Re: [PATCH net-next v3] checkpatch: warn about uses of ENOTSUPP
From: Jakub Kicinski Date: Mon, 11 May 2020 10:08:07 -0700 > ENOTSUPP often feels like the right error code to use, but it's > in fact not a standard Unix error. E.g.: > > $ python import errno errno.errorcode[errno.ENOTSUPP] > Traceback (most recent call last): > File "", line 1, in > AttributeError: module 'errno' has no attribute 'ENOTSUPP' > > There were numerous commits converting the uses back to EOPNOTSUPP > but in some cases we are stuck with the high error code for backward > compatibility reasons. > > Let's try prevent more ENOTSUPPs from getting into the kernel. > > Recent example: > https://lore.kernel.org/netdev/20200510182252.ga411...@lunn.ch/ > > v3 (Joe): > - fix the "not file" condition. > > v2 (Joe): > - add a link to recent discussion, > - don't match when scanning files, not patches to avoid sudden >influx of conversion patches. > https://lore.kernel.org/netdev/20200511165319.2251678-1-k...@kernel.org/ > > v1: > https://lore.kernel.org/netdev/20200510185148.2230767-1-k...@kernel.org/ > > Suggested-by: Andrew Lunn > Signed-off-by: Jakub Kicinski > Acked-by: Joe Perches Applied, thanks Jakub.
Re: [PATCH] perf tools: Replace zero-length array with flexible-array
On Mon, May 11, 2020 at 05:20:08PM -0300, Arnaldo Melo wrote: > > Thanks, applied > Thanks, Arnaldo. I wonder if could also take the other two: https://lore.kernel.org/lkml/20200511200911.GA13149@embeddedor/ https://lore.kernel.org/lkml/20200511201227.GA14041@embeddedor/ -- Gustavo
Re: [PATCH] kernel: sysctl: ignore invalid taint bits introduced via kernel.tainted and taint the kernel with TAINT_USER on writes
On Mon, May 11, 2020 at 11:10:45PM +, Luis Chamberlain wrote:
> On Mon, May 11, 2020 at 05:59:04PM -0400, Rafael Aquini wrote:
> > The sysctl knob allows any user with SYS_ADMIN capability to
> > taint the kernel with any arbitrary value, but this might
> > produce an invalid flags bitset being committed to tainted_mask.
> >
> > This patch introduces a simple way for proc_taint() to ignore
> > any eventual invalid bit coming from the user input before
> > committing those bits to the kernel tainted_mask, as well as
> > it makes clear use of TAINT_USER flag to mark the kernel
> > tainted by user everytime a taint value is written
> > to the kernel.tainted sysctl.
> >
> > Signed-off-by: Rafael Aquini
> > ---
> > kernel/sysctl.c | 17 -
> > 1 file changed, 16 insertions(+), 1 deletion(-)
> >
> > diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> > index 8a176d8727a3..f0a4fb38ac62 100644
> > --- a/kernel/sysctl.c
> > +++ b/kernel/sysctl.c
> > @@ -2623,17 +2623,32 @@ static int proc_taint(struct ctl_table *table, int
> > write,
> > return err;
> >
> > if (write) {
> > + int i;
> > +
> > + /*
> > +* Ignore user input that would make us committing
> > +* arbitrary invalid TAINT flags in the loop below.
> > +*/
> > + tmptaint &= (1UL << TAINT_FLAGS_COUNT) - 1;
>
> This looks good but we don't pr_warn() of information lost on intention.
>
Are you thinking in sth like:
+ if (tmptaint > TAINT_FLAGS_MAX) {
+ tmptaint &= TAINT_FLAGS_MAX;
+ pr_warn("proc_taint: out-of-range invalid input ignored"
+ " tainted_mask adjusted to 0x%x\n", tmptaint);
+ }
?
> > +
> > /*
> > * Poor man's atomic or. Not worth adding a primitive
> > * to everyone's atomic.h for this
> > */
> > - int i;
> > for (i = 0; i < BITS_PER_LONG && tmptaint >> i; i++) {
> > if ((tmptaint >> i) & 1)
> > add_taint(i, LOCKDEP_STILL_OK);
> > }
> > +
> > + /*
> > +* Users with SYS_ADMIN capability can include any arbitrary
> > +* taint flag by writing to this interface. If that's the case,
> > +* we also need to mark the kernel "tainted by user".
> > +*/
> > + add_taint(TAINT_USER, LOCKDEP_STILL_OK);
>
> I'm in favor of this however I'd like to hear from Ted on if it meets
> the original intention. I would think he had a good reason not to add
> it here.
>
Fair enough. The impression I got by reading Ted's original commit
message is that the intent was to have TAINT_USER as the flag set
via this interface, even though the code was allowing for any
arbitrary value. I think it's OK to let the user fiddle with
the flags, as it's been allowed since the introduction of
this interface, but we need to reflect that fact in the
tainting itself. Since TAINT_USER is not used anywhere,
this change perfectly communicates that fact without
the need for introducing yet another taint flag.
Cheers!
-- Rafael
Re: [PATCH v2 net-next 03/15] net: dsa: sja1105: keep the VLAN awareness state in a driver variable
On Tue, 12 May 2020 at 01:59, kbuild test robot wrote:
>
> Hi Vladimir,
>
> I love your patch! Yet something to improve:
>
> [auto build test ERROR on net-next/master]
> [cannot apply to linus/master v5.7-rc5]
> [if your patch is applied to the wrong git tree, please drop us a note to help
> improve the system. BTW, we also suggest to use '--base' option to specify the
> base tree in git format-patch, please see
> https://stackoverflow.com/a/37406982]
>
> url:
> https://github.com/0day-ci/linux/commits/Vladimir-Oltean/Traffic-support-for-dsa_8021q-in-vlan_filtering-1-mode/20200512-024329
> base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
> a6f0b26d6a5dcf27980e65f965779a929039f11d
> config: xtensa-randconfig-r021-20200511 (attached as .config)
> compiler: xtensa-linux-gcc (GCC) 9.3.0
> reproduce:
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
> ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross
> ARCH=xtensa
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kbuild test robot
>
> All errors (new ones prefixed by >>):
>
>xtensa-linux-ld: net/dsa/tag_sja1105.o: in function `sja1105_rcv':
> >> net/dsa/tag_sja1105.c:305: undefined reference to
> >> `sja1105_can_use_vlan_as_tags'
>xtensa-linux-ld: net/dsa/tag_sja1105.o: in function `sja1105_filter':
>net/dsa/tag_sja1105.c:77: undefined reference to
> `sja1105_can_use_vlan_as_tags'
>
Argh, this is by compiling the tagger module without the driver, it
looks like I can't get away with doing this.
The issue is that I don't want to expose struct sja1105_private
publicly, but I do have a struct sja1105_port hanging off of dp->priv.
But I don't have access to a dp pointer in the .filter method... So
the only realistic idea I have is to provide a shim implementation for
the call.
> vim +305 net/dsa/tag_sja1105.c
>
> f3097be21bf17a Vladimir Oltean 2019-06-08 246
> 227d07a07ef126 Vladimir Oltean 2019-05-05 247 static struct sk_buff
> *sja1105_rcv(struct sk_buff *skb,
> 227d07a07ef126 Vladimir Oltean 2019-05-05 248
> struct net_device *netdev,
> 227d07a07ef126 Vladimir Oltean 2019-05-05 249
> struct packet_type *pt)
> 227d07a07ef126 Vladimir Oltean 2019-05-05 250 {
> e53e18a6fe4d3a Vladimir Oltean 2019-06-08 251 struct sja1105_meta
> meta = {0};
> d461933638ae9f Vladimir Oltean 2019-06-08 252 int source_port,
> switch_id;
> e80f40cbe4dd51 Vladimir Oltean 2020-03-24 253 struct ethhdr *hdr;
> 227d07a07ef126 Vladimir Oltean 2019-05-05 254 u16 tpid, vid, tci;
> 42824463d38d27 Vladimir Oltean 2019-06-08 255 bool is_link_local;
> 227d07a07ef126 Vladimir Oltean 2019-05-05 256 bool is_tagged;
> e53e18a6fe4d3a Vladimir Oltean 2019-06-08 257 bool is_meta;
> 227d07a07ef126 Vladimir Oltean 2019-05-05 258
> e80f40cbe4dd51 Vladimir Oltean 2020-03-24 259 hdr = eth_hdr(skb);
> e80f40cbe4dd51 Vladimir Oltean 2020-03-24 260 tpid =
> ntohs(hdr->h_proto);
> d461933638ae9f Vladimir Oltean 2019-06-08 261 is_tagged = (tpid ==
> ETH_P_SJA1105);
> 42824463d38d27 Vladimir Oltean 2019-06-08 262 is_link_local =
> sja1105_is_link_local(skb);
> e53e18a6fe4d3a Vladimir Oltean 2019-06-08 263 is_meta =
> sja1105_is_meta_frame(skb);
> 227d07a07ef126 Vladimir Oltean 2019-05-05 264
> 227d07a07ef126 Vladimir Oltean 2019-05-05 265 skb->offload_fwd_mark
> = 1;
> 227d07a07ef126 Vladimir Oltean 2019-05-05 266
> 42824463d38d27 Vladimir Oltean 2019-06-08 267 if (is_tagged) {
> 42824463d38d27 Vladimir Oltean 2019-06-08 268 /* Normal
> traffic path. */
> e80f40cbe4dd51 Vladimir Oltean 2020-03-24 269
> skb_push_rcsum(skb, ETH_HLEN);
> e80f40cbe4dd51 Vladimir Oltean 2020-03-24 270
> __skb_vlan_pop(skb, );
> e80f40cbe4dd51 Vladimir Oltean 2020-03-24 271
> skb_pull_rcsum(skb, ETH_HLEN);
> e80f40cbe4dd51 Vladimir Oltean 2020-03-24 272
> skb_reset_network_header(skb);
> e80f40cbe4dd51 Vladimir Oltean 2020-03-24 273
> skb_reset_transport_header(skb);
> e80f40cbe4dd51 Vladimir Oltean 2020-03-24 274
> 42824463d38d27 Vladimir Oltean 2019-06-08 275 vid = tci &
> VLAN_VID_MASK;
> 42824463d38d27 Vladimir Oltean 2019-06-08 276 source_port =
> dsa_8021q_rx_source_port(vid);
> 42824463d38d27 Vl
[PATCH v3] admin guide/pm: Admin guide for intel-speed-select
Added documentation to configure servers to use Intel(R) Speed Select Technology using intel-speed-select tool. Signed-off-by: Srinivas Pandruvada Acked-by: Andriy Shevchenko --- v3: - Match the command results with the latest tool and added to this documentation. Tool made some "numbers" to more verbose display, so change documentation also. v2: Only formatting changes. So used ACK from Andriy. Addressed comments by Jonathan for the following items: - Removed non ASCII character - Addressed section/sub-section markers - Folded all commands and outputs in literal blocks .../admin-guide/pm/intel-speed-select.rst | 917 ++ .../admin-guide/pm/working-state.rst | 1 + 2 files changed, 918 insertions(+) create mode 100644 Documentation/admin-guide/pm/intel-speed-select.rst diff --git a/Documentation/admin-guide/pm/intel-speed-select.rst b/Documentation/admin-guide/pm/intel-speed-select.rst new file mode 100644 index ..b2ca601c21c6 --- /dev/null +++ b/Documentation/admin-guide/pm/intel-speed-select.rst @@ -0,0 +1,917 @@ +.. SPDX-License-Identifier: GPL-2.0 + + +Intel(R) Speed Select Technology User Guide + + +The Intel(R) Speed Select Technology (Intel(R) SST) provides a powerful new +collection of features that give more granular control over CPU performance. +With Intel(R) SST, one server can be configured for power and performance for a +variety of diverse workload requirements. + +Refer to the links below for an overview of the technology: + +- https://www.intel.com/content/www/us/en/architecture-and-technology/speed-select-technology-article.html +- https://builders.intel.com/docs/networkbuilders/intel-speed-select-technology-base-frequency-enhancing-performance.pdf + +These capabilities are further enhanced in some of the newer generations of +server platforms where these features can be enumerated and controlled +dynamically without pre-configuring via BIOS setup options. This dynamic +configuration is done via mailbox commands to the hardware. One way to enumerate +and configure these features is by using the Intel Speed Select utility. + +This document explains how to use the Intel Speed Select tool to enumerate and +control Intel(R) SST features. This document gives example commands and explains +how these commands change the power and performance profile of the system under +test. Using this tool as an example, customers can replicate the messaging +implemented in the tool in their production software. + +intel-speed-select configuration tool +== + +Most Linux distribution packages may include the "intel-speed-select" tool. If not, +it can be built by downloading the Linux kernel tree from kernel.org. Once +downloaded, the tool can be built without building the full kernel. + +From the kernel tree, run the following commands:: + +# cd tools/power/x86/intel-speed-select/ +# make +# make install + +Getting Help + + +To get help with the tool, execute the command below:: + +# intel-speed-select --help + +The top-level help describes arguments and features. Notice that there is a +multi-level help structure in the tool. For example, to get help for the feature "perf-profile":: + +# intel-speed-select perf-profile --help + +To get help on a command, another level of help is provided. For example for the command info "info":: + +# intel-speed-select perf-profile info --help + +Summary of platform capability +-- +To check the current platform and driver capaibilities, execute:: + +#intel-speed-select --info + +For example on a test system:: + + # intel-speed-select --info + Intel(R) Speed Select Technology + Executing on CPU model: X + Platform: API version : 1 + Platform: Driver version : 1 + Platform: mbox supported : 1 + Platform: mmio supported : 1 + Intel(R) SST-PP (feature perf-profile) is supported + TDP level change control is unlocked, max level: 4 + Intel(R) SST-TF (feature turbo-freq) is supported + Intel(R) SST-BF (feature base-freq) is not supported + Intel(R) SST-CP (feature core-power) is supported + +Intel(R) Speed Select Technology - Performance Profile (Intel(R) SST-PP) + + +This feature allows configuration of a server dynamically based on workload +performance requirements. This helps users during deployment as they do not have +to choose a specific server configuration statically. This Intel(R) Speed Select +Technology - Performance Profile (Intel(R) SST-PP) feature introduces a mechanism +that allows multiple optimized performance profiles per system. Each profile +defines a set of CPUs that need to be online and rest offline to sustain a +guaranteed base frequency. Once the user issues a command to use a specific +performance profile
Re: linux-next: Fixes tag needs some work in the scsi-fixes tree
Stephen,
> Fixes: 4910b524ac9 ("scsi: qla2xxx: Add support for setting port speed")
>
> has these problem(s):
>
> - SHA1 should be at least 12 digits long
I'm pretty good at spotting 8-digit SHAs but the 11 digits tripped me up
in this case.
I refined the SHA validation logic in my commit hook script to ensure 12
digits going forward.
Thanks!
--
Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v1 net-next 2/3] net: dsa: felix: Configure Time-Aware Scheduler via taprio offload
From: Xiaoliang Yang
Date: Mon, 11 May 2020 13:43:31 +0800
> @@ -710,7 +714,7 @@ static void felix_port_policer_del(struct dsa_switch *ds,
> int port)
> ocelot_port_policer_del(ocelot, port);
> }
>
> -static const struct dsa_switch_ops felix_switch_ops = {
> +static struct dsa_switch_ops felix_switch_ops = {
> .get_tag_protocol = felix_get_tag_protocol,
> .setup = felix_setup,
> .teardown = felix_teardown,
There has to be a better way to do this, removing const for operation
structs is very undesirable.
Re: [PATCH v3 3/3] KVM: x86: Move MPK feature detection to common code
On Mon, May 11, 2020 at 4:33 PM Babu Moger wrote: > > Both Intel and AMD support (MPK) Memory Protection Key feature. > Move the feature detection from VMX to the common code. It should > work for both the platforms now. > > Signed-off-by: Babu Moger > --- > arch/x86/kvm/cpuid.c |4 +++- > arch/x86/kvm/vmx/vmx.c |4 > 2 files changed, 3 insertions(+), 5 deletions(-) > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index 901cd1fdecd9..3da7d6ea7574 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -278,6 +278,8 @@ void kvm_set_cpu_caps(void) > #ifdef CONFIG_X86_64 > unsigned int f_gbpages = F(GBPAGES); > unsigned int f_lm = F(LM); > + /* PKU is not yet implemented for shadow paging. */ > + unsigned int f_pku = tdp_enabled ? F(PKU) : 0; I think we still want to require that OSPKE be set on the host before exposing PKU to the guest.
Re: [PATCH net-next 0/2] net: dsa: Constify two tagger ops
From: Florian Fainelli Date: Mon, 11 May 2020 16:47:13 -0700 > This patch series constifies the dsa_device_ops for ocelot and sja1105 Series applied, thanks Florian.
[PATCH net-next 2/2] net: dsa: tag_sja1105: Constify dsa_device_ops
sja1105_netdev_ops should be const since that is what the DSA layer
expects.
Signed-off-by: Florian Fainelli
---
net/dsa/tag_sja1105.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/dsa/tag_sja1105.c b/net/dsa/tag_sja1105.c
index d553bf36bd41..5ecac5921a7d 100644
--- a/net/dsa/tag_sja1105.c
+++ b/net/dsa/tag_sja1105.c
@@ -304,7 +304,7 @@ static struct sk_buff *sja1105_rcv(struct sk_buff *skb,
is_meta);
}
-static struct dsa_device_ops sja1105_netdev_ops = {
+static const struct dsa_device_ops sja1105_netdev_ops = {
.name = "sja1105",
.proto = DSA_TAG_PROTO_SJA1105,
.xmit = sja1105_xmit,
--
2.17.1
[PATCH net-next 1/2] net: dsa: ocelot: Constify dsa_device_ops
ocelot_netdev_ops should be const since that is what the DSA layer
expects.
Signed-off-by: Florian Fainelli
---
net/dsa/tag_ocelot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/dsa/tag_ocelot.c b/net/dsa/tag_ocelot.c
index 59de1315100f..b0c98ee4e13b 100644
--- a/net/dsa/tag_ocelot.c
+++ b/net/dsa/tag_ocelot.c
@@ -228,7 +228,7 @@ static struct sk_buff *ocelot_rcv(struct sk_buff *skb,
return skb;
}
-static struct dsa_device_ops ocelot_netdev_ops = {
+static const struct dsa_device_ops ocelot_netdev_ops = {
.name = "ocelot",
.proto = DSA_TAG_PROTO_OCELOT,
.xmit = ocelot_xmit,
--
2.17.1
[PATCH net-next 0/2] net: dsa: Constify two tagger ops
This patch series constifies the dsa_device_ops for ocelot and sja1105 Florian Fainelli (2): net: dsa: ocelot: Constify dsa_device_ops net: dsa: tag_sja1105: Constify dsa_device_ops net/dsa/tag_ocelot.c | 2 +- net/dsa/tag_sja1105.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- 2.17.1
Re: [PATCH v3 1/3] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86
On 5/11/20 4:32 PM, Babu Moger wrote: > AMD's next generation of EPYC processors support the MPK (Memory > Protection Keys) feature. > > So, rename X86_INTEL_MEMORY_PROTECTION_KEYS to X86_MEMORY_PROTECTION_KEYS. > > No functional changes. > > AMD documentation for MPK feature is available at "AMD64 Architecture > Programmer’s Manual Volume 2: System Programming, Pub. 24593 Rev. 3.34, > Section 5.6.6 Memory Protection Keys (MPK) Bit". Documentation can be > obtained at the link below. I was hoping to see at least *some* justification in this changelog. Do you think having "INTEL_" will confuse users? Is there some technical merit to this change? The naming churn is an obviously bad, not technically necessary change. > +config X86_MEMORY_PROTECTION_KEYS > + # Note: This is an intermediate change to avoid config prompt to > + # the users. Eventually, the option X86_INTEL_MEMORY_PROTECTION_KEYS > + # should be changed to X86_MEMORY_PROTECTION_KEYS permanently after > + # few kernel revisions. > + def_bool X86_INTEL_MEMORY_PROTECTION_KEYS "after a few kernel revisions" is code for "never". :) Could we put an explicit date on this, please? One year seems roughly right. Or, maybe "after the v5.10" release, so that this will approach will make into at least one LTS kernel. Maybe: # Set the "INTEL_"-free option whenever the "INTEL_" one is set. # The "INTEL_" one should be removed and replaced by this option after # 5.10. This avoids exposing most 'oldconfig' users to this churn.
[PATCH v3 3/3] KVM: x86: Move MPK feature detection to common code
Both Intel and AMD support (MPK) Memory Protection Key feature. Move the feature detection from VMX to the common code. It should work for both the platforms now. Signed-off-by: Babu Moger --- arch/x86/kvm/cpuid.c |4 +++- arch/x86/kvm/vmx/vmx.c |4 2 files changed, 3 insertions(+), 5 deletions(-) diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c index 901cd1fdecd9..3da7d6ea7574 100644 --- a/arch/x86/kvm/cpuid.c +++ b/arch/x86/kvm/cpuid.c @@ -278,6 +278,8 @@ void kvm_set_cpu_caps(void) #ifdef CONFIG_X86_64 unsigned int f_gbpages = F(GBPAGES); unsigned int f_lm = F(LM); + /* PKU is not yet implemented for shadow paging. */ + unsigned int f_pku = tdp_enabled ? F(PKU) : 0; #else unsigned int f_gbpages = 0; unsigned int f_lm = 0; @@ -326,7 +328,7 @@ void kvm_set_cpu_caps(void) ); kvm_cpu_cap_mask(CPUID_7_ECX, - F(AVX512VBMI) | F(LA57) | 0 /*PKU*/ | 0 /*OSPKE*/ | F(RDPID) | + F(AVX512VBMI) | F(LA57) | f_pku | 0 /*OSPKE*/ | F(RDPID) | F(AVX512_VPOPCNTDQ) | F(UMIP) | F(AVX512_VBMI2) | F(GFNI) | F(VAES) | F(VPCLMULQDQ) | F(AVX512_VNNI) | F(AVX512_BITALG) | F(CLDEMOTE) | F(MOVDIRI) | F(MOVDIR64B) | 0 /*WAITPKG*/ diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 46898a476ba7..d153732ed88f 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -7136,10 +7136,6 @@ static __init void vmx_set_cpu_caps(void) if (vmx_pt_mode_is_host_guest()) kvm_cpu_cap_check_and_set(X86_FEATURE_INTEL_PT); - /* PKU is not yet implemented for shadow paging. */ - if (enable_ept && boot_cpu_has(X86_FEATURE_OSPKE)) - kvm_cpu_cap_check_and_set(X86_FEATURE_PKU); - if (vmx_umip_emulated()) kvm_cpu_cap_set(X86_FEATURE_UMIP);
[PATCH v8 08/11] pstore/blk: Provide way to query pstore configuration
From: WeiXiong Liao
In order to configure itself, the MTD backend needs to be able to query
the current pstore configuration. Introduce pstore_blk_get_config() for
this purpose.
Signed-off-by: WeiXiong Liao
Link:
https://lore.kernel.org/r/1585126506-18635-10-git-send-email-liaoweixi...@allwinnertech.com
Co-developed-by: Kees Cook
Signed-off-by: Kees Cook
---
fs/pstore/blk.c| 37 ++---
include/linux/pstore_blk.h | 28
2 files changed, 58 insertions(+), 7 deletions(-)
diff --git a/fs/pstore/blk.c b/fs/pstore/blk.c
index 8c78eb9906fb..95436cff8976 100644
--- a/fs/pstore/blk.c
+++ b/fs/pstore/blk.c
@@ -94,6 +94,17 @@ struct bdev_info {
sector_t start_sect;
};
+#define check_size(name, alignsize) ({ \
+ long _##name_ = (name); \
+ _##name_ = _##name_ <= 0 ? 0 : (_##name_ * 1024); \
+ if (_##name_ & ((alignsize) - 1)) { \
+ pr_info(#name " must align to %d\n",\
+ (alignsize)); \
+ _##name_ = ALIGN(name, (alignsize));\
+ } \
+ _##name_; \
+})
+
/**
* struct pstore_device_info - back-end pstore/blk driver structure.
*
@@ -149,13 +160,11 @@ static int psblk_register_do(struct pstore_device_info
*dev)
dev->flags = UINT_MAX;
#define verify_size(name, alignsize, enabled) {
\
- long _##name_ = (enabled) ? (name) : 0; \
- _##name_ = _##name_ <= 0 ? 0 : (_##name_ * 1024); \
- if (_##name_ & ((alignsize) - 1)) { \
- pr_info(#name " must align to %d\n",\
- (alignsize)); \
- _##name_ = ALIGN(name, (alignsize));\
- } \
+ long _##name_; \
+ if (enabled)\
+ _##name_ = check_size(name, alignsize); \
+ else\
+ _##name_ = 0; \
name = _##name_ / 1024; \
pstore_zone_info->name = _##name_; \
}
@@ -456,6 +465,20 @@ void unregister_pstore_blk(unsigned int major)
}
EXPORT_SYMBOL_GPL(unregister_pstore_blk);
+/* get information of pstore/blk */
+int pstore_blk_get_config(struct pstore_blk_config *info)
+{
+ strncpy(info->device, blkdev, 80);
+ info->max_reason = max_reason;
+ info->kmsg_size = check_size(kmsg_size, 4096);
+ info->pmsg_size = check_size(pmsg_size, 4096);
+ info->ftrace_size = check_size(ftrace_size, 4096);
+ info->console_size = check_size(console_size, 4096);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(pstore_blk_get_config);
+
static void __exit pstore_blk_exit(void)
{
mutex_lock(_blk_lock);
diff --git a/include/linux/pstore_blk.h b/include/linux/pstore_blk.h
index ccba8c068752..0c40774e71e0 100644
--- a/include/linux/pstore_blk.h
+++ b/include/linux/pstore_blk.h
@@ -49,4 +49,32 @@ struct pstore_blk_info {
int register_pstore_blk(struct pstore_blk_info *info);
void unregister_pstore_blk(unsigned int major);
+/**
+ * struct pstore_blk_config - the pstore_blk backend configuration
+ *
+ * @device:Name of the desired block device
+ * @max_reason:Maximum kmsg dump reason to store to block
device
+ * @kmsg_size: Total size of for kmsg dumps
+ * @pmsg_size: Total size of the pmsg storage area
+ * @console_size: Total size of the console storage area
+ * @ftrace_size: Total size for ftrace logging data (for all CPUs)
+ */
+struct pstore_blk_config {
+ char device[80];
+ enum kmsg_dump_reason max_reason;
+ unsigned long kmsg_size;
+ unsigned long pmsg_size;
+ unsigned long console_size;
+ unsigned long ftrace_size;
+};
+
+/**
+ * pstore_blk_get_config - get a copy of the pstore_blk backend configuration
+ *
+ * @info: The sturct pstore_blk_config to be filled in
+ *
+ * Failure returns negative error code, and success returns 0.
+ */
+int pstore_blk_get_config(struct pstore_blk_config *info);
+
#endif
--
2.20.1
[PATCH v8 02/11] pstore/blk: Introduce backend for block devices
From: WeiXiong Liao pstore/blk is similar to pstore/ram, but uses a block device as the storage rather than persistent ram. The pstore/blk backend solves two common use-cases that used to preclude using pstore/ram: - not all devices have a battery that could be used to persist regular RAM across power failures. - most embedded intelligent equipment have no persistent ram, which increases costs, instead preferring cheaper solutions, like block devices. pstore/blk provides separate configurations for the end user and for the block drivers. User configuration determines how pstore/blk operates, such as record sizes, max kmsg dump reasons, etc. These can be set by Kconfig and/or module parameters, but module parameter have priority over Kconfig. Driver configuration covers all the details about the target block device, such as total size of the device and how to perform read/write operations. These are provided by block drivers, calling pstore_register_blkdev(), including an optional panic_write callback used to bypass regular IO APIs in an effort to avoid potentially destabilized kernel code during a panic. Signed-off-by: WeiXiong Liao Link: https://lore.kernel.org/r/1585126506-18635-3-git-send-email-liaoweixi...@allwinnertech.com Co-developed-by: Kees Cook Signed-off-by: Kees Cook --- fs/pstore/Kconfig | 64 ++ fs/pstore/Makefile | 3 + fs/pstore/blk.c| 437 + include/linux/pstore_blk.h | 51 + 4 files changed, 555 insertions(+) create mode 100644 fs/pstore/blk.c create mode 100644 include/linux/pstore_blk.h diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig index 98d2457bdd9f..958bec75f907 100644 --- a/fs/pstore/Kconfig +++ b/fs/pstore/Kconfig @@ -160,3 +160,67 @@ config PSTORE_ZONE help The common layer for pstore/blk (and pstore/ram in the future) to manage storage in zones. + +config PSTORE_BLK + tristate "Log panic/oops to a block device" + depends on PSTORE + depends on BLOCK + select PSTORE_ZONE + default n + help + This enables panic and oops message to be logged to a block dev + where it can be read back at some later point. + + If unsure, say N. + +config PSTORE_BLK_BLKDEV + string "block device identifier" + depends on PSTORE_BLK + default "" + help + Which block device should be used for pstore/blk. + + It accept the following variants: + 1) device number in hexadecimal representation, +with no leading 0x, for example b302. + 2) /dev/ represents the device number of disk + 3) /dev/ represents the device number +of partition - device number of disk plus the partition number + 4) /dev/p - same as the above, this form is +used when disk name of partitioned disk ends with a digit. + 5) PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF representing the +unique id of a partition if the partition table provides it. +The UUID may be either an EFI/GPT UUID, or refer to an MSDOS +partition using the format -PP, where is a zero- +filled hex representation of the 32-bit "NT disk signature", and PP +is a zero-filled hex representation of the 1-based partition number. + 6) PARTUUID=/PARTNROFF= to select a partition in relation +to a partition with a known unique id. + 7) : major and minor number of the device separated by +a colon. + + NOTE that, both Kconfig and module parameters can configure + pstore/blk, but module parameters have priority over Kconfig. + +config PSTORE_BLK_KMSG_SIZE + int "Size in Kbytes of kmsg dump log to store" + depends on PSTORE_BLK + default 64 + help + This just sets size of kmsg dump (oops, panic, etc) log for + pstore/blk. The size is in KB and must be a multiple of 4. + + NOTE that, both Kconfig and module parameters can configure + pstore/blk, but module parameters have priority over Kconfig. + +config PSTORE_BLK_MAX_REASON + int "Maximum kmsg dump reason to store" + depends on PSTORE_BLK + default 2 + help + The maximum reason for kmsg dumps to store. The default is + 2 (KMSG_DUMP_OOPS), see include/linux/kmsg_dump.h's + enum kmsg_dump_reason for more details. + + NOTE that, both Kconfig and module parameters can configure + pstore/blk, but module parameters have priority over Kconfig. diff --git a/fs/pstore/Makefile b/fs/pstore/Makefile index 58a967cbe4af..c270467aeece 100644 --- a/fs/pstore/Makefile +++ b/fs/pstore/Makefile @@ -15,3 +15,6 @@ obj-$(CONFIG_PSTORE_RAM) += ramoops.o pstore_zone-objs += zone.o obj-$(CONFIG_PSTORE_ZONE) += pstore_zone.o + +pstore_blk-objs += blk.o +obj-$(CONFIG_PSTORE_BLK) +=
[PATCH v8 07/11] pstore/zone: Provide way to skip "broken" zone for MTD devices
From: WeiXiong Liao
One requirement to support MTD devices in pstore/zone is having a
way to declare certain regions as broken. Add this support to
pstore/zone.
The MTD driver should return -ENOMSG when encountering a bad region,
which tells pstore/zone to skip and try the next one.
Signed-off-by: WeiXiong Liao
Link:
https://lore.kernel.org/r/1585126506-18635-9-git-send-email-liaoweixi...@allwinnertech.com
Signed-off-by: Kees Cook
---
fs/pstore/blk.c | 10 --
fs/pstore/zone.c| 65 ++---
include/linux/pstore_blk.h | 3 +-
include/linux/pstore_zone.h | 12 ---
4 files changed, 71 insertions(+), 19 deletions(-)
diff --git a/fs/pstore/blk.c b/fs/pstore/blk.c
index 9f1f0d5b3795..8c78eb9906fb 100644
--- a/fs/pstore/blk.c
+++ b/fs/pstore/blk.c
@@ -109,9 +109,12 @@ struct bdev_info {
* means error.
* @write: The same as @read, but the following error number:
* -EBUSY means try to write again later.
+ * -ENOMSG means to try next zone.
* @panic_write:The write operation only used for panic case. It's optional
- * if you do not care panic log. The parameters and return value
- * are the same as @read.
+ * if you do not care panic log. The parameters are relative
+ * value to storage.
+ * On success, the number of bytes should be returned, others
+ * excluding -ENOMSG mean error. -ENOMSG means to try next zone.
*/
struct pstore_device_info {
unsigned long total_size;
@@ -339,6 +342,9 @@ static ssize_t psblk_blk_panic_write(const char *buf,
size_t size,
/* size and off must align to SECTOR_SIZE for block device */
ret = blkdev_panic_write(buf, off >> SECTOR_SHIFT,
size >> SECTOR_SHIFT);
+ /* try next zone */
+ if (ret == -ENOMSG)
+ return ret;
return ret ? -EIO : size;
}
diff --git a/fs/pstore/zone.c b/fs/pstore/zone.c
index d83b24f3cdd9..110a38242f74 100644
--- a/fs/pstore/zone.c
+++ b/fs/pstore/zone.c
@@ -249,6 +249,9 @@ static int psz_zone_write(struct pstore_zone *zone,
return 0;
dirty:
+ /* no need to mark dirty if going to try next zone */
+ if (wcnt == -ENOMSG)
+ return -ENOMSG;
atomic_set(>dirty, true);
/* flush dirty zones nicely */
if (wcnt == -EBUSY && !is_on_panic())
@@ -391,7 +394,11 @@ static int psz_kmsg_recover_meta(struct psz_context *cxt)
return -EINVAL;
rcnt = info->read((char *)buf, len, zone->off);
- if (rcnt != len) {
+ if (rcnt == -ENOMSG) {
+ pr_debug("%s with id %lu may be broken, skip\n",
+ zone->name, i);
+ continue;
+ } else if (rcnt != len) {
pr_err("read %s with id %lu failed\n", zone->name, i);
return (int)rcnt < 0 ? (int)rcnt : -EIO;
}
@@ -726,24 +733,58 @@ static void psz_write_kmsg_hdr(struct pstore_zone *zone,
hdr->counter = 0;
}
+/*
+ * In case zone is broken, which may occur to MTD device, we try each zones,
+ * start at cxt->kmsg_write_cnt.
+ */
static inline int notrace psz_kmsg_write_record(struct psz_context *cxt,
struct pstore_record *record)
{
+ int ret = -EBUSY;
size_t size, hlen;
struct pstore_zone *zone;
- unsigned int zonenum;
+ unsigned int i;
- zonenum = cxt->kmsg_write_cnt;
- zone = cxt->kpszs[zonenum];
- if (unlikely(!zone))
- return -ENOSPC;
- cxt->kmsg_write_cnt = (zonenum + 1) % cxt->kmsg_max_cnt;
+ for (i = 0; i < cxt->kmsg_max_cnt; i++) {
+ unsigned int zonenum, len;
+
+ zonenum = (cxt->kmsg_write_cnt + i) % cxt->kmsg_max_cnt;
+ zone = cxt->kpszs[zonenum];
+ if (unlikely(!zone))
+ return -ENOSPC;
+
+ /* avoid destroying old data, allocate a new one */
+ len = zone->buffer_size + sizeof(*zone->buffer);
+ zone->oldbuf = zone->buffer;
+ zone->buffer = kzalloc(len, GFP_KERNEL);
+ if (!zone->buffer) {
+ zone->buffer = zone->oldbuf;
+ return -ENOMEM;
+ }
+ zone->buffer->sig = zone->oldbuf->sig;
+
+ pr_debug("write %s to zone id %d\n", zone->name, zonenum);
+ psz_write_kmsg_hdr(zone, record);
+ hlen = sizeof(struct psz_kmsg_header);
+ size = min_t(size_t, record->size, zone->buffer_size - hlen);
+ ret = psz_zone_write(zone, FLUSH_ALL, record->buf, size, hlen);
+ if (likely(!ret || ret != -ENOMSG)) {
+ cxt->kmsg_write_cnt = zonenum + 1;
+
[PATCH v3 2/3] KVM: x86: Move pkru save/restore to x86.c
MPK feature is supported by both VMX and SVM. So we can
safely move pkru state save/restore to common code. Also
move all the pkru data structure to kvm_vcpu_arch.
Also fixes the problem Jim Mattson pointed and suggested below.
"Though rdpkru and wrpkru are contingent upon CR4.PKE, the PKRU
resource isn't. It can be read with XSAVE and written with XRSTOR.
So, if we don't set the guest PKRU value here(kvm_load_guest_xsave_state),
the guest can read the host value.
In case of kvm_load_host_xsave_state, guest with CR4.PKE clear could
potentially use XRSTOR to change the host PKRU value"
Signed-off-by: Babu Moger
---
arch/x86/include/asm/kvm_host.h |1 +
arch/x86/kvm/vmx/vmx.c | 18 --
arch/x86/kvm/x86.c | 17 +
3 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 42a2d0d3984a..afd8f3780ae0 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -578,6 +578,7 @@ struct kvm_vcpu_arch {
unsigned long cr4;
unsigned long cr4_guest_owned_bits;
unsigned long cr8;
+ u32 host_pkru;
u32 pkru;
u32 hflags;
u64 efer;
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index c2c6335a998c..46898a476ba7 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -1372,7 +1372,6 @@ void vmx_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
vmx_vcpu_pi_load(vcpu, cpu);
- vmx->host_pkru = read_pkru();
vmx->host_debugctlmsr = get_debugctlmsr();
}
@@ -6577,11 +6576,6 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu)
kvm_load_guest_xsave_state(vcpu);
- if (static_cpu_has(X86_FEATURE_PKU) &&
- kvm_read_cr4_bits(vcpu, X86_CR4_PKE) &&
- vcpu->arch.pkru != vmx->host_pkru)
- __write_pkru(vcpu->arch.pkru);
-
pt_guest_enter(vmx);
if (vcpu_to_pmu(vcpu)->version)
@@ -6671,18 +6665,6 @@ static void vmx_vcpu_run(struct kvm_vcpu *vcpu)
pt_guest_exit(vmx);
- /*
-* eager fpu is enabled if PKEY is supported and CR4 is switched
-* back on host, so it is safe to read guest PKRU from current
-* XSAVE.
-*/
- if (static_cpu_has(X86_FEATURE_PKU) &&
- kvm_read_cr4_bits(vcpu, X86_CR4_PKE)) {
- vcpu->arch.pkru = rdpkru();
- if (vcpu->arch.pkru != vmx->host_pkru)
- __write_pkru(vmx->host_pkru);
- }
-
kvm_load_host_xsave_state(vcpu);
vmx->nested.nested_run_pending = 0;
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c5835f9cb9ad..98baeb74452c 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -836,11 +836,25 @@ void kvm_load_guest_xsave_state(struct kvm_vcpu *vcpu)
vcpu->arch.ia32_xss != host_xss)
wrmsrl(MSR_IA32_XSS, vcpu->arch.ia32_xss);
}
+
+ if (static_cpu_has(X86_FEATURE_PKU) &&
+ (kvm_read_cr4_bits(vcpu, X86_CR4_PKE) ||
+(vcpu->arch.xcr0 & XFEATURE_MASK_PKRU)) &&
+ vcpu->arch.pkru != vcpu->arch.host_pkru)
+ __write_pkru(vcpu->arch.pkru);
}
EXPORT_SYMBOL_GPL(kvm_load_guest_xsave_state);
void kvm_load_host_xsave_state(struct kvm_vcpu *vcpu)
{
+ if (static_cpu_has(X86_FEATURE_PKU) &&
+ (kvm_read_cr4_bits(vcpu, X86_CR4_PKE) ||
+(vcpu->arch.xcr0 & XFEATURE_MASK_PKRU))) {
+ vcpu->arch.pkru = rdpkru();
+ if (vcpu->arch.pkru != vcpu->arch.host_pkru)
+ __write_pkru(vcpu->arch.host_pkru);
+ }
+
if (kvm_read_cr4_bits(vcpu, X86_CR4_OSXSAVE)) {
if (vcpu->arch.xcr0 != host_xcr0)
@@ -3570,6 +3584,9 @@ void kvm_arch_vcpu_load(struct kvm_vcpu *vcpu, int cpu)
kvm_x86_ops.vcpu_load(vcpu, cpu);
+ /* Save host pkru register if supported */
+ vcpu->arch.host_pkru = read_pkru();
+
/* Apply any externally detected TSC adjustments (due to suspend) */
if (unlikely(vcpu->arch.tsc_offset_adjustment)) {
adjust_tsc_offset_host(vcpu, vcpu->arch.tsc_offset_adjustment);
Re: [RFC 14/43] mm: memblock: PKRAM: prevent memblock resize from clobbering preserved pages
On 5/11/20 6:57 AM, Mike Rapoport wrote:
> On Wed, May 06, 2020 at 05:41:40PM -0700, Anthony Yznaga wrote:
>> The size of the memblock reserved array may be increased while preserved
>> pages are being reserved. When this happens, preserved pages that have
>> not yet been reserved are at risk for being clobbered when space for a
>> larger array is allocated.
>> When called from memblock_double_array(), a wrapper around
>> memblock_find_in_range() walks the preserved pages pagetable to find
>> sufficiently sized ranges without preserved pages and passes them to
>> memblock_find_in_range().
> I'd suggest to create an array of memblock_region's that will contain
> the PKRAM ranges before kexec and pass this array to the new kernel.
> Then, somewhere in start_kerenel() replace replace
> memblock.reserved->regions with that array.
I'll look into doing this. Thanks!
Anthony
>
>> Signed-off-by: Anthony Yznaga
>> ---
>> include/linux/pkram.h | 3 +++
>> mm/memblock.c | 15 +--
>> mm/pkram.c| 51
>> +++
>> 3 files changed, 67 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/pkram.h b/include/linux/pkram.h
>> index edc5d8bef9d3..409022e1472f 100644
>> --- a/include/linux/pkram.h
>> +++ b/include/linux/pkram.h
>> @@ -62,6 +62,9 @@ struct page *pkram_load_page(struct pkram_stream *ps,
>> unsigned long *index,
>> ssize_t pkram_write(struct pkram_stream *ps, const void *buf, size_t count);
>> size_t pkram_read(struct pkram_stream *ps, void *buf, size_t count);
>>
>> +phys_addr_t pkram_memblock_find_in_range(phys_addr_t start, phys_addr_t end,
>> + phys_addr_t size, phys_addr_t align);
>> +
>> #ifdef CONFIG_PKRAM
>> extern unsigned long pkram_reserved_pages;
>> void pkram_reserve(void);
>> diff --git a/mm/memblock.c b/mm/memblock.c
>> index c79ba6f9920c..69ae883b8d21 100644
>> --- a/mm/memblock.c
>> +++ b/mm/memblock.c
>> @@ -16,6 +16,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>> #include
>> @@ -349,6 +350,16 @@ phys_addr_t __init_memblock
>> memblock_find_in_range(phys_addr_t start,
>> return ret;
>> }
>>
>> +phys_addr_t __init_memblock __memblock_find_in_range(phys_addr_t start,
>> +phys_addr_t end, phys_addr_t size,
>> +phys_addr_t align)
>> +{
>> +if (IS_ENABLED(CONFIG_PKRAM))
>> +return pkram_memblock_find_in_range(start, end, size, align);
>> +else
>> +return memblock_find_in_range(start, end, size, align);
>> +}
>> +
>> static void __init_memblock memblock_remove_region(struct memblock_type
>> *type, unsigned long r)
>> {
>> type->total_size -= type->regions[r].size;
>> @@ -447,11 +458,11 @@ static int __init_memblock
>> memblock_double_array(struct memblock_type *type,
>> if (type != )
>> new_area_start = new_area_size = 0;
>>
>> -addr = memblock_find_in_range(new_area_start + new_area_size,
>> +addr = __memblock_find_in_range(new_area_start + new_area_size,
>> memblock.current_limit,
>> new_alloc_size, PAGE_SIZE);
>> if (!addr && new_area_size)
>> -addr = memblock_find_in_range(0,
>> +addr = __memblock_find_in_range(0,
>> min(new_area_start, memblock.current_limit),
>> new_alloc_size, PAGE_SIZE);
>>
>> diff --git a/mm/pkram.c b/mm/pkram.c
>> index dd3c89614010..e49c9bcd3854 100644
>> --- a/mm/pkram.c
>> +++ b/mm/pkram.c
>> @@ -1238,3 +1238,54 @@ void pkram_free_pgt(void)
>> __free_pages_core(virt_to_page(pkram_pgd), 0);
>> pkram_pgd = NULL;
>> }
>> +
>> +static int __init_memblock pkram_memblock_find_cb(struct pkram_pg_state
>> *st, unsigned long base, unsigned long size)
>> +{
>> +unsigned long end = base + size;
>> +unsigned long addr;
>> +
>> +if (size < st->min_size)
>> +return 0;
>> +
>> +addr = memblock_find_in_range(base, end, st->min_size, PAGE_SIZE);
>> +if (!addr)
>> +return 0;
>> +
>> +st->retval = addr;
>> +return 1;
>> +}
>> +
>> +/*
>> + * It may be necessary to allocate a larger reserved memblock array
>> + * while populating it with ranges of preserved pages. To avoid
>> + * trampling preserved pages that have not yet been added to the
>> + * memblock reserved list this function implements a wrapper around
>> + * memblock_find_in_range() that restricts searches to subranges
>> + * that do not contain preserved pages.
>> + */
>> +phys_addr_t __init_memblock pkram_memblock_find_in_range(phys_addr_t start,
>> +phys_addr_t end, phys_addr_t size,
>> +phys_addr_t align)
>> +{
>> +struct
[PATCH v3 1/3] arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86
AMD's next generation of EPYC processors support the MPK (Memory
Protection Keys) feature.
So, rename X86_INTEL_MEMORY_PROTECTION_KEYS to X86_MEMORY_PROTECTION_KEYS.
No functional changes.
AMD documentation for MPK feature is available at "AMD64 Architecture
Programmer’s Manual Volume 2: System Programming, Pub. 24593 Rev. 3.34,
Section 5.6.6 Memory Protection Keys (MPK) Bit". Documentation can be
obtained at the link below.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=206537
Signed-off-by: Babu Moger
---
Documentation/core-api/protection-keys.rst |3 ++-
arch/x86/Kconfig | 11 +--
arch/x86/include/asm/disabled-features.h |4 ++--
arch/x86/include/asm/mmu.h |2 +-
arch/x86/include/asm/mmu_context.h |4 ++--
arch/x86/include/asm/pgtable.h |4 ++--
arch/x86/include/asm/pgtable_types.h |2 +-
arch/x86/include/asm/special_insns.h |2 +-
arch/x86/include/uapi/asm/mman.h |2 +-
arch/x86/kernel/cpu/common.c |2 +-
arch/x86/mm/Makefile |2 +-
arch/x86/mm/pkeys.c|2 +-
scripts/headers_install.sh |2 +-
tools/arch/x86/include/asm/disabled-features.h |4 ++--
14 files changed, 27 insertions(+), 19 deletions(-)
diff --git a/Documentation/core-api/protection-keys.rst
b/Documentation/core-api/protection-keys.rst
index 49d9833af871..d25e89e53c59 100644
--- a/Documentation/core-api/protection-keys.rst
+++ b/Documentation/core-api/protection-keys.rst
@@ -6,7 +6,8 @@ Memory Protection Keys
Memory Protection Keys for Userspace (PKU aka PKEYs) is a feature
which is found on Intel's Skylake "Scalable Processor" Server CPUs.
-It will be avalable in future non-server parts.
+It will be available in future non-server parts. Also, AMD64
+Architecture Programmer’s Manual defines PKU feature in AMD processors.
For anyone wishing to test or use this feature, it is available in
Amazon's EC2 C5 instances and is known to work there using an Ubuntu
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 1197b5596d5a..b6f1686526eb 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1887,10 +1887,10 @@ config X86_UMIP
results are dummy.
config X86_INTEL_MEMORY_PROTECTION_KEYS
- prompt "Intel Memory Protection Keys"
+ prompt "Memory Protection Keys"
def_bool y
# Note: only available in 64-bit mode
- depends on CPU_SUP_INTEL && X86_64
+ depends on X86_64 && (CPU_SUP_INTEL || CPU_SUP_AMD)
select ARCH_USES_HIGH_VMA_FLAGS
select ARCH_HAS_PKEYS
---help---
@@ -1902,6 +1902,13 @@ config X86_INTEL_MEMORY_PROTECTION_KEYS
If unsure, say y.
+config X86_MEMORY_PROTECTION_KEYS
+ # Note: This is an intermediate change to avoid config prompt to
+ # the users. Eventually, the option X86_INTEL_MEMORY_PROTECTION_KEYS
+ # should be changed to X86_MEMORY_PROTECTION_KEYS permanently after
+ # few kernel revisions.
+ def_bool X86_INTEL_MEMORY_PROTECTION_KEYS
+
choice
prompt "TSX enable mode"
depends on CPU_SUP_INTEL
diff --git a/arch/x86/include/asm/disabled-features.h
b/arch/x86/include/asm/disabled-features.h
index 4ea8584682f9..52dbdfed8043 100644
--- a/arch/x86/include/asm/disabled-features.h
+++ b/arch/x86/include/asm/disabled-features.h
@@ -36,13 +36,13 @@
# define DISABLE_PCID (1<<(X86_FEATURE_PCID & 31))
#endif /* CONFIG_X86_64 */
-#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
+#ifdef CONFIG_X86_MEMORY_PROTECTION_KEYS
# define DISABLE_PKU 0
# define DISABLE_OSPKE 0
#else
# define DISABLE_PKU (1<<(X86_FEATURE_PKU & 31))
# define DISABLE_OSPKE (1<<(X86_FEATURE_OSPKE & 31))
-#endif /* CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS */
+#endif /* CONFIG_X86_MEMORY_PROTECTION_KEYS */
#ifdef CONFIG_X86_5LEVEL
# define DISABLE_LA57 0
diff --git a/arch/x86/include/asm/mmu.h b/arch/x86/include/asm/mmu.h
index bdeae9291e5c..351d22152709 100644
--- a/arch/x86/include/asm/mmu.h
+++ b/arch/x86/include/asm/mmu.h
@@ -42,7 +42,7 @@ typedef struct {
const struct vdso_image *vdso_image;/* vdso image in use */
atomic_t perf_rdpmc_allowed;/* nonzero if rdpmc is allowed */
-#ifdef CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS
+#ifdef CONFIG_X86_MEMORY_PROTECTION_KEYS
/*
* One bit per protection key says whether userspace can
* use it or not. protected by mmap_sem.
diff --git a/arch/x86/include/asm/mmu_context.h
b/arch/x86/include/asm/mmu_context.h
index 4e55370e48e8..33f4a7ccac5e 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -118,7 +118,7 @@ static inline int init_new_context(struct task_struct *tsk,
mm->context.ctx_id = atomic64_inc_return(_mm_ctx_id);
atomic64_set(>context.tlb_gen,
[PATCH v8 09/11] pstore/blk: Support non-block storage devices
From: WeiXiong Liao
Add support for non-block devices (e.g. MTD). A non-block driver calls
pstore_blk_register_device() to register iself.
In addition, pstore/zone is updated to handle non-block devices,
where an erase must be done before a write. Without this, there is no
way to remove records stored to an MTD.
Signed-off-by: WeiXiong Liao
Link:
https://lore.kernel.org/r/1585126506-18635-11-git-send-email-liaoweixi...@allwinnertech.com
Signed-off-by: Kees Cook
---
Documentation/admin-guide/pstore-blk.rst | 17 -
fs/pstore/blk.c | 94 +---
fs/pstore/zone.c | 8 +-
include/linux/pstore_blk.h | 38 ++
include/linux/pstore_zone.h | 6 ++
5 files changed, 115 insertions(+), 48 deletions(-)
diff --git a/Documentation/admin-guide/pstore-blk.rst
b/Documentation/admin-guide/pstore-blk.rst
index bef8c7436721..d45341e55e82 100644
--- a/Documentation/admin-guide/pstore-blk.rst
+++ b/Documentation/admin-guide/pstore-blk.rst
@@ -7,8 +7,8 @@ Introduction
pstore block (pstore/blk) is an oops/panic logger that writes its logs to a
-block device before the system crashes. You can get these log files by
-mounting pstore filesystem like::
+block device and non-block device before the system crashes. You can get
+these log files by mounting pstore filesystem like::
mount -t pstore pstore /sys/fs/pstore
@@ -24,8 +24,8 @@ Configurations for user determine how pstore/blk works, such
as pmsg_size,
kmsg_size and so on. All of them support both Kconfig and module parameters,
but module parameters have priority over Kconfig.
-Configurations for driver are all about block device, such as total_size
-of block device and read/write operations.
+Configurations for driver are all about block device and non-block device,
+such as total_size of block device and read/write operations.
Configurations for user
---
@@ -152,6 +152,15 @@ driver uses ``register_pstore_blk`` to register to
pstore/blk.
.. kernel-doc:: fs/pstore/blk.c
:identifiers: register_pstore_blk
+A non-block device driver uses ``register_pstore_device`` with
+``struct pstore_device_info`` to register to pstore/blk.
+
+.. kernel-doc:: fs/pstore/blk.c
+ :identifiers: register_pstore_device
+
+.. kernel-doc:: include/linux/pstore_blk.h
+ :identifiers: pstore_device_info
+
Compression and header
--
diff --git a/fs/pstore/blk.c b/fs/pstore/blk.c
index 95436cff8976..a1bd7c1fdfa0 100644
--- a/fs/pstore/blk.c
+++ b/fs/pstore/blk.c
@@ -105,55 +105,23 @@ struct bdev_info {
_##name_; \
})
-/**
- * struct pstore_device_info - back-end pstore/blk driver structure.
- *
- * @total_size: The total size in bytes pstore/blk can use. It must be greater
- * than 4096 and be multiple of 4096.
- * @flags: Refer to macro starting with PSTORE_FLAGS defined in
- * linux/pstore.h. It means what front-ends this device support.
- * Zero means all backends for compatible.
- * @read: The general read operation. Both of the function parameters
- * @size and @offset are relative value to bock device (not the
- * whole disk).
- * On success, the number of bytes should be returned, others
- * means error.
- * @write: The same as @read, but the following error number:
- * -EBUSY means try to write again later.
- * -ENOMSG means to try next zone.
- * @panic_write:The write operation only used for panic case. It's optional
- * if you do not care panic log. The parameters are relative
- * value to storage.
- * On success, the number of bytes should be returned, others
- * excluding -ENOMSG mean error. -ENOMSG means to try next zone.
- */
-struct pstore_device_info {
- unsigned long total_size;
- unsigned int flags;
- pstore_zone_read_op read;
- pstore_zone_write_op write;
- pstore_zone_write_op panic_write;
-};
-
-static int psblk_register_do(struct pstore_device_info *dev)
+static int __register_pstore_device(struct pstore_device_info *dev)
{
int ret;
- if (!dev || !dev->total_size || !dev->read || !dev->write)
+ if (WARN_ON(!mutex_is_locked(_blk_lock)))
return -EINVAL;
- mutex_lock(_blk_lock);
+ if (!dev || !dev->total_size || !dev->read || !dev->write)
+ return -EINVAL;
/* someone already registered before */
- if (pstore_zone_info) {
- mutex_unlock(_blk_lock);
+ if (pstore_zone_info)
return -EBUSY;
- }
+
pstore_zone_info = kzalloc(sizeof(struct pstore_zone_info), GFP_KERNEL);
- if (!pstore_zone_info) {
- mutex_unlock(_blk_lock);
+ if (!pstore_zone_info)
return -ENOMEM;
- }
[PATCH v3 0/3] arch/x86: Enable MPK feature on AMD
AMD's next generation of EPYC processors support the MPK (Memory Protection Keys) feature. AMD documentation for MPK feature is available at "AMD64 Architecture Programmer’s Manual Volume 2: System Programming, Pub. 24593 Rev. 3.34, Section 5.6.6 Memory Protection Keys (MPK) Bit". The documentation can be obtained at the link below: https://bugzilla.kernel.org/show_bug.cgi?id=206537 This series enables the feature on AMD and updates config parameters to reflect the MPK support on generic x86 platforms. --- v3: - Fixed the problem Jim Mattson pointed out which can cause pkru resources to get corrupted during host and guest switches. - Moved the PKU feature detection code from VMX.c to common code. v2: https://lore.kernel.org/lkml/158897190718.22378.3974700869904223395.st...@naples-babu.amd.com/ - Introduced intermediate config option X86_MEMORY_PROTECTION_KEYS to avoid user propmpts. Kept X86_INTEL_MEMORY_PROTECTION_KEYS as is. Eventually, we will be moving to X86_MEMORY_PROTECTION_KEYS after couple of kernel revisions. - Moved pkru data structures to kvm_vcpu_arch. Moved save/restore pkru to kvm_load_host_xsave_state/kvm_load_guest_xsave_state. v1: https://lore.kernel.org/lkml/158880240546.11615.2219410169137148044.st...@naples-babu.amd.com/ Babu Moger (3): arch/x86: Rename config X86_INTEL_MEMORY_PROTECTION_KEYS to generic x86 KVM: x86: Move pkru save/restore to x86.c KVM: x86: Move MPK feature detection to common code Documentation/core-api/protection-keys.rst |3 ++- arch/x86/Kconfig | 11 +-- arch/x86/include/asm/disabled-features.h |4 ++-- arch/x86/include/asm/kvm_host.h|1 + arch/x86/include/asm/mmu.h |2 +- arch/x86/include/asm/mmu_context.h |4 ++-- arch/x86/include/asm/pgtable.h |4 ++-- arch/x86/include/asm/pgtable_types.h |2 +- arch/x86/include/asm/special_insns.h |2 +- arch/x86/include/uapi/asm/mman.h |2 +- arch/x86/kernel/cpu/common.c |2 +- arch/x86/kvm/cpuid.c |4 +++- arch/x86/kvm/vmx/vmx.c | 22 -- arch/x86/kvm/x86.c | 17 + arch/x86/mm/Makefile |2 +- arch/x86/mm/pkeys.c|2 +- scripts/headers_install.sh |2 +- tools/arch/x86/include/asm/disabled-features.h |4 ++-- 18 files changed, 48 insertions(+), 42 deletions(-) --
[PATCH v8 04/11] pstore/zone,blk: Add console frontend support
From: WeiXiong Liao
Support backend for console. To enable console backend, just make
console_size be greater than 0 and a multiple of 4096.
Signed-off-by: WeiXiong Liao
Link:
https://lore.kernel.org/r/1585126506-18635-6-git-send-email-liaoweixi...@allwinnertech.com
Signed-off-by: Kees Cook
---
fs/pstore/Kconfig | 18 +++--
fs/pstore/blk.c | 12 +-
fs/pstore/zone.c| 81 ++---
include/linux/pstore_zone.h | 4 +-
4 files changed, 105 insertions(+), 10 deletions(-)
diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index ef01c48f0ff7..126aa6c3ecf2 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -180,11 +180,11 @@ config PSTORE_BLK_BLKDEV
help
Which block device should be used for pstore/blk.
- It accept the following variants:
+ It accepts the following variants:
1) device number in hexadecimal representation,
with no leading 0x, for example b302.
- 2) /dev/ represents the device number of disk
- 3) /dev/ represents the device number
+ 2) /dev/ represents the device name of disk
+ 3) /dev/ represents the device name and number
of partition - device number of disk plus the partition number
4) /dev/p - same as the above, this form is
used when disk name of partitioned disk ends with a digit.
@@ -236,3 +236,15 @@ config PSTORE_BLK_PMSG_SIZE
NOTE that, both Kconfig and module parameters can configure
pstore/blk, but module parameters have priority over Kconfig.
+
+config PSTORE_BLK_CONSOLE_SIZE
+ int "Size in Kbytes of console log to store"
+ depends on PSTORE_BLK
+ depends on PSTORE_CONSOLE
+ default 64
+ help
+ This just sets size of console log (console_size) to store via
+ pstore/blk. The size is in KB and must be a multiple of 4.
+
+ NOTE that, both Kconfig and module parameters can configure
+ pstore/blk, but module parameters have priority over Kconfig.
diff --git a/fs/pstore/blk.c b/fs/pstore/blk.c
index e3fa29988b0f..0b88c0bcd36c 100644
--- a/fs/pstore/blk.c
+++ b/fs/pstore/blk.c
@@ -35,6 +35,14 @@ static long pmsg_size = -1;
module_param(pmsg_size, long, 0400);
MODULE_PARM_DESC(pmsg_size, "pmsg size in kbytes");
+#if IS_ENABLED(CONFIG_PSTORE_CONSOLE)
+static long console_size = CONFIG_PSTORE_BLK_CONSOLE_SIZE;
+#else
+static long console_size = -1;
+#endif
+module_param(console_size, long, 0400);
+MODULE_PARM_DESC(console_size, "console size in kbytes");
+
/*
* blkdev - the block device to use for pstore storage
*
@@ -91,7 +99,8 @@ struct bdev_info {
* whole disk).
* On success, the number of bytes should be returned, others
* means error.
- * @write: The same as @read.
+ * @write: The same as @read, but the following error number:
+ * -EBUSY means try to write again later.
* @panic_write:The write operation only used for panic case. It's optional
* if you do not care panic log. The parameters and return value
* are the same as @read.
@@ -142,6 +151,7 @@ static int psblk_register_do(struct pstore_device_info *dev)
verify_size(kmsg_size, 4096, dev->flags & PSTORE_FLAGS_DMESG);
verify_size(pmsg_size, 4096, dev->flags & PSTORE_FLAGS_PMSG);
+ verify_size(console_size, 4096, dev->flags & PSTORE_FLAGS_CONSOLE);
#undef verify_size
pstore_zone_info->total_size = dev->total_size;
diff --git a/fs/pstore/zone.c b/fs/pstore/zone.c
index fe6fde96d722..33c99dc5f980 100644
--- a/fs/pstore/zone.c
+++ b/fs/pstore/zone.c
@@ -91,10 +91,12 @@ struct pstore_zone {
*
* @kpszs: kmsg dump storage zones
* @ppsz: pmsg storage zone
+ * @cpsz: console storage zone
* @kmsg_max_cnt: max count of @kpszs
* @kmsg_read_cnt: counter of total read kmsg dumps
* @kmsg_write_cnt: counter of total kmsg dump writes
* @pmsg_read_cnt: counter of total read pmsg zone
+ * @console_read_cnt: counter of total read console zone
* @oops_counter: counter of oops dumps
* @panic_counter: counter of panic dumps
* @recovered: whether finished recovering data from storage
@@ -106,10 +108,12 @@ struct pstore_zone {
struct psz_context {
struct pstore_zone **kpszs;
struct pstore_zone *ppsz;
+ struct pstore_zone *cpsz;
unsigned int kmsg_max_cnt;
unsigned int kmsg_read_cnt;
unsigned int kmsg_write_cnt;
unsigned int pmsg_read_cnt;
+ unsigned int console_read_cnt;
/*
* These counters should be calculated during recovery.
* It records the oops/panic times after crashes rather than boots.
@@ -129,6 +133,9 @@ struct psz_context {
};
static struct psz_context pstore_zone_cxt;
+static void psz_flush_all_dirty_zones(struct work_struct *);
+static DECLARE_DELAYED_WORK(psz_cleaner, psz_flush_all_dirty_zones);
+
/**
* enum
[PATCH v8 03/11] pstore/zone,blk: Add support for pmsg frontend
From: WeiXiong Liao
Add pmsg support to pstore/blk (through pstore/zone). To enable, pmsg_size
must be greater than 0 and a multiple of 4096.
Signed-off-by: WeiXiong Liao
Link:
https://lore.kernel.org/r/1585126506-18635-5-git-send-email-liaoweixi...@allwinnertech.com
Signed-off-by: Kees Cook
---
fs/pstore/Kconfig | 12 ++
fs/pstore/blk.c | 9 ++
fs/pstore/zone.c| 265 ++--
include/linux/pstore_zone.h | 2 +
4 files changed, 279 insertions(+), 9 deletions(-)
diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index 958bec75f907..ef01c48f0ff7 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -224,3 +224,15 @@ config PSTORE_BLK_MAX_REASON
NOTE that, both Kconfig and module parameters can configure
pstore/blk, but module parameters have priority over Kconfig.
+
+config PSTORE_BLK_PMSG_SIZE
+ int "Size in Kbytes of pmsg to store"
+ depends on PSTORE_BLK
+ depends on PSTORE_PMSG
+ default 64
+ help
+ This just sets size of pmsg (pmsg_size) for pstore/blk. The size is
+ in KB and must be a multiple of 4.
+
+ NOTE that, both Kconfig and module parameters can configure
+ pstore/blk, but module parameters have priority over Kconfig.
diff --git a/fs/pstore/blk.c b/fs/pstore/blk.c
index 6490c60af0dc..e3fa29988b0f 100644
--- a/fs/pstore/blk.c
+++ b/fs/pstore/blk.c
@@ -27,6 +27,14 @@ module_param(max_reason, int, 0400);
MODULE_PARM_DESC(max_reason,
"maximum reason for kmsg dump (default 2: Oops and Panic)");
+#if IS_ENABLED(CONFIG_PSTORE_PMSG)
+static long pmsg_size = CONFIG_PSTORE_BLK_PMSG_SIZE;
+#else
+static long pmsg_size = -1;
+#endif
+module_param(pmsg_size, long, 0400);
+MODULE_PARM_DESC(pmsg_size, "pmsg size in kbytes");
+
/*
* blkdev - the block device to use for pstore storage
*
@@ -133,6 +141,7 @@ static int psblk_register_do(struct pstore_device_info *dev)
}
verify_size(kmsg_size, 4096, dev->flags & PSTORE_FLAGS_DMESG);
+ verify_size(pmsg_size, 4096, dev->flags & PSTORE_FLAGS_PMSG);
#undef verify_size
pstore_zone_info->total_size = dev->total_size;
diff --git a/fs/pstore/zone.c b/fs/pstore/zone.c
index 20fa52385c78..fe6fde96d722 100644
--- a/fs/pstore/zone.c
+++ b/fs/pstore/zone.c
@@ -27,12 +27,14 @@
*
* @sig: signature to indicate header (PSZ_SIG xor PSZONE-type value)
* @datalen: length of data in @data
+ * @start: offset into @data where the beginning of the stored bytes begin
* @data: zone data.
*/
struct psz_buffer {
#define PSZ_SIG (0x43474244) /* DBGC */
uint32_t sig;
atomic_t datalen;
+ atomic_t start;
uint8_t data[];
};
@@ -88,9 +90,11 @@ struct pstore_zone {
* struct psz_context - all about running state of pstore/zone
*
* @kpszs: kmsg dump storage zones
+ * @ppsz: pmsg storage zone
* @kmsg_max_cnt: max count of @kpszs
* @kmsg_read_cnt: counter of total read kmsg dumps
* @kmsg_write_cnt: counter of total kmsg dump writes
+ * @pmsg_read_cnt: counter of total read pmsg zone
* @oops_counter: counter of oops dumps
* @panic_counter: counter of panic dumps
* @recovered: whether finished recovering data from storage
@@ -101,9 +105,11 @@ struct pstore_zone {
*/
struct psz_context {
struct pstore_zone **kpszs;
+ struct pstore_zone *ppsz;
unsigned int kmsg_max_cnt;
unsigned int kmsg_read_cnt;
unsigned int kmsg_write_cnt;
+ unsigned int pmsg_read_cnt;
/*
* These counters should be calculated during recovery.
* It records the oops/panic times after crashes rather than boots.
@@ -143,15 +149,20 @@ static inline int buffer_datalen(struct pstore_zone *zone)
return atomic_read(>buffer->datalen);
}
+static inline int buffer_start(struct pstore_zone *zone)
+{
+ return atomic_read(>buffer->start);
+}
+
static inline bool is_on_panic(void)
{
return atomic_read(_zone_cxt.on_panic);
}
-static ssize_t psz_zone_read(struct pstore_zone *zone, char *buf,
+static ssize_t psz_zone_read_buffer(struct pstore_zone *zone, char *buf,
size_t len, unsigned long off)
{
- if (!buf || !zone->buffer)
+ if (!buf || !zone || !zone->buffer)
return -EINVAL;
if (off > zone->buffer_size)
return -EINVAL;
@@ -160,6 +171,18 @@ static ssize_t psz_zone_read(struct pstore_zone *zone,
char *buf,
return len;
}
+static int psz_zone_read_oldbuf(struct pstore_zone *zone, char *buf,
+ size_t len, unsigned long off)
+{
+ if (!buf || !zone || !zone->oldbuf)
+ return -EINVAL;
+ if (off > zone->buffer_size)
+ return -EINVAL;
+ len = min_t(size_t, len, zone->buffer_size - off);
+ memcpy(buf, zone->oldbuf->data + off, len);
+ return 0;
+}
+
static int psz_zone_write(struct pstore_zone *zone,
enum
[PATCH v8 10/11] mtd: Support kmsg dumper based on pstore/blk
From: WeiXiong Liao
This introduces mtdpstore, which is similar to mtdoops but more
powerful. It uses pstore/blk, and aims to store panic and oops logs to
a flash partition, where pstore can later read back and present as files
in the mounted pstore filesystem.
To make mtdpstore work, the "blkdev" of pstore/blk should be set
as MTD device name or MTD device number. For more details, see
Documentation/admin-guide/pstore-blk.rst
This solves a number of issues:
- Work duplication: both of pstore and mtdoops do the same job storing
panic/oops log. They have very similar logic, registering to kmsg
dumper and storing logs to several chunks one by one.
- Layer violations: drivers should provides methods instead of polices.
MTD should provide read/write/erase operations, and allow a higher
level drivers to provide the chunk management, kmsg dump
configuration, etc.
- Missing features: pstore provides many additional features, including
presenting the logs as files, logging dump time and count, and
supporting other frontends like pmsg, console, etc.
Signed-off-by: WeiXiong Liao
Link:
https://lore.kernel.org/r/1585126506-18635-12-git-send-email-liaoweixi...@allwinnertech.com
Signed-off-by: Kees Cook
---
Documentation/admin-guide/pstore-blk.rst | 9 +-
drivers/mtd/Kconfig | 10 +
drivers/mtd/Makefile | 1 +
drivers/mtd/mtdpstore.c | 563 +++
4 files changed, 581 insertions(+), 2 deletions(-)
create mode 100644 drivers/mtd/mtdpstore.c
diff --git a/Documentation/admin-guide/pstore-blk.rst
b/Documentation/admin-guide/pstore-blk.rst
index d45341e55e82..296d5027787a 100644
--- a/Documentation/admin-guide/pstore-blk.rst
+++ b/Documentation/admin-guide/pstore-blk.rst
@@ -43,9 +43,9 @@ blkdev
~~
The block device to use. Most of the time, it is a partition of block device.
-It's required for pstore/blk.
+It's required for pstore/blk. It is also used for MTD device.
-It accepts the following variants:
+It accepts the following variants for block device:
1. device number in hexadecimal represents itself; no
leading 0x, for example b302.
@@ -64,6 +64,11 @@ It accepts the following variants:
partition with a known unique id.
#. : major and minor number of the device separated by a colon.
+It accepts the following variants for MTD device:
+
+1. MTD device name. "pstore" is recommended.
+#. MTD device number.
+
kmsg_size
~
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index 42d401ea60ee..6ddab796216d 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -170,6 +170,16 @@ config MTD_OOPS
buffer in a flash partition where it can be read back at some
later point.
+config MTD_PSTORE
+ tristate "Log panic/oops to an MTD buffer based on pstore"
+ depends on PSTORE_BLK
+ help
+ This enables panic and oops messages to be logged to a circular
+ buffer in a flash partition where it can be read back as files after
+ mounting pstore filesystem.
+
+ If unsure, say N.
+
config MTD_SWAP
tristate "Swap on MTD device support"
depends on MTD && SWAP
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 56cc60ccc477..593d0593a038 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_RFD_FTL) += rfd_ftl.o
obj-$(CONFIG_SSFDC)+= ssfdc.o
obj-$(CONFIG_SM_FTL) += sm_ftl.o
obj-$(CONFIG_MTD_OOPS) += mtdoops.o
+obj-$(CONFIG_MTD_PSTORE) += mtdpstore.o
obj-$(CONFIG_MTD_SWAP) += mtdswap.o
nftl-objs := nftlcore.o nftlmount.o
diff --git a/drivers/mtd/mtdpstore.c b/drivers/mtd/mtdpstore.c
new file mode 100644
index ..06084eff1004
--- /dev/null
+++ b/drivers/mtd/mtdpstore.c
@@ -0,0 +1,563 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#define dev_fmt(fmt) "mtdoops-pstore: " fmt
+
+#include
+#include
+#include
+#include
+#include
+
+static struct mtdpstore_context {
+ int index;
+ struct pstore_blk_config info;
+ struct pstore_device_info dev;
+ struct mtd_info *mtd;
+ unsigned long *rmmap; /* removed bit map */
+ unsigned long *usedmap; /* used bit map */
+ /*
+* used for panic write
+* As there are no block_isbad for panic case, we should keep this
+* status before panic to ensure panic_write not failed.
+*/
+ unsigned long *badmap; /* bad block bit map */
+} oops_cxt;
+
+static int mtdpstore_block_isbad(struct mtdpstore_context *cxt, loff_t off)
+{
+ int ret;
+ struct mtd_info *mtd = cxt->mtd;
+ u64 blknum = div_u64(off, mtd->erasesize);
+
+ if (test_bit(blknum, cxt->badmap))
+ return true;
+ ret = mtd_block_isbad(mtd, off);
+ if (ret < 0) {
+ dev_err(>dev, "mtd_block_isbad failed, aborting\n");
+
[PATCH v8 01/11] pstore/zone: Introduce common layer to manage storage zones
From: WeiXiong Liao
Implement a common set of APIs needed to support pstore storage zones,
based on how ramoops is designed. This will be used by pstore/blk with
the intention of migrating pstore/ram in the future.
Signed-off-by: WeiXiong Liao
Link:
https://lore.kernel.org/r/1585126506-18635-2-git-send-email-liaoweixi...@allwinnertech.com
Co-developed-by: Kees Cook
Signed-off-by: Kees Cook
---
fs/pstore/Kconfig | 7 +
fs/pstore/Makefile | 3 +
fs/pstore/zone.c| 987
include/linux/pstore_zone.h | 44 ++
4 files changed, 1041 insertions(+)
create mode 100644 fs/pstore/zone.c
create mode 100644 include/linux/pstore_zone.h
diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index 8f0369aad22a..98d2457bdd9f 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -153,3 +153,10 @@ config PSTORE_RAM
"ramoops.ko".
For more information, see Documentation/admin-guide/ramoops.rst.
+
+config PSTORE_ZONE
+ tristate
+ depends on PSTORE
+ help
+ The common layer for pstore/blk (and pstore/ram in the future)
+ to manage storage in zones.
diff --git a/fs/pstore/Makefile b/fs/pstore/Makefile
index 967b5891f325..58a967cbe4af 100644
--- a/fs/pstore/Makefile
+++ b/fs/pstore/Makefile
@@ -12,3 +12,6 @@ pstore-$(CONFIG_PSTORE_PMSG) += pmsg.o
ramoops-objs += ram.o ram_core.o
obj-$(CONFIG_PSTORE_RAM) += ramoops.o
+
+pstore_zone-objs += zone.o
+obj-$(CONFIG_PSTORE_ZONE) += pstore_zone.o
diff --git a/fs/pstore/zone.c b/fs/pstore/zone.c
new file mode 100644
index ..20fa52385c78
--- /dev/null
+++ b/fs/pstore/zone.c
@@ -0,0 +1,987 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Provide a pstore intermediate backend, organized into kernel memory
+ * allocated zones that are then mapped and flushed into a single
+ * contiguous region on a storage backend of some kind (block, mtd, etc).
+ */
+
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "internal.h"
+
+/**
+ * struct psz_head - header of zone to flush to storage
+ *
+ * @sig: signature to indicate header (PSZ_SIG xor PSZONE-type value)
+ * @datalen: length of data in @data
+ * @data: zone data.
+ */
+struct psz_buffer {
+#define PSZ_SIG (0x43474244) /* DBGC */
+ uint32_t sig;
+ atomic_t datalen;
+ uint8_t data[];
+};
+
+/**
+ * struct psz_kmsg_header - kmsg dump-specific header to flush to storage
+ *
+ * @magic: magic num for kmsg dump header
+ * @time: kmsg dump trigger time
+ * @compressed: whether conpressed
+ * @counter: kmsg dump counter
+ * @reason: the kmsg dump reason (e.g. oops, panic, etc)
+ * @data: pointer to log data
+ *
+ * This is a sub-header for a kmsg dump, trailing after _buffer.
+ */
+struct psz_kmsg_header {
+#define PSTORE_KMSG_HEADER_MAGIC 0x4dfc3ae5 /* Just a random number */
+ uint32_t magic;
+ struct timespec64 time;
+ bool compressed;
+ uint32_t counter;
+ enum kmsg_dump_reason reason;
+ uint8_t data[];
+};
+
+/**
+ * struct pstore_zone - single stored buffer
+ *
+ * @off: zone offset of storage
+ * @type: front-end type for this zone
+ * @name: front-end name for this zone
+ * @buffer: pointer to data buffer managed by this zone
+ * @oldbuf: pointer to old data buffer
+ * @buffer_size: bytes in @buffer->data
+ * @should_recover: whether this zone should recover from storage
+ * @dirty: whether the data in @buffer dirty
+ *
+ * zone structure in memory.
+ */
+struct pstore_zone {
+ loff_t off;
+ const char *name;
+ enum pstore_type_id type;
+
+ struct psz_buffer *buffer;
+ struct psz_buffer *oldbuf;
+ size_t buffer_size;
+ bool should_recover;
+ atomic_t dirty;
+};
+
+/**
+ * struct psz_context - all about running state of pstore/zone
+ *
+ * @kpszs: kmsg dump storage zones
+ * @kmsg_max_cnt: max count of @kpszs
+ * @kmsg_read_cnt: counter of total read kmsg dumps
+ * @kmsg_write_cnt: counter of total kmsg dump writes
+ * @oops_counter: counter of oops dumps
+ * @panic_counter: counter of panic dumps
+ * @recovered: whether finished recovering data from storage
+ * @on_panic: whether panic is happening
+ * @pstore_zone_info_lock: lock to @pstore_zone_info
+ * @pstore_zone_info: information from backend
+ * @pstore: structure for pstore
+ */
+struct psz_context {
+ struct pstore_zone **kpszs;
+ unsigned int kmsg_max_cnt;
+ unsigned int kmsg_read_cnt;
+ unsigned int kmsg_write_cnt;
+ /*
+* These counters should be calculated during recovery.
+* It records the oops/panic times after crashes rather than boots.
+*/
+ unsigned int oops_counter;
+ unsigned int panic_counter;
+ atomic_t recovered;
+ atomic_t on_panic;
+
+ /*
+* pstore_zone_info_lock protects
[PATCH v8 06/11] Documentation: Add details for pstore/blk
From: WeiXiong Liao Add details on using pstore/blk, the new backend of pstore to record dumps to block devices, in Documentation/admin-guide/pstore-blk.rst Signed-off-by: WeiXiong Liao Link: https://lore.kernel.org/r/1585126506-18635-8-git-send-email-liaoweixi...@allwinnertech.com Signed-off-by: Kees Cook --- Documentation/admin-guide/pstore-blk.rst | 229 +++ MAINTAINERS | 1 + fs/pstore/Kconfig| 2 + 3 files changed, 232 insertions(+) create mode 100644 Documentation/admin-guide/pstore-blk.rst diff --git a/Documentation/admin-guide/pstore-blk.rst b/Documentation/admin-guide/pstore-blk.rst new file mode 100644 index ..bef8c7436721 --- /dev/null +++ b/Documentation/admin-guide/pstore-blk.rst @@ -0,0 +1,229 @@ +.. SPDX-License-Identifier: GPL-2.0 + +pstore block oops/panic logger +== + +Introduction + + +pstore block (pstore/blk) is an oops/panic logger that writes its logs to a +block device before the system crashes. You can get these log files by +mounting pstore filesystem like:: + +mount -t pstore pstore /sys/fs/pstore + + +pstore block concepts +- + +pstore/blk provides efficient configuration method for pstore/blk, which +divides all configurations into two parts, configurations for user and +configurations for driver. + +Configurations for user determine how pstore/blk works, such as pmsg_size, +kmsg_size and so on. All of them support both Kconfig and module parameters, +but module parameters have priority over Kconfig. + +Configurations for driver are all about block device, such as total_size +of block device and read/write operations. + +Configurations for user +--- + +All of these configurations support both Kconfig and module parameters, but +module parameters have priority over Kconfig. + +Here is an example for module parameters:: + +pstore_blk.blkdev=179:7 pstore_blk.kmsg_size=64 + +The detail of each configurations may be of interest to you. + +blkdev +~~ + +The block device to use. Most of the time, it is a partition of block device. +It's required for pstore/blk. + +It accepts the following variants: + +1. device number in hexadecimal represents itself; no + leading 0x, for example b302. +#. /dev/ represents the device number of disk +#. /dev/ represents the device number of partition - device + number of disk plus the partition number +#. /dev/p - same as the above; this form is used when disk + name of partitioned disk ends with a digit. +#. PARTUUID=00112233-4455-6677-8899-AABBCCDDEEFF represents the unique id of + a partition if the partition table provides it. The UUID may be either an + EFI/GPT UUID, or refer to an MSDOS partition using the format -PP, + where is a zero-filled hex representation of the 32-bit + "NT disk signature", and PP is a zero-filled hex representation of the + 1-based partition number. +#. PARTUUID=/PARTNROFF= to select a partition in relation to a + partition with a known unique id. +#. : major and minor number of the device separated by a colon. + +kmsg_size +~ + +The chunk size in KB for oops/panic front-end. It **MUST** be a multiple of 4. +It's optional if you do not care oops/panic log. + +There are multiple chunks for oops/panic front-end depending on the remaining +space except other pstore front-ends. + +pstore/blk will log to oops/panic chunks one by one, and always overwrite the +oldest chunk if there is no more free chunk. + +pmsg_size +~ + +The chunk size in KB for pmsg front-end. It **MUST** be a multiple of 4. +It's optional if you do not care pmsg log. + +Unlike oops/panic front-end, there is only one chunk for pmsg front-end. + +Pmsg is a user space accessible pstore object. Writes to */dev/pmsg0* are +appended to the chunk. On reboot the contents are available in +*/sys/fs/pstore/pmsg-pstore-blk-0*. + +console_size + + +The chunk size in KB for console front-end. It **MUST** be a multiple of 4. +It's optional if you do not care console log. + +Similar to pmsg front-end, there is only one chunk for console front-end. + +All log of console will be appended to the chunk. On reboot the contents are +available in */sys/fs/pstore/console-pstore-blk-0*. + +ftrace_size +~~~ + +The chunk size in KB for ftrace front-end. It **MUST** be a multiple of 4. +It's optional if you do not care console log. + +Similar to oops front-end, there are multiple chunks for ftrace front-end +depending on the count of cpu processors. Each chunk size is equal to +ftrace_size / processors_count. + +All log of ftrace will be appended to the chunk. On reboot the contents are +combined and available in */sys/fs/pstore/ftrace-pstore-blk-0*. + +Persistent function tracing might be useful for debugging software or hardware +related hangs. Here is an example of usage:: + + # mount -t pstore pstore /sys/fs/pstore
[PATCH v8 00/11] pstore: mtd: support crash log to block and mtd device
Hi, After some small fixes, here's v8. :) Thanks! -Kees v8: - oops -> kmsg dump (WeiXiong) - typo/language fixes (Randy) - fix bdev failure paths (WeiXiong) - fix dev_err() -> pr_err (WeiXiong) v7: https://lore.kernel.org/lkml/20200510202436.63222-1-keesc...@chromium.org/ v6: https://lore.kernel.org/lkml/20200509234103.46544-1-keesc...@chromium.org/ v5: https://lore.kernel.org/lkml/1589022854-19821-1-git-send-email-liaoweixi...@allwinnertech.com/ v4: https://lore.kernel.org/lkml/20200508064004.57898-1-keesc...@chromium.org/ v3: https://lore.kernel.org/lkml/1585126506-18635-1-git-send-email-liaoweixi...@allwinnertech.com/ v2: https://lore.kernel.org/lkml/1581078355-19647-1-git-send-email-liaoweixi...@allwinnertech.com/ v1: https://lore.kernel.org/lkml/1579482233-2672-1-git-send-email-liaoweixi...@allwinnertech.com/ Kees Cook (1): pstore/blk: Introduce "best_effort" mode WeiXiong Liao (10): pstore/zone: Introduce common layer to manage storage zones pstore/blk: Introduce backend for block devices pstore/zone,blk: Add support for pmsg frontend pstore/zone,blk: Add console frontend support pstore/zone,blk: Add ftrace frontend support Documentation: Add details for pstore/blk pstore/zone: Provide way to skip "broken" zone for MTD devices pstore/blk: Provide way to query pstore configuration pstore/blk: Support non-block storage devices mtd: Support kmsg dumper based on pstore/blk Documentation/admin-guide/pstore-blk.rst | 243 MAINTAINERS |1 + drivers/mtd/Kconfig | 10 + drivers/mtd/Makefile |1 + drivers/mtd/mtdpstore.c | 563 + fs/pstore/Kconfig| 109 ++ fs/pstore/Makefile |6 + fs/pstore/blk.c | 521 fs/pstore/zone.c | 1463 ++ include/linux/pstore_blk.h | 118 ++ include/linux/pstore_zone.h | 60 + 11 files changed, 3095 insertions(+) create mode 100644 Documentation/admin-guide/pstore-blk.rst create mode 100644 drivers/mtd/mtdpstore.c create mode 100644 fs/pstore/blk.c create mode 100644 fs/pstore/zone.c create mode 100644 include/linux/pstore_blk.h create mode 100644 include/linux/pstore_zone.h -- 2.20.1
[PATCH v8 11/11] pstore/blk: Introduce "best_effort" mode
In order to use arbitrary block devices as a pstore backend, provide a
new module param named "best_effort", which will allow using any block
device, even if it has not provided a panic_write callback.
Signed-off-by: Kees Cook
---
fs/pstore/blk.c | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/fs/pstore/blk.c b/fs/pstore/blk.c
index a1bd7c1fdfa0..9000d2e9f1c5 100644
--- a/fs/pstore/blk.c
+++ b/fs/pstore/blk.c
@@ -51,6 +51,10 @@ static long ftrace_size = -1;
module_param(ftrace_size, long, 0400);
MODULE_PARM_DESC(ftrace_size, "ftrace size in kbytes");
+static bool best_effort;
+module_param(best_effort, bool, 0400);
+MODULE_PARM_DESC(best_effort, "use best effort to write (i.e. do not require
storage driver pstore support, default: off)");
+
/*
* blkdev - the block device to use for pstore storage
*
@@ -378,7 +382,8 @@ static int __register_pstore_blk(struct pstore_blk_info
*info)
}
/* only allow driver matching the @blkdev */
- if (!binfo.devt || MAJOR(binfo.devt) != info->major) {
+ if (!binfo.devt || (!best_effort &&
+ MAJOR(binfo.devt) != info->major)) {
pr_debug("invalid major %u (expect %u)\n",
info->major, MAJOR(binfo.devt));
ret = -ENODEV;
@@ -480,6 +485,20 @@ int pstore_blk_get_config(struct pstore_blk_config *info)
}
EXPORT_SYMBOL_GPL(pstore_blk_get_config);
+static int __init pstore_blk_init(void)
+{
+ struct pstore_blk_info info = { };
+ int ret = 0;
+
+ mutex_lock(_blk_lock);
+ if (!pstore_zone_info && best_effort && blkdev[0])
+ ret = __register_pstore_blk();
+ mutex_unlock(_blk_lock);
+
+ return ret;
+}
+late_initcall(pstore_blk_init);
+
static void __exit pstore_blk_exit(void)
{
mutex_lock(_blk_lock);
--
2.20.1
[PATCH v8 05/11] pstore/zone,blk: Add ftrace frontend support
From: WeiXiong Liao
Support backend for ftrace. To enable ftrace backend, just make
ftrace_size be greater than 0 and a multiple of 4096.
Signed-off-by: WeiXiong Liao
Link:
https://lore.kernel.org/r/1585126506-18635-7-git-send-email-liaoweixi...@allwinnertech.com
Signed-off-by: Kees Cook
---
fs/pstore/Kconfig | 12
fs/pstore/blk.c | 9 +++
fs/pstore/zone.c| 113 +++-
include/linux/pstore_zone.h | 2 +
4 files changed, 135 insertions(+), 1 deletion(-)
diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig
index 126aa6c3ecf2..c2237984b407 100644
--- a/fs/pstore/Kconfig
+++ b/fs/pstore/Kconfig
@@ -248,3 +248,15 @@ config PSTORE_BLK_CONSOLE_SIZE
NOTE that, both Kconfig and module parameters can configure
pstore/blk, but module parameters have priority over Kconfig.
+
+config PSTORE_BLK_FTRACE_SIZE
+ int "Size in Kbytes of ftrace log to store"
+ depends on PSTORE_BLK
+ depends on PSTORE_FTRACE
+ default 64
+ help
+ This just sets size of ftrace log (ftrace_size) for pstore/blk. The
+ size is in KB and must be a multiple of 4.
+
+ NOTE that, both Kconfig and module parameters can configure
+ pstore/blk, but module parameters have priority over Kconfig.
diff --git a/fs/pstore/blk.c b/fs/pstore/blk.c
index 0b88c0bcd36c..9f1f0d5b3795 100644
--- a/fs/pstore/blk.c
+++ b/fs/pstore/blk.c
@@ -43,6 +43,14 @@ static long console_size = -1;
module_param(console_size, long, 0400);
MODULE_PARM_DESC(console_size, "console size in kbytes");
+#if IS_ENABLED(CONFIG_PSTORE_FTRACE)
+static long ftrace_size = CONFIG_PSTORE_BLK_FTRACE_SIZE;
+#else
+static long ftrace_size = -1;
+#endif
+module_param(ftrace_size, long, 0400);
+MODULE_PARM_DESC(ftrace_size, "ftrace size in kbytes");
+
/*
* blkdev - the block device to use for pstore storage
*
@@ -152,6 +160,7 @@ static int psblk_register_do(struct pstore_device_info *dev)
verify_size(kmsg_size, 4096, dev->flags & PSTORE_FLAGS_DMESG);
verify_size(pmsg_size, 4096, dev->flags & PSTORE_FLAGS_PMSG);
verify_size(console_size, 4096, dev->flags & PSTORE_FLAGS_CONSOLE);
+ verify_size(ftrace_size, 4096, dev->flags & PSTORE_FLAGS_FTRACE);
#undef verify_size
pstore_zone_info->total_size = dev->total_size;
diff --git a/fs/pstore/zone.c b/fs/pstore/zone.c
index 33c99dc5f980..d83b24f3cdd9 100644
--- a/fs/pstore/zone.c
+++ b/fs/pstore/zone.c
@@ -92,11 +92,14 @@ struct pstore_zone {
* @kpszs: kmsg dump storage zones
* @ppsz: pmsg storage zone
* @cpsz: console storage zone
+ * @fpszs: ftrace storage zones
* @kmsg_max_cnt: max count of @kpszs
* @kmsg_read_cnt: counter of total read kmsg dumps
* @kmsg_write_cnt: counter of total kmsg dump writes
* @pmsg_read_cnt: counter of total read pmsg zone
* @console_read_cnt: counter of total read console zone
+ * @ftrace_max_cnt: max count of @fpszs
+ * @ftrace_read_cnt: counter of max read ftrace zone
* @oops_counter: counter of oops dumps
* @panic_counter: counter of panic dumps
* @recovered: whether finished recovering data from storage
@@ -109,11 +112,14 @@ struct psz_context {
struct pstore_zone **kpszs;
struct pstore_zone *ppsz;
struct pstore_zone *cpsz;
+ struct pstore_zone **fpszs;
unsigned int kmsg_max_cnt;
unsigned int kmsg_read_cnt;
unsigned int kmsg_write_cnt;
unsigned int pmsg_read_cnt;
unsigned int console_read_cnt;
+ unsigned int ftrace_max_cnt;
+ unsigned int ftrace_read_cnt;
/*
* These counters should be calculated during recovery.
* It records the oops/panic times after crashes rather than boots.
@@ -314,6 +320,8 @@ static void psz_flush_all_dirty_zones(struct work_struct
*work)
ret |= psz_flush_dirty_zone(cxt->cpsz);
if (cxt->kpszs)
ret |= psz_flush_dirty_zones(cxt->kpszs, cxt->kmsg_max_cnt);
+ if (cxt->fpszs)
+ ret |= psz_flush_dirty_zones(cxt->fpszs, cxt->ftrace_max_cnt);
if (ret && cxt->pstore_zone_info)
schedule_delayed_work(_cleaner, msecs_to_jiffies(1000));
}
@@ -550,6 +558,31 @@ static int psz_recover_zone(struct psz_context *cxt,
struct pstore_zone *zone)
return ret;
}
+static int psz_recover_zones(struct psz_context *cxt,
+ struct pstore_zone **zones, unsigned int cnt)
+{
+ int ret;
+ unsigned int i;
+ struct pstore_zone *zone;
+
+ if (!zones)
+ return 0;
+
+ for (i = 0; i < cnt; i++) {
+ zone = zones[i];
+ if (unlikely(!zone))
+ continue;
+ ret = psz_recover_zone(cxt, zone);
+ if (ret)
+ goto recover_fail;
+ }
+
+ return 0;
+recover_fail:
+ pr_debug("recover %s[%u] failed\n", zone->name, i);
+ return ret;
+}
+
/**
*
Re: ftrace: function radeon_init not traceable
On Tue, 12 May 2020 01:07:44 +0200 Paul Menzel wrote: > >> > >> initcall_debug log_buf_len=32M trace_buf_size=57074K > >> trace_clock=global > >> trace_options=nooverwrite,funcgraph-abstime,funcgraph-cpu,funcgraph-duration,funcgraph-proc,funcgraph-tail,nofuncgraph-overhead,context-info,graph-time > >> ftrace=function_graph ftrace_graph_max_depth=1 > >> ftrace_graph_filter=radeon_init > >> > >> But ftrace “rejects” that: > >> > >> [0.075538] ftrace: allocating 30958 entries in 61 pages > >> [0.084542] ftrace: allocated 61 pages with 5 groups > >> [0.094184] ftrace: function radeon_init not traceable > >> > >> I believe it worked in the past. Is there a way to trace that init > >> function? > > > > Did it every work for modules? radeon_init() isn't in the symbol table at > > boot up. > > > > [ 15.066951] systemd-journald[124]: Successfully sent stream file > > descriptor to service manager. > > [ 15.098265] hub 1-0:1.0: USB hub found > > [ 15.104006] systemd-journald[124]: Successfully sent stream file > > descriptor to service manager. > > [ 15.112965] hub 1-0:1.0: 2 ports detected > > [ 15.118116] probe of 1-0:1.0 returned 1 after 19873 usecs > > [ 15.124007] calling radeon_init+0x0/0x1000 [radeon] @ 133 > > > > The radeon_init is called after systemd is running, so it is definitely > > from a module. > > > > Perhaps you had it built in before? > > You are right. Probably I did. Can you suggest how to set up ftrace to > trace a module? In recent kernels there was a feature to function trace modules before they are loaded, but that feature isn't yet available on mainline. I could add it when I get a chance, but that wont be in the near future. Also, the function graph wont work for that either, as that isn't set up to preload before functions. But since you have ftrace_graph_max_depth of one, you don't need the graph, the limiting of the function (set_ftrace_filter) is good enough. But again, that only works after boot up. > > > > Probably because the filtering failed, so there is no filter. > > Is that the intended behavior? Or should nothing be traced? Well, it's just like writing something not acceptable in the filter functions. If it fails, it does not filter. So yes, it is expected behavior. -- Steve
[PATCH v3 1/1] usb: typec: tps6598x: Add USB role switching logic
This patch adds USB role switch support to the tps6598x.
The setup to initiate or accept a data-role switch is both assumed and
currently required to be baked-into the firmware as described in TI's
document here.
Link: https://www.ti.com/lit/an/slva843a/slva843a.pdf
With this change its possible to use the USB role-switch API to detect and
notify role-switches to downstream consumers.
Tested with a ChipIdea controller on a Qualcomm MSM8939.
Cc: Heikki Krogerus
Cc: Greg Kroah-Hartman
Cc: Nikolaus Voss
Cc: Andy Shevchenko
Cc: Gustavo A. R. Silva
Cc: Kees Cook
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Bryan O'Donoghue
---
drivers/usb/typec/tps6598x.c | 57 +++-
1 file changed, 50 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/typec/tps6598x.c b/drivers/usb/typec/tps6598x.c
index defa651282b0..b7c9fe5caabe 100644
--- a/drivers/usb/typec/tps6598x.c
+++ b/drivers/usb/typec/tps6598x.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
/* Register offsets */
#define TPS_REG_VID0x00
@@ -94,6 +95,7 @@ struct tps6598x {
struct typec_port *port;
struct typec_partner *partner;
struct usb_pd_identity partner_identity;
+ struct usb_role_switch *role_sw;
};
/*
@@ -190,6 +192,23 @@ static int tps6598x_read_partner_identity(struct tps6598x
*tps)
return 0;
}
+static void tps6598x_set_data_role(struct tps6598x *tps,
+ enum typec_data_role role, bool connected)
+{
+ enum usb_role role_val;
+
+ if (role == TYPEC_HOST)
+ role_val = USB_ROLE_HOST;
+ else
+ role_val = USB_ROLE_DEVICE;
+
+ if (!connected)
+ role_val = USB_ROLE_NONE;
+
+ usb_role_switch_set_role(tps->role_sw, role_val);
+ typec_set_data_role(tps->port, role);
+}
+
static int tps6598x_connect(struct tps6598x *tps, u32 status)
{
struct typec_partner_desc desc;
@@ -220,7 +239,7 @@ static int tps6598x_connect(struct tps6598x *tps, u32
status)
typec_set_pwr_opmode(tps->port, mode);
typec_set_pwr_role(tps->port, TPS_STATUS_PORTROLE(status));
typec_set_vconn_role(tps->port, TPS_STATUS_VCONN(status));
- typec_set_data_role(tps->port, TPS_STATUS_DATAROLE(status));
+ tps6598x_set_data_role(tps, TPS_STATUS_DATAROLE(status), true);
tps->partner = typec_register_partner(tps->port, );
if (IS_ERR(tps->partner))
@@ -240,7 +259,7 @@ static void tps6598x_disconnect(struct tps6598x *tps, u32
status)
typec_set_pwr_opmode(tps->port, TYPEC_PWR_MODE_USB);
typec_set_pwr_role(tps->port, TPS_STATUS_PORTROLE(status));
typec_set_vconn_role(tps->port, TPS_STATUS_VCONN(status));
- typec_set_data_role(tps->port, TPS_STATUS_DATAROLE(status));
+ tps6598x_set_data_role(tps, TPS_STATUS_DATAROLE(status), false);
}
static int tps6598x_exec_cmd(struct tps6598x *tps, const char *cmd,
@@ -328,7 +347,7 @@ static int tps6598x_dr_set(struct typec_port *port, enum
typec_data_role role)
goto out_unlock;
}
- typec_set_data_role(tps->port, role);
+ tps6598x_set_data_role(tps, role, true);
out_unlock:
mutex_unlock(>lock);
@@ -452,6 +471,7 @@ static int tps6598x_probe(struct i2c_client *client)
{
struct typec_capability typec_cap = { };
struct tps6598x *tps;
+ struct fwnode_handle *fwnode;
u32 status;
u32 conf;
u32 vid;
@@ -495,11 +515,22 @@ static int tps6598x_probe(struct i2c_client *client)
if (ret < 0)
return ret;
+ fwnode = device_get_named_child_node(>dev, "connector");
+ if (IS_ERR(fwnode))
+ return PTR_ERR(fwnode);
+
+ tps->role_sw = fwnode_usb_role_switch_get(fwnode);
+ if (IS_ERR(tps->role_sw)) {
+ ret = PTR_ERR(tps->role_sw);
+ goto err_fwnode_put;
+ }
+
typec_cap.revision = USB_TYPEC_REV_1_2;
typec_cap.pd_revision = 0x200;
typec_cap.prefer_role = TYPEC_NO_PREFERRED_ROLE;
typec_cap.driver_data = tps;
typec_cap.ops = _ops;
+ typec_cap.fwnode = fwnode;
switch (TPS_SYSCONF_PORTINFO(conf)) {
case TPS_PORTINFO_SINK_ACCESSORY:
@@ -525,12 +556,16 @@ static int tps6598x_probe(struct i2c_client *client)
typec_cap.data = TYPEC_PORT_DFP;
break;
default:
- return -ENODEV;
+ ret = -ENODEV;
+ goto err_role_put;
}
tps->port = typec_register_port(>dev, _cap);
- if (IS_ERR(tps->port))
- return PTR_ERR(tps->port);
+ if (IS_ERR(tps->port)) {
+ ret = PTR_ERR(tps->port);
+ goto err_role_put;
+ }
+ fwnode_handle_put(fwnode);
if (status & TPS_STATUS_PLUG_PRESENT) {
ret = tps6598x_connect(tps, status);
Re: [PATCH v7 00/18] pstore: mtd: support crash log to block and mtd device
On Mon, May 11, 2020 at 06:54:11PM +0800, WeiXiong Liao wrote: > On 2020/5/11 AM 4:24, Kees Cook wrote: > > Hi! > > > > Well, I guess I spoke too soon. :) Here is v7. Hopefully this is > > it. WeiXiong, can you test this and make sure you're happy with the > > results? > > I tested it on Allwinner board for all frontends, including panic. > All of them work well! That's a very good news. Great! I'll get v8 sent out. :) Thanks! -- Kees Cook
Re: [PATCH v7 17/18] mtd: Support kmsg dumper based on pstore/blk
On Mon, May 11, 2020 at 05:01:26PM +0800, WeiXiong Liao wrote:
> On 2020/5/11 AM 4:24, Kees Cook wrote:
> > [...]
> > + if (strlen(info->device) == 0) {
> > + dev_err(>dev, "mtd device must be supplied\n");
>
> mtd is NULL here, "mtd->dev" leads to error.
>
> > + return -EINVAL;
> > + }
> > + if (!info->kmsg_size) {
> > + dev_err(>dev, "no backend enabled\n");
>
> Also here.
Thanks! Fixed.
--
Kees Cook
Re: [PATCH v7 11/18] pstore/zone,blk: Add console frontend support
On Mon, May 11, 2020 at 08:38:32AM -0700, Randy Dunlap wrote: > On 5/10/20 1:24 PM, Kees Cook wrote: > > diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig > > index f18cd126d83f..f1484f751c5e 100644 > > --- a/fs/pstore/Kconfig > > +++ b/fs/pstore/Kconfig > > @@ -236,3 +236,15 @@ config PSTORE_BLK_PMSG_SIZE > > > > NOTE that, both Kconfig and module parameters can configure > > pstore/blk, but module parameters have priority over Kconfig. > > + > > +config PSTORE_BLK_CONSOLE_SIZE > > + int "Size in Kbytes of console to store" > > maybe of console log to store" > > since my console size is not measured in Kbytes. > > > + depends on PSTORE_BLK > > + depends on PSTORE_CONSOLE > > + default 64 > > + help > > + This just sets size of console (console_size) for pstore/blk. The > >console log > > > + size is in KB and must be a multiple of 4. > > + > > + NOTE that, both Kconfig and module parameters can configure > > + pstore/blk, but module parameters have priority over Kconfig. Good points! I've fixed this and a typo in the ftrace Kconfig help. -- Kees Cook
RE: [PATCH v2] igb: Report speed and duplex as unknown when device is runtime suspended
> From: Kai-Heng Feng > Sent: Monday, May 4, 2020 9:02 PM > To: Kirsher, Jeffrey T > Cc: Kai-Heng Feng ; Brown, Aaron F > ; David S. Miller ; > moderated list:INTEL ETHERNET DRIVERS ; > open list:NETWORKING DRIVERS ; open list ker...@vger.kernel.org> > Subject: [PATCH v2] igb: Report speed and duplex as unknown when device is > runtime suspended > > igb device gets runtime suspended when there's no link partner. We can't > get correct speed under that state: > $ cat /sys/class/net/enp3s0/speed > 1000 > > In addition to that, an error can also be spotted in dmesg: > [ 385.991957] igb :03:00.0 enp3s0: PCIe link lost > > Since device can only be runtime suspended when there's no link partner, > we can skip reading register and let the following logic set speed and > duplex with correct status. > > The more generic approach will be wrap get_link_ksettings() with begin() > and complete() callbacks. However, for this particular issue, begin() > calls igb_runtime_resume() , which tries to rtnl_lock() while the lock > is already hold by upper ethtool layer. > > So let's take this approach until the igb_runtime_resume() no longer > needs to hold rtnl_lock. > > Cc: Jeff Kirsher > Cc: Aaron Brown > Suggested-by: Alexander Duyck > Signed-off-by: Kai-Heng Feng > --- > v2: > - Don't early return the routine so other info can be set. > > drivers/net/ethernet/intel/igb/igb_ethtool.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > Tested-by: Aaron Brown
Re: [PATCH v11 33/56] Input: atmel_mxt_ts - delay enabling IRQ when not using regulators
11.05.2020 05:05, Wang, Jiada пишет: > Hello Dmitry > > Thanks for your comment and test, > > can you let me know which platform (board) you are using for test, > and DTS changes if you have added any. That's this device-tree [1] without any extra changes. [1] https://patchwork.ozlabs.org/project/linux-tegra/patch/20200505022517.30523-2-dig...@gmail.com/ The v10 was working fine. I'm take a more detailed look at the problem later this week.
Re: [PATCH v2 1/3] dt-bindings: leds: common: Drop enumeration for linux,default-triggers
On Mon, Apr 27, 2020 at 03:31:30PM +0800, Chen-Yu Tsai wrote: > From: Chen-Yu Tsai > > The bindings currently list a very small subset of valid triggers for > LEDs. Since many drivers or subsystems in Linux register custom > triggers, the list would become very hard to maintain. The idea was we'll consolidate around standardized names and that new users should use 'function' instead. There was discussion around this when adding 'function'. > > Instead, just drop the list and allow free form strings. > > Signed-off-by: Chen-Yu Tsai > --- > .../devicetree/bindings/leds/common.yaml | 21 +-- > 1 file changed, 1 insertion(+), 20 deletions(-) > > diff --git a/Documentation/devicetree/bindings/leds/common.yaml > b/Documentation/devicetree/bindings/leds/common.yaml > index 4c270fde4567..3b3cdab3fc15 100644 > --- a/Documentation/devicetree/bindings/leds/common.yaml > +++ b/Documentation/devicetree/bindings/leds/common.yaml > @@ -79,26 +79,7 @@ properties: > description: >This parameter, if present, is a string defining the trigger assigned > to >the LED. > -allOf: > - - $ref: /schemas/types.yaml#definitions/string > -enum: > -# LED will act as a back-light, controlled by the framebuffer system > - - backlight > -# LED will turn on (but for leds-gpio see "default-state" property in > -# Documentation/devicetree/bindings/leds/leds-gpio.yaml) > - - default-on > -# LED "double" flashes at a load average based rate > - - heartbeat > -# LED indicates disk activity > - - disk-activity > -# LED indicates IDE disk activity (deprecated), in new > implementations > -# use "disk-activity" > - - ide-disk > -# LED flashes at a fixed, configurable rate > - - timer > -# LED alters the brightness for the specified duration with one > software > -# timer (requires "led-pattern" property) > - - pattern > +$ref: /schemas/types.yaml#definitions/string > >led-pattern: > description: | > -- > 2.26.0 >
Re: [PATCH] x86/boot: Mark global variables as static
Feel free to add my tested by
On Mon, 11 May 2020 at 23:58, Arvind Sankar wrote:
>
> Mike Lothian reports that after commit
> 964124a97b97 ("efi/x86: Remove extra headroom for setup block")
> gcc 10.1.0 fails with
>
> HOSTCC arch/x86/boot/tools/build
>
> /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld:
> error: linker defined: multiple definition of '_end'
>
> /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld:
> /tmp/ccEkW0jM.o: previous definition here
> collect2: error: ld returned 1 exit status
> make[1]: *** [scripts/Makefile.host:103: arch/x86/boot/tools/build] Error 1
> make: *** [arch/x86/Makefile:303: bzImage] Error 2
>
> The issue is with the _end variable that was added, to hold the end of
> the compressed kernel from zoffsets.h (ZO__end). The name clashes with
> the linker-defined _end symbol that indicates the end of the build
> program itself.
>
> Even when there is no compile-time error, this causes build to use
> memory past the end of its .bss section.
>
> To solve this, mark _end as static, and for symmetry, mark the rest of
> the variables that keep track of symbols from the compressed kernel as
> static as well.
>
> Fixes: 964124a97b97 ("efi/x86: Remove extra headroom for setup block")
> Signed-off-by: Arvind Sankar
> ---
> arch/x86/boot/tools/build.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/boot/tools/build.c b/arch/x86/boot/tools/build.c
> index 8f8c8e386cea..c8b8c1a8d1fc 100644
> --- a/arch/x86/boot/tools/build.c
> +++ b/arch/x86/boot/tools/build.c
> @@ -59,14 +59,14 @@ u8 buf[SETUP_SECT_MAX*512];
> #define PECOFF_COMPAT_RESERVE 0x0
> #endif
>
> -unsigned long efi32_stub_entry;
> -unsigned long efi64_stub_entry;
> -unsigned long efi_pe_entry;
> -unsigned long efi32_pe_entry;
> -unsigned long kernel_info;
> -unsigned long startup_64;
> -unsigned long _ehead;
> -unsigned long _end;
> +static unsigned long efi32_stub_entry;
> +static unsigned long efi64_stub_entry;
> +static unsigned long efi_pe_entry;
> +static unsigned long efi32_pe_entry;
> +static unsigned long kernel_info;
> +static unsigned long startup_64;
> +static unsigned long _ehead;
> +static unsigned long _end;
>
> /*--*/
>
> --
> 2.26.2
>
Re: [PATCH v7 09/18] pstore/blk: Introduce backend for block devices
On Mon, May 11, 2020 at 08:36:49AM -0700, Randy Dunlap wrote: > On 5/10/20 1:24 PM, Kees Cook wrote: > > diff --git a/fs/pstore/Kconfig b/fs/pstore/Kconfig > > index 98d2457bdd9f..92ba73bd0b62 100644 > > --- a/fs/pstore/Kconfig > > +++ b/fs/pstore/Kconfig > > @@ -160,3 +160,67 @@ config PSTORE_ZONE > > help > > The common layer for pstore/blk (and pstore/ram in the future) > > to manage storage in zones. > > + > > +config PSTORE_BLK > > + tristate "Log panic/oops to a block device" > > + depends on PSTORE > > + depends on BLOCK > > + select PSTORE_ZONE > > + default n > > + help > > + This enables panic and oops message to be logged to a block dev > > + where it can be read back at some later point. > > + > > + If unsure, say N. > > + > > +config PSTORE_BLK_BLKDEV > > + string "block device identifier" > > + depends on PSTORE_BLK > > + default "" > > + help > > + Which block device should be used for pstore/blk. > > + > > + It accept the following variants: > > + 1) device number in hexadecimal represents > > +itself no leading 0x, for example b302. > >itself with no leading 0x, Yes, I've reworked the language here. Thanks! -- Kees Cook
Re: [PATCH] kernel: sysctl: ignore invalid taint bits introduced via kernel.tainted and taint the kernel with TAINT_USER on writes
On Mon, May 11, 2020 at 05:59:04PM -0400, Rafael Aquini wrote:
> The sysctl knob allows any user with SYS_ADMIN capability to
> taint the kernel with any arbitrary value, but this might
> produce an invalid flags bitset being committed to tainted_mask.
>
> This patch introduces a simple way for proc_taint() to ignore
> any eventual invalid bit coming from the user input before
> committing those bits to the kernel tainted_mask, as well as
> it makes clear use of TAINT_USER flag to mark the kernel
> tainted by user everytime a taint value is written
> to the kernel.tainted sysctl.
>
> Signed-off-by: Rafael Aquini
> ---
> kernel/sysctl.c | 17 -
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 8a176d8727a3..f0a4fb38ac62 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -2623,17 +2623,32 @@ static int proc_taint(struct ctl_table *table, int
> write,
> return err;
>
> if (write) {
> + int i;
> +
> + /*
> + * Ignore user input that would make us committing
> + * arbitrary invalid TAINT flags in the loop below.
> + */
> + tmptaint &= (1UL << TAINT_FLAGS_COUNT) - 1;
This looks good but we don't pr_warn() of information lost on intention.
> +
> /*
>* Poor man's atomic or. Not worth adding a primitive
>* to everyone's atomic.h for this
>*/
> - int i;
> for (i = 0; i < BITS_PER_LONG && tmptaint >> i; i++) {
> if ((tmptaint >> i) & 1)
> add_taint(i, LOCKDEP_STILL_OK);
> }
> +
> + /*
> + * Users with SYS_ADMIN capability can include any arbitrary
> + * taint flag by writing to this interface. If that's the case,
> + * we also need to mark the kernel "tainted by user".
> + */
> + add_taint(TAINT_USER, LOCKDEP_STILL_OK);
I'm in favor of this however I'd like to hear from Ted on if it meets
the original intention. I would think he had a good reason not to add
it here.
Luis
> }
>
> +
> return err;
> }
>
> --
> 2.25.4
>
Re: [PATCH v7 09/18] pstore/blk: Introduce backend for block devices
On Mon, May 11, 2020 at 04:36:51PM +0800, WeiXiong Liao wrote:
> On 2020/5/11 AM 4:24, Kees Cook wrote:
> > [...]
> > +static struct block_device *psblk_get_bdev(void *holder,
> > + struct bdev_info *info)
>
> Well. That's pretty a good idea to get information about block device
> after registering. And after your codes, the global variable g_bdev_info is
> useless. It's time to drop it.
Ah yes! I meant to clean that up and forgot. Fixed now.
> > [...]
> > + bdev = blkdev_get_by_path(blkdev, mode, holder);
> > + if (IS_ERR(bdev)) {
> > + dev_t devt;
> > +
> > + devt = name_to_dev_t(blkdev);
> > + if (devt == 0)
> > + return ERR_PTR(-ENODEV);
> > + bdev = blkdev_get_by_dev(devt, mode, holder);
> > + }
>
> We should check bdev here. Otherwise, part_nr_sects_read()
> may catch segment error.
>
> if (IS_ERR(bdev))
> return bdev;
Whoops, yes. Fixed.
> > + bdev = psblk_get_bdev(holder, );
> > + if (IS_ERR(bdev)) {
> > + pr_err("failed to open '%s'!\n", blkdev);
> > + ret = PTR_ERR(bdev);
> > + goto err_put_bdev;
>
> It should not goto err_put_bdev since bdev already be put if get_bdev()
> fail.
Ah yes, good point. Fixed.
--
Kees Cook
Re: ftrace: function radeon_init not traceable
Dear Steven, Thank you for your quick response. Am 11.05.20 um 20:58 schrieb Steven Rostedt: On Sat, 9 May 2020 12:16:30 +0200 Paul Menzel wrote: Linux master and Linux 5.6.7 (from Debian Sid/unstable) are used. Instrumenting Linux’ start-up time, I’d like to trace the init function of the Radeon graphics driver `radeon_init()` (built as a module). drivers/gpu/drm/radeon/radeon_drv.c:static int __init radeon_init(void) drivers/gpu/drm/radeon/radeon_drv.c:module_init(radeon_init); With `initcall_debug` I can see: [1.079920] calling radeon_init+0x0/0x1000 [radeon] @ 138 [1.663200] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after 129346 usecs With `function_graph` as the trace, I am adding the string below to the Linux kernel CLI. initcall_debug log_buf_len=32M trace_buf_size=57074K trace_clock=global trace_options=nooverwrite,funcgraph-abstime,funcgraph-cpu,funcgraph-duration,funcgraph-proc,funcgraph-tail,nofuncgraph-overhead,context-info,graph-time ftrace=function_graph ftrace_graph_max_depth=1 ftrace_graph_filter=radeon_init But ftrace “rejects” that: [0.075538] ftrace: allocating 30958 entries in 61 pages [0.084542] ftrace: allocated 61 pages with 5 groups [0.094184] ftrace: function radeon_init not traceable I believe it worked in the past. Is there a way to trace that init function? Did it every work for modules? radeon_init() isn't in the symbol table at boot up. [ 15.066951] systemd-journald[124]: Successfully sent stream file descriptor to service manager. [ 15.098265] hub 1-0:1.0: USB hub found [ 15.104006] systemd-journald[124]: Successfully sent stream file descriptor to service manager. [ 15.112965] hub 1-0:1.0: 2 ports detected [ 15.118116] probe of 1-0:1.0 returned 1 after 19873 usecs [ 15.124007] calling radeon_init+0x0/0x1000 [radeon] @ 133 The radeon_init is called after systemd is running, so it is definitely from a module. Perhaps you had it built in before? You are right. Probably I did. Can you suggest how to set up ftrace to trace a module? Despite the function not being traceable, the trace file is still filled. I’d would have expected to be empty. ``` # tracer: function_graph # # TIMECPU TASK/PID DURATION FUNCTION CALLS # | | || | | | | | | 2.910887 | 0)-0| 2.662 us| local_touch_nmi(); 2.910888 | 0)-0| 0.497 us| local_touch_nmi(); 2.910888 | 0)-0| 0.346 us| local_touch_nmi(); 2.910888 | 1) systemd-1| 1.440 us| __text_poke(); 2.910888 | 1) systemd-1| 0.588 us| __text_poke(); 2.910888 | 1) systemd-1| 0.556 us| __text_poke(); 2.910888 | 1) systemd-1| 0.489 us| __text_poke(); […] 2.910889 | 1) systemd-1| 0.530 us| __text_poke(); 2.910889 | 0)-0| 0.473 us| do_sync_core(); 2.910889 | 1) systemd-1| 0.572 us| do_sync_core(); 2.910889 | 0)-0| 0.365 us| arch_cpu_idle_enter(); 2.910889 | 1) systemd-1| 0.830 us| __text_poke(); 2.910889 | 0)-0| ! 278.143 us | arch_cpu_idle(); 2.910889 | 1) systemd-1| 0.582 us| __text_poke(); […] ``` Probably because the filtering failed, so there is no filter. Is that the intended behavior? Or should nothing be traced? Kind regards, Paul
Re: [PATCH v3 3/5] drm/nouveau/kms/gv100-: Add support for interlaced modes
On Mon, May 11, 2020 at 6:42 PM Lyude Paul wrote: > diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c > b/drivers/gpu/drm/nouveau/nouveau_connector.c > index 43bcbb6d73c4..6dae00da5d7e 100644 > --- a/drivers/gpu/drm/nouveau/nouveau_connector.c > +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c > @@ -1065,7 +1065,7 @@ nouveau_connector_mode_valid(struct drm_connector > *connector, > return get_slave_funcs(encoder)->mode_valid(encoder, mode); > case DCB_OUTPUT_DP: > if (mode->flags & DRM_MODE_FLAG_INTERLACE && > - !nv_encoder->dp.caps.interlace) > + !nv_encoder->caps.dp_interlace) > return MODE_NO_INTERLACE; > > max_clock = nv_encoder->dp.link_nr; You probably meant for this hunk to go into an earlier patch. -ilia
Re: [PATCH] soc: qcom: aoss: Add SM8250 compatible
On Sun, 26 Apr 2020 22:42:02 -0700, Bjorn Andersson wrote: > Add SM8250 compatible to the qcom_aoss binding and driver. > > Signed-off-by: Bjorn Andersson > --- > Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.txt | 1 + > drivers/soc/qcom/qcom_aoss.c | 1 + > 2 files changed, 2 insertions(+) > Acked-by: Rob Herring
Re: [PATCH 8/8] dt-bindings: display: Convert ingenic,lcd.txt to YAML
On Tue, Apr 28, 2020 at 04:12:21PM +0200, Paul Cercueil wrote:
> This one patch will need a V2, I messed up with the clocks.
Looks fine otherwise.
>
> -Paul
>
>
> Le dim. 26 avril 2020 à 20:58, Paul Cercueil a écrit
> :
> > Convert the ingenic,lcd.txt to a new ingenic,lcd.yaml file.
> >
> > In the process, the new ingenic,jz4780-lcd compatible string has been
> > added.
> >
> > Signed-off-by: Paul Cercueil
> > ---
> > .../bindings/display/ingenic,lcd.txt | 45 ---
> > .../bindings/display/ingenic,lcd.yaml | 113 ++
> > 2 files changed, 113 insertions(+), 45 deletions(-)
> > delete mode 100644
> > Documentation/devicetree/bindings/display/ingenic,lcd.txt
> > create mode 100644
> > Documentation/devicetree/bindings/display/ingenic,lcd.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/display/ingenic,lcd.txt
> > b/Documentation/devicetree/bindings/display/ingenic,lcd.txt
> > deleted file mode 100644
> > index 01e3261defb6..
> > --- a/Documentation/devicetree/bindings/display/ingenic,lcd.txt
> > +++ /dev/null
> > @@ -1,45 +0,0 @@
> > -Ingenic JZ47xx LCD driver
> > -
> > -Required properties:
> > -- compatible: one of:
> > - * ingenic,jz4740-lcd
> > - * ingenic,jz4725b-lcd
> > - * ingenic,jz4770-lcd
> > -- reg: LCD registers location and length
> > -- clocks: LCD pixclock and device clock specifiers.
> > - The device clock is only required on the JZ4740.
> > -- clock-names: "lcd_pclk" and "lcd"
> > -- interrupts: Specifies the interrupt line the LCD controller is
> > connected to.
> > -
> > -Example:
> > -
> > -panel {
> > - compatible = "sharp,ls020b1dd01d";
> > -
> > - backlight = <>;
> > - power-supply = <>;
> > -
> > - port {
> > - panel_input: endpoint {
> > - remote-endpoint = <_output>;
> > - };
> > - };
> > -};
> > -
> > -
> > -lcd: lcd-controller@1305 {
> > - compatible = "ingenic,jz4725b-lcd";
> > - reg = <0x1305 0x1000>;
> > -
> > - interrupt-parent = <>;
> > - interrupts = <31>;
> > -
> > - clocks = < JZ4725B_CLK_LCD>;
> > - clock-names = "lcd";
> > -
> > - port {
> > - panel_output: endpoint {
> > - remote-endpoint = <_input>;
> > - };
> > - };
> > -};
> > diff --git a/Documentation/devicetree/bindings/display/ingenic,lcd.yaml
> > b/Documentation/devicetree/bindings/display/ingenic,lcd.yaml
> > new file mode 100644
> > index ..8e9c851dc7c5
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/ingenic,lcd.yaml
> > @@ -0,0 +1,113 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/display/ingenic,lcd.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Ingenic SoCs LCD controller devicetree bindings
> > +
> > +maintainers:
> > + - Paul Cercueil
> > +
> > +properties:
> > + $nodename:
> > +pattern: "^lcd-controller@[0-9a-f]+$"
> > +
> > + compatible:
> > +enum:
> > + - ingenic,jz4740-lcd
> > + - ingenic,jz4725b-lcd
> > + - ingenic,jz4770-lcd
> > + - ingenic,jz4780-lcd
> > +
> > + reg:
> > +maxItems: 1
> > +
> > + interrupts:
> > +maxItems: 1
> > +
> > + clocks:
> > +items:
> > + - description: Module clock
> > + - description: Pixel clock
> > +minItems: 1
> > +
> > + clock-names:
> > +items:
> > + - const: lcd
> > + - const: lcd_pclk
> > +minItems: 1
> > +
> > + port:
> > +type: object
> > +description:
> > + A port node with endpoint definitions as defined in
> > + Documentation/devicetree/bindings/media/video-interfaces.txt
> > +
> > +required:
> > +- compatible
> > +- reg
> > +- interrupts
> > +- clocks
> > +- clock-names
> > +
> > +if:
> > + properties:
> > +compatible:
> > + contains:
> > +enum:
> > + - ingenic,jz4740-lcd
> > + - ingenic,jz4780-lcd
> > +then:
> > + properties:
> > +clocks:
> > + minItems: 2
> > +clock-names:
> > + minItems: 2
> > +else:
> > + properties:
> > +clocks:
> > + maxItems: 1
> > +clock-names:
> > + maxItems: 1
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > +#include
> > +lcd-controller@1305 {
> > + compatible = "ingenic,jz4740-lcd";
> > + reg = <0x1305 0x1000>;
> > +
> > + interrupt-parent = <>;
> > + interrupts = <30>;
> > +
> > + clocks = < JZ4740_CLK_LCD>, < JZ4740_CLK_LCD_PCLK>;
> > + clock-names = "lcd", "lcd_pclk";
> > +
> > + port {
> > +endpoint {
> > + remote-endpoint = <_input>;
> > +};
> > + };
> > +};
> > +
> > + - |
> > +#include
> > +lcd-controller@1305 {
> > + compatible = "ingenic,jz4725b-lcd";
> > + reg = <0x1305 0x1000>;
> > +
> > + interrupt-parent = <>;
> > + interrupts = <31>;
> > +
> > +
Re: [PATCH 7/8] dt-bindings: serial: Convert ingenic,uart.txt to YAML
On Sun, 26 Apr 2020 20:58:55 +0200, Paul Cercueil wrote: > Convert the ingenic,uart.txt to a new ingenic,uart.yaml file. > > A few things were changed in the process: > - the dmas and dma-names properties are now required. > - the ingenic,jz4770-uart and ingenic,jz4775-uart compatible strings now > require the ingenic,jz4760-uart string to be used as fallback, since > the hardware is compatible. > - the ingenic,jz4725b-uart compatible string was added, with a fallback > to ingenic,jz4740-uart. > > Signed-off-by: Paul Cercueil > --- > .../bindings/serial/ingenic,uart.txt | 28 -- > .../bindings/serial/ingenic,uart.yaml | 94 +++ > 2 files changed, 94 insertions(+), 28 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/serial/ingenic,uart.txt > create mode 100644 Documentation/devicetree/bindings/serial/ingenic,uart.yaml > Applied, thanks!
Re: [PATCH v7 08/18] pstore/zone: Introduce common layer to manage storage zones
On Mon, May 11, 2020 at 04:36:21PM +0800, WeiXiong Liao wrote:
> On 2020/5/11 AM 4:24, Kees Cook wrote:
> > [...]
> > + * @time: oops/panic trigger time
>
> The above comment should be corrected since it is not only oops/panic
> any more.
Ah yes, thanks! I'll clean these all up.
> > [...]
> > + if (hdr->reason == KMSG_DUMP_OOPS)
> > + hdr->counter = ++cxt->oops_counter;
> > + else
> > + hdr->counter = ++cxt->panic_counter;
>
> Here should be:
>
> if (hdr->reason == KMSG_DUMP_OOPS)
> hdr->counter = ++cxt->oops_counter;
> else if (hdr->reason == KMSG_DUMP_PANIC)
> hdr->counter = ++cxt->panic_counter;
> else
> hdr->counter = 0;
Good catch; thanks! I'll move the lost later hunk to here.
> > [...]
> > +MODULE_DESCRIPTION("Storage Manager for pstore/blk");
I'm going to leave this as-is for now since it's accurate for the
moment. :)
--
Kees Cook
Re: [PATCH v2 net-next 03/15] net: dsa: sja1105: keep the VLAN awareness state in a driver variable
Hi Vladimir,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
[cannot apply to linus/master v5.7-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Vladimir-Oltean/Traffic-support-for-dsa_8021q-in-vlan_filtering-1-mode/20200512-024329
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
a6f0b26d6a5dcf27980e65f965779a929039f11d
config: xtensa-randconfig-r021-20200511 (attached as .config)
compiler: xtensa-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross
ARCH=xtensa
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
xtensa-linux-ld: net/dsa/tag_sja1105.o: in function `sja1105_rcv':
>> net/dsa/tag_sja1105.c:305: undefined reference to
>> `sja1105_can_use_vlan_as_tags'
xtensa-linux-ld: net/dsa/tag_sja1105.o: in function `sja1105_filter':
net/dsa/tag_sja1105.c:77: undefined reference to
`sja1105_can_use_vlan_as_tags'
vim +305 net/dsa/tag_sja1105.c
f3097be21bf17a Vladimir Oltean 2019-06-08 246
227d07a07ef126 Vladimir Oltean 2019-05-05 247 static struct sk_buff
*sja1105_rcv(struct sk_buff *skb,
227d07a07ef126 Vladimir Oltean 2019-05-05 248
struct net_device *netdev,
227d07a07ef126 Vladimir Oltean 2019-05-05 249
struct packet_type *pt)
227d07a07ef126 Vladimir Oltean 2019-05-05 250 {
e53e18a6fe4d3a Vladimir Oltean 2019-06-08 251 struct sja1105_meta
meta = {0};
d461933638ae9f Vladimir Oltean 2019-06-08 252 int source_port,
switch_id;
e80f40cbe4dd51 Vladimir Oltean 2020-03-24 253 struct ethhdr *hdr;
227d07a07ef126 Vladimir Oltean 2019-05-05 254 u16 tpid, vid, tci;
42824463d38d27 Vladimir Oltean 2019-06-08 255 bool is_link_local;
227d07a07ef126 Vladimir Oltean 2019-05-05 256 bool is_tagged;
e53e18a6fe4d3a Vladimir Oltean 2019-06-08 257 bool is_meta;
227d07a07ef126 Vladimir Oltean 2019-05-05 258
e80f40cbe4dd51 Vladimir Oltean 2020-03-24 259 hdr = eth_hdr(skb);
e80f40cbe4dd51 Vladimir Oltean 2020-03-24 260 tpid =
ntohs(hdr->h_proto);
d461933638ae9f Vladimir Oltean 2019-06-08 261 is_tagged = (tpid ==
ETH_P_SJA1105);
42824463d38d27 Vladimir Oltean 2019-06-08 262 is_link_local =
sja1105_is_link_local(skb);
e53e18a6fe4d3a Vladimir Oltean 2019-06-08 263 is_meta =
sja1105_is_meta_frame(skb);
227d07a07ef126 Vladimir Oltean 2019-05-05 264
227d07a07ef126 Vladimir Oltean 2019-05-05 265 skb->offload_fwd_mark =
1;
227d07a07ef126 Vladimir Oltean 2019-05-05 266
42824463d38d27 Vladimir Oltean 2019-06-08 267 if (is_tagged) {
42824463d38d27 Vladimir Oltean 2019-06-08 268 /* Normal
traffic path. */
e80f40cbe4dd51 Vladimir Oltean 2020-03-24 269
skb_push_rcsum(skb, ETH_HLEN);
e80f40cbe4dd51 Vladimir Oltean 2020-03-24 270
__skb_vlan_pop(skb, );
e80f40cbe4dd51 Vladimir Oltean 2020-03-24 271
skb_pull_rcsum(skb, ETH_HLEN);
e80f40cbe4dd51 Vladimir Oltean 2020-03-24 272
skb_reset_network_header(skb);
e80f40cbe4dd51 Vladimir Oltean 2020-03-24 273
skb_reset_transport_header(skb);
e80f40cbe4dd51 Vladimir Oltean 2020-03-24 274
42824463d38d27 Vladimir Oltean 2019-06-08 275 vid = tci &
VLAN_VID_MASK;
42824463d38d27 Vladimir Oltean 2019-06-08 276 source_port =
dsa_8021q_rx_source_port(vid);
42824463d38d27 Vladimir Oltean 2019-06-08 277 switch_id =
dsa_8021q_rx_switch_id(vid);
42824463d38d27 Vladimir Oltean 2019-06-08 278 skb->priority =
(tci & VLAN_PRIO_MASK) >> VLAN_PRIO_SHIFT;
42824463d38d27 Vladimir Oltean 2019-06-08 279 } else if
(is_link_local) {
227d07a07ef126 Vladimir Oltean 2019-05-05 280 /* Management
traffic path. Switch embeds the switch ID and
227d07a07ef126 Vladimir Oltean 2019-05-05 281 * port ID into
bytes of the destination MAC, courtesy of
227d07a07ef126 Vladimir Oltean 2019-05-05 282 * the
incl_srcpt options.
227d07a07ef126 Vladimir Oltean 2019-05-05 283 */
227d07a07ef126 Vladimir Oltean 2019-05-05 284 source_port =
hdr->h_dest[3];
227d07a07ef126 Vladimir Oltean 2019-05-05 285 switch_id =
hdr->
Re: [PATCH 6/8] dt-bindings: i2c: Convert i2c-jz4780.txt to YAML
On Sun, 26 Apr 2020 20:58:54 +0200, Paul Cercueil wrote: > Convert the i2c-jz4780.txt file to ingenic,i2c.yaml. > > Two things were changed in the process: > - the clock-frequency property can now only be set to the two values > that can be set by the hardware; > - the dmas and dma-names properties are now required. > > Signed-off-by: Paul Cercueil > --- > .../devicetree/bindings/i2c/i2c-jz4780.txt| 33 > .../devicetree/bindings/i2c/ingenic,i2c.yaml | 83 +++ > 2 files changed, 83 insertions(+), 33 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/i2c/i2c-jz4780.txt > create mode 100644 Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml > Applied, thanks!
Re: [PATCH v2 net-next 02/15] net: dsa: tag_8021q: introduce a vid_is_dsa_8021q helper
On 5/11/2020 6:53 AM, Vladimir Oltean wrote: > From: Vladimir Oltean > > This function returns a boolean denoting whether the VLAN passed as > argument is part of the 1024-3071 range that the dsa_8021q tagging > scheme uses. > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian
Re: [PATCH v2 net-next 01/15] net: dsa: provide an option for drivers to always receive bridge VLANs
On 5/11/2020 6:53 AM, Vladimir Oltean wrote: > From: Russell King > > DSA assumes that a bridge which has vlan filtering disabled is not > vlan aware, and ignores all vlan configuration. However, the kernel > software bridge code allows configuration in this state. > > This causes the kernel's idea of the bridge vlan state and the > hardware state to disagree, so "bridge vlan show" indicates a correct > configuration but the hardware lacks all configuration. Even worse, > enabling vlan filtering on a DSA bridge immediately blocks all traffic > which, given the output of "bridge vlan show", is very confusing. > > Provide an option that drivers can set to indicate they want to receive > vlan configuration even when vlan filtering is disabled. At the very > least, this is safe for Marvell DSA bridges, which do not look up > ingress traffic in the VTU if the port is in 8021Q disabled state. It is > also safe for the Ocelot switch family. Whether this change is suitable > for all DSA bridges is not known. > > Signed-off-by: Russell King > Signed-off-by: Vladimir Oltean We may want to consolidate these checks in a helper function at some point, and the name is still not super clear to me (not sure what disabled refers to unless you read the comments), but this is as good as it could be: Reviewed-by: Florian Fainelli -- Florian
[PATCH] x86/boot: Mark global variables as static
Mike Lothian reports that after commit
964124a97b97 ("efi/x86: Remove extra headroom for setup block")
gcc 10.1.0 fails with
HOSTCC arch/x86/boot/tools/build
/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld:
error: linker defined: multiple definition of '_end'
/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/tmp/ccEkW0jM.o: previous definition here
collect2: error: ld returned 1 exit status
make[1]: *** [scripts/Makefile.host:103: arch/x86/boot/tools/build] Error 1
make: *** [arch/x86/Makefile:303: bzImage] Error 2
The issue is with the _end variable that was added, to hold the end of
the compressed kernel from zoffsets.h (ZO__end). The name clashes with
the linker-defined _end symbol that indicates the end of the build
program itself.
Even when there is no compile-time error, this causes build to use
memory past the end of its .bss section.
To solve this, mark _end as static, and for symmetry, mark the rest of
the variables that keep track of symbols from the compressed kernel as
static as well.
Fixes: 964124a97b97 ("efi/x86: Remove extra headroom for setup block")
Signed-off-by: Arvind Sankar
---
arch/x86/boot/tools/build.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/x86/boot/tools/build.c b/arch/x86/boot/tools/build.c
index 8f8c8e386cea..c8b8c1a8d1fc 100644
--- a/arch/x86/boot/tools/build.c
+++ b/arch/x86/boot/tools/build.c
@@ -59,14 +59,14 @@ u8 buf[SETUP_SECT_MAX*512];
#define PECOFF_COMPAT_RESERVE 0x0
#endif
-unsigned long efi32_stub_entry;
-unsigned long efi64_stub_entry;
-unsigned long efi_pe_entry;
-unsigned long efi32_pe_entry;
-unsigned long kernel_info;
-unsigned long startup_64;
-unsigned long _ehead;
-unsigned long _end;
+static unsigned long efi32_stub_entry;
+static unsigned long efi64_stub_entry;
+static unsigned long efi_pe_entry;
+static unsigned long efi32_pe_entry;
+static unsigned long kernel_info;
+static unsigned long startup_64;
+static unsigned long _ehead;
+static unsigned long _end;
/*--*/
--
2.26.2
Re: [PATCH 5/8] dt-bindings: mtd: Convert ingenic,jz4780-nand.txt to YAML
On Sun, Apr 26, 2020 at 08:58:53PM +0200, Paul Cercueil wrote:
> Convert the ingenic,jz4780-nand.txt doc file to ingenic,nand.yaml.
>
> Signed-off-by: Paul Cercueil
> ---
> .../bindings/mtd/ingenic,jz4780-nand.txt | 92
> .../devicetree/bindings/mtd/ingenic,nand.yaml | 133 ++
> 2 files changed, 133 insertions(+), 92 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> create mode 100644 Documentation/devicetree/bindings/mtd/ingenic,nand.yaml
>
> diff --git a/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> b/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> deleted file mode 100644
> index c02259353327..
> --- a/Documentation/devicetree/bindings/mtd/ingenic,jz4780-nand.txt
> +++ /dev/null
> @@ -1,92 +0,0 @@
> -* Ingenic JZ4780 NAND/ECC
> -
> -This file documents the device tree bindings for NAND flash devices on the
> -JZ4780. NAND devices are connected to the NEMC controller (described in
> -memory-controllers/ingenic,jz4780-nemc.txt), and thus NAND device nodes must
> -be children of the NEMC node.
> -
> -Required NAND controller device properties:
> -- compatible: Should be one of:
> - * ingenic,jz4740-nand
> - * ingenic,jz4725b-nand
> - * ingenic,jz4780-nand
> -- reg: For each bank with a NAND chip attached, should specify a bank number,
> - an offset of 0 and a size of 0x100 (i.e. the whole NEMC bank).
> -
> -Optional NAND controller device properties:
> -- ecc-engine: To make use of the hardware ECC controller, this
> - property must contain a phandle for the ECC controller node. The required
> - properties for this node are described below. If this is not specified,
> - software ECC will be used instead.
> -
> -Optional children nodes:
> -- Individual NAND chips are children of the NAND controller node.
> -
> -Required children node properties:
> -- reg: An integer ranging from 1 to 6 representing the CS line to use.
> -
> -Optional children node properties:
> -- nand-ecc-step-size: ECC block size in bytes.
> -- nand-ecc-strength: ECC strength (max number of correctable bits).
> -- nand-ecc-mode: String, operation mode of the NAND ecc mode. "hw" by default
> -- nand-on-flash-bbt: boolean to enable on flash bbt option, if not present
> false
> -- rb-gpios: GPIO specifier for the busy pin.
> -- wp-gpios: GPIO specifier for the write protect pin.
> -
> -Optional child node of NAND chip nodes:
> -- partitions: see Documentation/devicetree/bindings/mtd/partition.txt
> -
> -Example:
> -
> -nemc: nemc@1341 {
> - ...
> -
> - nandc: nand-controller@1 {
> - compatible = "ingenic,jz4780-nand";
> - reg = <1 0 0x100>; /* Bank 1 */
> -
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - ecc-engine = <>;
> -
> - nand@1 {
> - reg = <1>;
> -
> - nand-ecc-step-size = <1024>;
> - nand-ecc-strength = <24>;
> - nand-ecc-mode = "hw";
> - nand-on-flash-bbt;
> -
> - rb-gpios = < 20 GPIO_ACTIVE_LOW>;
> - wp-gpios = < 22 GPIO_ACTIVE_LOW>;
> -
> - partitions {
> - #address-cells = <2>;
> - #size-cells = <2>;
> - ...
> - }
> - };
> - };
> -};
> -
> -The ECC controller is a separate SoC component used for error correction on
> -NAND devices. The following is a description of the device properties for a
> -ECC controller.
> -
> -Required ECC properties:
> -- compatible: Should be one of:
> - * ingenic,jz4740-ecc
> - * ingenic,jz4725b-bch
> - * ingenic,jz4780-bch
> -- reg: Should specify the ECC controller registers location and length.
> -- clocks: Clock for the ECC controller.
> -
> -Example:
> -
> -bch: bch@134d {
> - compatible = "ingenic,jz4780-bch";
> - reg = <0x134d 0x1>;
> -
> - clocks = < JZ4780_CLK_BCH>;
> -};
> diff --git a/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml
> b/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml
> new file mode 100644
> index ..0e4cb1b55385
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/ingenic,nand.yaml
> @@ -0,0 +1,133 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/mtd/ingenic,nand.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ingenic SoCs NAND controller devicetree bindings
> +
> +maintainers:
> + - Paul Cercueil
> +
> +allOf:
> + - $ref: ../memory-controllers/ingenic,nemc-client.yaml#
You don't need this here because the schema is already applied with the
parent's schema.
> + - $ref: nand-controller.yaml#
> +
> +properties:
> + compatible:
> +enum:
> + - ingenic,jz4740-nand
> + -
Re: [PATCH] x86: support i386 with Clang
On Mon, May 11, 2020 at 3:34 PM Brian Gerst wrote:
>
> On Mon, May 11, 2020 at 2:46 PM Nick Desaulniers
> wrote:
> >
> > On Mon, May 11, 2020 at 11:09 AM Brian Gerst wrote:
> > > This looks like the same issue that we just discussed for bitops.h.
> > > Add the "b" operand size modifier to force it to use the 8-bit
> > > register names (and probably also needs the "w" modifier in the 16-bit
> > > case).
> >
> > While it does feel familiar, it is slightly different.
> > https://godbolt.org/z/Rme4Zg
> > That case was both compilers validating the inline asm, yet generating
> > assembly that the assembler would choke on. This case is validation
> > in the front end failing.
>
> > long long ret;
> > switch (sizeof(ret)) {
> > case 1:
> > asm ("movb $5, %0" : "=q" (ret));
> > break;
> > case 8:;
> > }
>
> So if the issue here is that the output variable type is long long,
> what code is using a 64-bit percpu variable on a 32-bit kernel? Can
> you give a specific file that fails to build with Clang? If Clang is
> choking on it it may be silently miscompiling on GCC.
On further investigation, 64-bit percpu operations fall back to the
generic code on x86-32, so there is no problem with miscompiling here.
On a side note from looking at the preprocessed output of the percpu
macros: they generate a ton of extra dead code because the core macros
also have a switch on data size. I will take a stab at cleaning that
up.
--
Brian Gerst
Re: [PATCH 4/8] dt-bindings: memory: Convert ingenic,jz4780-nemc.txt to YAML
On Sun, Apr 26, 2020 at 08:58:52PM +0200, Paul Cercueil wrote:
> Convert the ingenic,jz4780-nemc.txt doc file to ingenic,nemc.yaml.
>
> The ingenic,jz4725b-nemc compatible string was added in the process,
> with a fallback to ingenic,jz4740-nemc.
>
> Signed-off-by: Paul Cercueil
> ---
> .../ingenic,jz4780-nemc.txt | 76 ---
> .../ingenic,nemc-client.yaml | 45 +
> .../memory-controllers/ingenic,nemc.yaml | 95 +++
> 3 files changed, 140 insertions(+), 76 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt
> create mode 100644
> Documentation/devicetree/bindings/memory-controllers/ingenic,nemc-client.yaml
> create mode 100644
> Documentation/devicetree/bindings/memory-controllers/ingenic,nemc.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt
>
> b/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt
> deleted file mode 100644
> index 59b8dcc118ee..
> ---
> a/Documentation/devicetree/bindings/memory-controllers/ingenic,jz4780-nemc.txt
> +++ /dev/null
> @@ -1,76 +0,0 @@
> -* Ingenic JZ4780 NAND/external memory controller (NEMC)
> -
> -This file documents the device tree bindings for the NEMC external memory
> -controller in Ingenic JZ4780
> -
> -Required properties:
> -- compatible: Should be set to one of:
> -"ingenic,jz4740-nemc" (JZ4740)
> -"ingenic,jz4780-nemc" (JZ4780)
> -- reg: Should specify the NEMC controller registers location and length.
> -- clocks: Clock for the NEMC controller.
> -- #address-cells: Must be set to 2.
> -- #size-cells: Must be set to 1.
> -- ranges: A set of ranges for each bank describing the physical memory
> layout.
> - Each should specify the following 4 integer values:
> -
> - 0
> -
> -Each child of the NEMC node describes a device connected to the NEMC.
> -
> -Required child node properties:
> -- reg: Should contain at least one register specifier, given in the following
> - format:
> -
> -
> -
> - Multiple registers can be specified across multiple banks. This is needed,
> - for example, for packaged NAND devices with multiple dies. Such devices
> - should be grouped into a single node.
> -
> -Optional child node properties:
> -- ingenic,nemc-bus-width: Specifies the bus width in bits. Defaults to 8
> bits.
> -- ingenic,nemc-tAS: Address setup time in nanoseconds.
> -- ingenic,nemc-tAH: Address hold time in nanoseconds.
> -- ingenic,nemc-tBP: Burst pitch time in nanoseconds.
> -- ingenic,nemc-tAW: Access wait time in nanoseconds.
> -- ingenic,nemc-tSTRV: Static memory recovery time in nanoseconds.
> -
> -If a child node references multiple banks in its "reg" property, the same
> value
> -for all optional parameters will be configured for all banks. If any optional
> -parameters are omitted, they will be left unchanged from whatever they are
> -configured to when the NEMC device is probed (which may be the reset value as
> -given in the hardware reference manual, or a value configured by the boot
> -loader).
> -
> -Example (NEMC node with a NAND child device attached at CS1):
> -
> -nemc: nemc@1341 {
> - compatible = "ingenic,jz4780-nemc";
> - reg = <0x1341 0x1>;
> -
> - #address-cells = <2>;
> - #size-cells = <1>;
> -
> - ranges = <1 0 0x1b00 0x100
> - 2 0 0x1a00 0x100
> - 3 0 0x1900 0x100
> - 4 0 0x1800 0x100
> - 5 0 0x1700 0x100
> - 6 0 0x1600 0x100>;
> -
> - clocks = < JZ4780_CLK_NEMC>;
> -
> - nand: nand@1 {
> - compatible = "ingenic,jz4780-nand";
> - reg = <1 0 0x100>;
> -
> - ingenic,nemc-tAS = <10>;
> - ingenic,nemc-tAH = <5>;
> - ingenic,nemc-tBP = <10>;
> - ingenic,nemc-tAW = <15>;
> - ingenic,nemc-tSTRV = <100>;
> -
> - ...
> - };
> -};
> diff --git
> a/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc-client.yaml
>
> b/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc-client.yaml
> new file mode 100644
> index ..682e6f7e74fa
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/memory-controllers/ingenic,nemc-client.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id:
> http://devicetree.org/schemas/memory-controllers/ingenic,nemc-client.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title:
> + Ingenic SoCs NAND / External Memory Controller (NEMC)
> + client-specific properties
> +
> +maintainers:
> + - Paul Cercueil
> +
> +description:
> + This document lists the various properties that child nodes of the NEMC
> node
> + can use.
> +
> +properties:
What about 'reg'? That should be required.
> +
Re: [PATCH v2 4/5] efi/x86: Remove extra headroom for setup block
On Mon, May 11, 2020 at 11:13:00PM +0200, Ard Biesheuvel wrote: > On Mon, 11 May 2020 at 20:36, Arvind Sankar wrote: > > > > On Mon, May 11, 2020 at 06:01:49PM +0100, Mike Lothian wrote: > > > Hi > > > > > > This patch has been causing issues for me since switching to GCC 10.1: > > > > > > CALLscripts/checksyscalls.sh > > > CALLscripts/atomic/check-atomics.sh > > > DESCEND objtool > > > CHK include/generated/compile.h > > > HOSTCC arch/x86/boot/tools/build > > > /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: > > > error: linker defined: multiple definition of '_end' > > > /usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: > > > /tmp/ccEkW0jM.o: previous definition here > > > collect2: error: ld returned 1 exit status > > > make[1]: *** [scripts/Makefile.host:103: arch/x86/boot/tools/build] Error > > > 1 > > > make: *** [arch/x86/Makefile:303: bzImage] Error 2 > > > > > > Cheers > > > > > > Mike > > > > I'm not getting an error even with gcc 10 for some reason, but I can see > > that it is busted. It's using the linker-defined _end symbol which is > > just pass the end of the .bss. > > > > Does adding "static" to the declaration of _end fix your error? > > This is in a host tool, so it depends on the builtin linker script the > toolchain decides to use. This is risky, though, as it may be using > PROVIDE() for _end, which means that in cases where it doesn't break, > other references to _end that may exist will be linked to the wrong > symbol. I don't think 'build' should be expected to do anything > interesting with its own representation in memory, but better fix it > nonetheless. Right, _end _is_ getting redefined in my system linker script too: I can see with objdump that the final _end symbol in my version of build is actually pointing beyond the .bss. But my toolchain doesn't report an error for some reason. > > Arvind: mind sending a fix for this, please? Yeah, I have one ready -- was just waiting to hear back if "static" did fix it, but I can send it out now.
Re: [PATCH v3 05/11] arm64: Add call_break_hook() to early_brk64() for early kgdb
Hi,
On Mon, May 11, 2020 at 7:59 AM Will Deacon wrote:
>
> Hi Doug,
>
> On Tue, Apr 28, 2020 at 02:13:45PM -0700, Douglas Anderson wrote:
> > diff --git a/arch/arm64/kernel/debug-monitors.c
> > b/arch/arm64/kernel/debug-monitors.c
> > index 48222a4760c2..59c353dfc8e9 100644
> > --- a/arch/arm64/kernel/debug-monitors.c
> > +++ b/arch/arm64/kernel/debug-monitors.c
> > @@ -297,7 +297,7 @@ void unregister_kernel_break_hook(struct break_hook
> > *hook)
> > unregister_debug_hook(>node);
> > }
> >
> > -static int call_break_hook(struct pt_regs *regs, unsigned int esr)
> > +int call_break_hook(struct pt_regs *regs, unsigned int esr)
> > {
> > struct break_hook *hook;
> > struct list_head *list;
> > diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> > index cf402be5c573..a8173f0c1774 100644
> > --- a/arch/arm64/kernel/traps.c
> > +++ b/arch/arm64/kernel/traps.c
> > @@ -1044,6 +1044,9 @@ int __init early_brk64(unsigned long addr, unsigned
> > int esr,
> > if ((comment & ~KASAN_BRK_MASK) == KASAN_BRK_IMM)
> > return kasan_handler(regs, esr) != DBG_HOOK_HANDLED;
> > #endif
> > + if (call_break_hook(regs, esr) == DBG_HOOK_HANDLED)
> > + return 0;
>
> I think this just means we're not running debug_traps_init() early enough,
> and actually the KASAN early handler is unnecessary too.
>
> If we call debug_traps_init() directly from setup_arch() and drop the
> arch_initcall(), can we then drop early_brk64 entirely?
It seems to work in my testing. ...but the worry I have is the
comment right before trap_init(). It says:
/* This registration must happen early, before debug_traps_init(). */
By moving debug_traps_init() early we're violating that comment. Do I
just remove that comment, or was there a good reason for it? ...or am
I reading it wrong and I should have read it as if it said:
/* NOTE: this registration happens early, before debug_traps_init(). */
...then removing it is fine. Maybe that's right?
I coded this up and put it on the Chrome OS gerrit at
. I'm happy to post this on the list as
a loner patch to replace this one or spin the whole series depending
on what people want.
-Doug
Re: [PATCH v11 07/56] Input: atmel_mxt_ts - implement T9 vector/orientation support
On Thu, May 07, 2020 at 10:56:07PM -0700, Jiada Wang wrote: > From: Nick Dyer > > The atmel touch messages contain orientation information as a byte in a > packed format which can be passed straight on to Android if the input > device configuration is correct. No, unfortunately I can not accept this. Please convert to the proper format for ABS_MT_ORIENTATION as defined in Documentation/input/multi-touch-protocol.rst Thanks. -- Dmitry
Re: [PATCH 3/8] dt-bindings: pinctrl: Convert ingenic,pinctrl.txt to YAML
On Sun, Apr 26, 2020 at 08:58:51PM +0200, Paul Cercueil wrote:
> Convert the ingenic,pinctrl.txt doc file to ingenic,pinctrl.yaml.
>
> In the process, some compatible strings now require a fallback, as the
> corresponding SoCs are pin-compatible with their fallback variant.
>
> Signed-off-by: Paul Cercueil
> ---
> .../bindings/pinctrl/ingenic,pinctrl.txt | 81 --
> .../bindings/pinctrl/ingenic,pinctrl.yaml | 138 ++
> 2 files changed, 138 insertions(+), 81 deletions(-)
> delete mode 100644
> Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.txt
> create mode 100644
> Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
> diff --git a/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
> b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
> new file mode 100644
> index ..adf462cc2737
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/ingenic,pinctrl.yaml
> @@ -0,0 +1,138 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pinctrl/ingenic,pinctrl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Ingenic SoCs pin controller devicetree bindings
> +
> +description: >
> + Please refer to pinctrl-bindings.txt in this directory for details of the
> + common pinctrl bindings used by client devices, including the meaning of
> the
> + phrase "pin configuration node".
> +
> + For the Ingenic SoCs, pin control is tightly bound with GPIO ports. All
> pins
> + may be used as GPIOs, multiplexed device functions are configured within
> the
> + GPIO port configuration registers and it is typical to refer to pins using
> the
> + naming scheme "PxN" where x is a character identifying the GPIO port with
> + which the pin is associated and N is an integer from 0 to 31 identifying
> the
> + pin within that GPIO port. For example PA0 is the first pin in GPIO port A,
> + and PB31 is the last pin in GPIO port B. The JZ4740, the X1000 and the
> X1830
> + contains 4 GPIO ports, PA to PD, for a total of 128 pins. The JZ4760, the
> + JZ4770 and the JZ4780 contains 6 GPIO ports, PA to PF, for a total of 192
> + pins.
> +
> +maintainers:
> + - Paul Cercueil
> +
> +properties:
> + nodename:
> +pattern: "^pin-controller@[0-9a-f]+$"
That would have been more consistent, but 'pinctrl@...' is the standard.
> +
> + compatible:
> +oneOf:
> + - enum:
> +- ingenic,jz4740-pinctrl
> +- ingenic,jz4725b-pinctrl
> +- ingenic,jz4760-pinctrl
> +- ingenic,jz4770-pinctrl
> +- ingenic,jz4780-pinctrl
> +- ingenic,x1000-pinctrl
> +- ingenic,x1500-pinctrl
> +- ingenic,x1830-pinctrl
> + - items:
> +- const: ingenic,jz4760b-pinctrl
> +- const: ingenic,jz4760-pinctrl
> + - items:
> +- const: ingenic,x1000e-pinctrl
> +- const: ingenic,x1000-pinctrl
> +
> + reg:
> +maxItems: 1
> +
> + "#address-cells":
> +const: 1
> +
> + "#size-cells":
> +const: 0
> +
> +patternProperties:
> + "^gpio@[0-9]$":
> +type: object
> +properties:
> + compatible:
> +enum:
> + - ingenic,jz4740-gpio
> + - ingenic,jz4725b-gpio
> + - ingenic,jz4760-gpio
> + - ingenic,jz4770-gpio
> + - ingenic,jz4780-gpio
> + - ingenic,x1000-gpio
> + - ingenic,x1500-gpio
> + - ingenic,x1830-gpio
> +
> + reg:
> +items:
> + - description: The GPIO bank number
> +
> + gpio-controller: true
> +
> + "#gpio-cells":
> +const: 2
> +
> + gpio-ranges:
> +maxItems: 1
> +
> + interrupt-controller: true
> +
> + "#interrupt-cells":
> +const: 2
> +description:
> + Refer to ../interrupt-controller/interrupts.txt for more details.
> +
> + interrupts:
> +maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - gpio-controller
> + - "#gpio-cells"
> + - interrupts
> + - interrupt-controller
> + - "#interrupt-cells"
> +
> +additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - "#address-cells"
> + - "#size-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> +pin-controller@1001 {
> + compatible = "ingenic,jz4770-pinctrl";
> + reg = <0x1001 0x600>;
> +
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + gpio@0 {
> +compatible = "ingenic,jz4770-gpio";
> +reg = <0>;
> +
> +gpio-controller;
> +gpio-ranges = < 0 0 32>;
> +#gpio-cells = <2>;
> +
> +interrupt-controller;
> +#interrupt-cells = <2>;
> +
> +interrupt-parent = <>;
> +interrupts = <17>;
> + };
> +};
What about pinctrl child nodes?
> --
> 2.26.2
>
mmotm 2020-05-11-15-43 uploaded
The mm-of-the-moment snapshot 2020-05-11-15-43 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (5.x or 5.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. https://github.com/hnaz/linux-mm The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is also available at https://github.com/hnaz/linux-mm This mmotm tree contains the following patches against 5.7-rc5: (patches marked "*" will be included in linux-next) * checkpatch-test-git_dir-changes.patch * proc-kpageflags-prevent-an-integer-overflow-in-stable_page_flags.patch * proc-kpageflags-do-not-use-uninitialized-struct-pages.patch * kcov-cleanup-debug-messages.patch * kcov-fix-potential-use-after-free-in-kcov_remote_start.patch * kcov-move-t-kcov-assignments-into-kcov_start-stop.patch * kcov-move-t-kcov_sequence-assignment.patch * kcov-use-t-kcov_mode-as-enabled-indicator.patch * kcov-collect-coverage-from-interrupts.patch * usb-core-kcov-collect-coverage-from-usb-complete-callback.patch * memcg-optimize-memorynuma_stat-like-memorystat.patch * mm-memcg-fix-inconsistent-oom-event-behavior.patch * epoll-call-final-ep_events_available-check-under-the-lock.patch * mm-gup-fix-fixup_user_fault-on-multiple-retries.patch * lib-lzo-fix-ambiguous-encoding-bug-in-lzo-rle.patch * userfaultfd-fix-remap-event-with-mremap_dontunmap.patch * ipc-utilc-sysvipc_find_ipc-incorrectly-updates-position-index.patch * ipc-utilc-sysvipc_find_ipc-incorrectly-updates-position-index-fix.patch * device-dax-dont-leak-kernel-memory-to-user-space-after-unloading-kmem.patch * scripts-support-compiled-source-improved-precise.patch * scripts-add-a-intermediate-file-for-make-gtags.patch * squashfs-migrate-from-ll_rw_block-usage-to-bio.patch * squashfs-migrate-from-ll_rw_block-usage-to-bio-fix.patch * ocfs2-add-missing-annotation-for-dlm_empty_lockres.patch * ocfs2-mount-shared-volume-without-ha-stack.patch * drivers-tty-serial-sh-scic-suppress-uninitialized-var-warning.patch * ramfs-support-o_tmpfile.patch * vfs-track-per-sb-writeback-errors-and-report-them-to-syncfs.patch * buffer-record-blockdev-write-errors-in-super_block-that-it-backs.patch * kernel-watchdog-flush-all-printk-nmi-buffers-when-hardlockup-detected.patch mm.patch * usercopy-mark-dma-kmalloc-caches-as-usercopy-caches.patch * mm-slub-fix-corrupted-freechain-in-deactivate_slab.patch * mm-slub-fix-corrupted-freechain-in-deactivate_slab-fix.patch * slub-remove-userspace-notifier-for-cache-add-remove.patch * slub-remove-kmalloc-under-list_lock-from-list_slab_objects.patch * mm-slub-fix-stack-overruns-with-slub_stats.patch * mm-slub-add-panic_on_error-to-the-debug-facilities.patch * mm-slub-add-panic_on_error-to-the-debug-facilities-fix.patch * mm-dump_page-do-not-crash-with-invalid-mapping-pointer.patch * mm-move-readahead-prototypes-from-mmh.patch * mm-return-void-from-various-readahead-functions.patch * mm-ignore-return-value-of-readpages.patch * mm-move-readahead-nr_pages-check-into-read_pages.patch * mm-add-new-readahead_control-api.patch * mm-use-readahead_control-to-pass-arguments.patch * mm-rename-various-offset-parameters-to-index.patch * mm-rename-readahead-loop-variable-to-i.patch * mm-remove-page_offset-from-readahead-loop.patch * mm-put-readahead-pages-in-cache-earlier.patch * mm-add-readahead-address-space-operation.patch * mm-move-end_index-check-out-of-readahead-loop.patch * mm-add-page_cache_readahead_unbounded.patch * mm-document-why-we-dont-set-pagereadahead.patch * mm-use-memalloc_nofs_save-in-readahead-path.patch * fs-convert-mpage_readpages-to-mpage_readahead.patch * btrfs-convert-from-readpages-to-readahead.patch * erofs-convert-uncompressed-files-from-readpages-to-readahead.patch * erofs-convert-compressed-files-from-readpages-to-readahead.patch * ext4-convert-from-readpages-to-readahead.patch *
My Dear in the lord
My Dear in the lord My name is Mrs. Mina A. Brunel I am a Norway Citizen who is living in Burkina Faso, I am married to Mr. Brunel Patrice, a politician who owns a small gold company in Burkina Faso; He died of Leprosy and Radesyge, in the year February 2010, During his lifetime he deposited the sum of € 8.5 Million Euro) Eight million, Five hundred thousand Euros in a bank in Ouagadougou the capital city of Burkina Faso in West Africa. The money was from the sale of his company and death benefits payment and entitlements of my deceased husband by his company. I am sending you this message with heavy tears in my eyes and great sorrow in my heart, and also praying that it will reach you in good health because I am not in good health, I sleep every night without knowing if I may be alive to see the next day. I am suffering from long time cancer and presently I am partially suffering from Leprosy, which has become difficult for me to move around. I was married to my late husband for more than 6 years without having a child and my doctor confided that I have less chance to live, having to know when the cup of death will come, I decided to contact you to claim the fund since I don't have any relation I grew up from an orphanage home. I have decided to donate this money for the support of helping Motherless babies/Less privileged/Widows and churches also to build the house of God because I am dying and diagnosed with cancer for about 3 years ago. I have decided to donate from what I have inherited from my late husband to you for the good work of Almighty God; I will be going in for an operation surgery soon. Now I want you to stand as my next of kin to claim the funds for charity purposes. Because of this money remains unclaimed after my death, the bank executives or the government will take the money as unclaimed fund and maybe use it for selfishness and worthless ventures, I need a very honest person who can claim this money and use it for Charity works, for orphanages, widows and also build schools and churches for less privilege that will be named after my late husband and my name. I need your urgent answer to know if you will be able to execute this project, and I will give you more information on how the fund will be transferred to your bank account or online banking. Thanks Mrs. Mina A. Brunel
[PATCH v3 2/5] drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP interlacing support
Right now, we make the mistake of allowing interlacing on all
connectors. Nvidia hardware does not always support interlacing with DP
though, so we need to make sure that we don't allow interlaced modes to
be set in such situations as otherwise we'll end up accidentally hanging
the display HW.
This fixes some hangs with Turing, which would be caused by attempting
to set an interlaced mode on hardware that doesn't support it. This
patch likely fixes other hardware hanging in the same way as well.
Note that we say we probe PIOR caps, but they don't actually have any
interlacing caps. So, the get_caps() function for PIORs just sets
interlacing support to true.
Changes since v1:
* Actually probe caps correctly this time, both on EVO and NVDisplay.
Changes since v2:
* Fix probing for < GF119
* Use vfunc table, in prep for adding more caps in the future.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/core.h | 7 ++
drivers/gpu/drm/nouveau/dispnv50/core507d.c | 15
drivers/gpu/drm/nouveau/dispnv50/core827d.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/core907d.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/core917d.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/corec37d.c | 26 +
drivers/gpu/drm/nouveau/dispnv50/corec57d.c | 1 +
drivers/gpu/drm/nouveau/dispnv50/disp.c | 19 +--
drivers/gpu/drm/nouveau/dispnv50/disp.h | 1 +
drivers/gpu/drm/nouveau/dispnv50/pior507d.c | 8 +++
drivers/gpu/drm/nouveau/dispnv50/sor507d.c | 7 ++
drivers/gpu/drm/nouveau/dispnv50/sor907d.c | 11 +
drivers/gpu/drm/nouveau/dispnv50/sorc37d.c | 9 +++
drivers/gpu/drm/nouveau/nouveau_connector.c | 10 +++-
drivers/gpu/drm/nouveau/nouveau_encoder.h | 4
15 files changed, 118 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/core.h
b/drivers/gpu/drm/nouveau/dispnv50/core.h
index ff94f3f6f264..99157dc94d23 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/core.h
+++ b/drivers/gpu/drm/nouveau/dispnv50/core.h
@@ -2,6 +2,7 @@
#define __NV50_KMS_CORE_H__
#include "disp.h"
#include "atom.h"
+#include
struct nv50_core {
const struct nv50_core_func *func;
@@ -15,6 +16,7 @@ void nv50_core_del(struct nv50_core **);
struct nv50_core_func {
void (*init)(struct nv50_core *);
void (*ntfy_init)(struct nouveau_bo *, u32 offset);
+ int (*caps_init)(struct nouveau_drm *, struct nv50_disp *);
int (*ntfy_wait_done)(struct nouveau_bo *, u32 offset,
struct nvif_device *);
void (*update)(struct nv50_core *, u32 *interlock, bool ntfy);
@@ -27,6 +29,9 @@ struct nv50_core_func {
const struct nv50_outp_func {
void (*ctrl)(struct nv50_core *, int or, u32 ctrl,
struct nv50_head_atom *);
+ /* XXX: Only used by SORs and PIORs for now */
+ void (*get_caps)(struct nv50_disp *,
+struct nouveau_encoder *, int or);
} *dac, *pior, *sor;
};
@@ -35,6 +40,7 @@ int core507d_new_(const struct nv50_core_func *, struct
nouveau_drm *, s32,
struct nv50_core **);
void core507d_init(struct nv50_core *);
void core507d_ntfy_init(struct nouveau_bo *, u32);
+int core507d_caps_init(struct nouveau_drm *, struct nv50_disp *);
int core507d_ntfy_wait_done(struct nouveau_bo *, u32, struct nvif_device *);
void core507d_update(struct nv50_core *, u32 *, bool);
@@ -51,6 +57,7 @@ extern const struct nv50_outp_func sor907d;
int core917d_new(struct nouveau_drm *, s32, struct nv50_core **);
int corec37d_new(struct nouveau_drm *, s32, struct nv50_core **);
+int corec37d_caps_init(struct nouveau_drm *, struct nv50_disp *);
int corec37d_ntfy_wait_done(struct nouveau_bo *, u32, struct nvif_device *);
void corec37d_update(struct nv50_core *, u32 *, bool);
void corec37d_wndw_owner(struct nv50_core *);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
index c5152c39c684..e341f572c269 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/core507d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/core507d.c
@@ -62,6 +62,20 @@ core507d_ntfy_init(struct nouveau_bo *bo, u32 offset)
nouveau_bo_wr32(bo, offset / 4, 0x);
}
+int
+core507d_caps_init(struct nouveau_drm *drm, struct nv50_disp *disp)
+{
+ u32 *push = evo_wait(>core->chan, 2);
+
+ if (push) {
+ evo_mthd(push, 0x008c, 1);
+ evo_data(push, 0x0);
+ evo_kick(push, >core->chan);
+ }
+
+ return 0;
+}
+
void
core507d_init(struct nv50_core *core)
{
@@ -77,6 +91,7 @@ static const struct nv50_core_func
core507d = {
.init = core507d_init,
.ntfy_init = core507d_ntfy_init,
+ .caps_init = core507d_caps_init,
.ntfy_wait_done = core507d_ntfy_wait_done,
.update = core507d_update,
.head = ,
diff --git
[PATCH v3 0/5] drm/nouveau: DP interlace fixes
Currently, nouveau doesn't actually bother to try probing whether or not it can actually handle interlaced modes over DisplayPort. As a result, on volta and later we'll end up trying to set an interlaced mode even when it's not supported and cause the front end for the display engine to hang. So, let's teach nouveau to reject interlaced modes on hardware that can't actually handle it. Additionally for MST, since we accomplish this by simply reusing more of the SST mode validation we also get (some) basic bw validation for modes we detect on MST connectors completely for free. Lyude Paul (5): drm/nouveau/kms/nv50-: Initialize core channel in nouveau_display_create() drm/nouveau/kms/nv50-: Probe SOR and PIOR caps for DP interlacing support drm/nouveau/kms/gv100-: Add support for interlaced modes drm/nouveau/kms/nv50-: Move 8BPC limit for MST into nv50_mstc_get_modes() drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST drivers/gpu/drm/nouveau/dispnv50/core.h | 7 +++ drivers/gpu/drm/nouveau/dispnv50/core507d.c | 15 ++ drivers/gpu/drm/nouveau/dispnv50/core827d.c | 1 + drivers/gpu/drm/nouveau/dispnv50/core907d.c | 1 + drivers/gpu/drm/nouveau/dispnv50/core917d.c | 1 + drivers/gpu/drm/nouveau/dispnv50/corec37d.c | 26 + drivers/gpu/drm/nouveau/dispnv50/corec57d.c | 1 + drivers/gpu/drm/nouveau/dispnv50/disp.c | 58 +++-- drivers/gpu/drm/nouveau/dispnv50/disp.h | 1 + drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 5 +- drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 5 +- drivers/gpu/drm/nouveau/dispnv50/pior507d.c | 8 +++ drivers/gpu/drm/nouveau/dispnv50/sor507d.c | 7 +++ drivers/gpu/drm/nouveau/dispnv50/sor907d.c | 11 drivers/gpu/drm/nouveau/dispnv50/sorc37d.c | 9 drivers/gpu/drm/nouveau/nouveau_connector.c | 48 +++-- drivers/gpu/drm/nouveau/nouveau_connector.h | 5 ++ drivers/gpu/drm/nouveau/nouveau_dp.c| 31 +++ drivers/gpu/drm/nouveau/nouveau_encoder.h | 8 +++ 19 files changed, 213 insertions(+), 35 deletions(-) -- 2.26.2
[PATCH v3 1/5] drm/nouveau/kms/nv50-: Initialize core channel in nouveau_display_create()
We'll need the core channel initialized and ready by the time that we
start creating modesetting objects, so that we can call the
NV507D_GET_CAPABILITIES method to make the hardware expose it's
modesetting capabilities for later probing.
So, when loading the driver prepare the core channel from within
nouveau_display_create(). Everywhere else, we initialize the core
channel during resume.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index 6be9df1820c5..05b458b16e3f 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -2369,7 +2369,8 @@ nv50_display_init(struct drm_device *dev, bool resume,
bool runtime)
struct drm_encoder *encoder;
struct drm_plane *plane;
- core->func->init(core);
+ if (resume || runtime)
+ core->func->init(core);
list_for_each_entry(encoder, >mode_config.encoder_list, head) {
if (encoder->encoder_type != DRM_MODE_ENCODER_DPMST) {
@@ -2456,6 +2457,8 @@ nv50_display_create(struct drm_device *dev)
if (ret)
goto out;
+ disp->core->func->init(disp->core);
+
/* create crtc objects to represent the hw heads */
if (disp->disp->object.oclass >= GV100_DISP)
crtcs = nvif_rd32(>object, 0x610060) & 0xff;
--
2.26.2
[PATCH v3 3/5] drm/nouveau/kms/gv100-: Add support for interlaced modes
We advertise being able to set interlaced modes, so let's actually make
sure to do that. Otherwise, we'll end up hanging the display engine due
to trying to set a mode with timings adjusted for interlacing without
telling the hardware it's actually an interlaced mode.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/headc37d.c | 5 +++--
drivers/gpu/drm/nouveau/dispnv50/headc57d.c | 5 +++--
drivers/gpu/drm/nouveau/nouveau_connector.c | 2 +-
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
b/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
index 00011ce109a6..4a9a32b89f74 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc37d.c
@@ -168,14 +168,15 @@ headc37d_mode(struct nv50_head *head, struct
nv50_head_atom *asyh)
struct nv50_dmac *core = _disp(head->base.base.dev)->core->chan;
struct nv50_head_mode *m = >mode;
u32 *push;
- if ((push = evo_wait(core, 12))) {
+ if ((push = evo_wait(core, 13))) {
evo_mthd(push, 0x2064 + (head->base.index * 0x400), 5);
evo_data(push, (m->v.active << 16) | m->h.active );
evo_data(push, (m->v.synce << 16) | m->h.synce );
evo_data(push, (m->v.blanke << 16) | m->h.blanke );
evo_data(push, (m->v.blanks << 16) | m->h.blanks );
evo_data(push, (m->v.blank2e << 16) | m->v.blank2s);
- evo_mthd(push, 0x200c + (head->base.index * 0x400), 1);
+ evo_mthd(push, 0x2008 + (head->base.index * 0x400), 2);
+ evo_data(push, m->interlace);
evo_data(push, m->clock * 1000);
evo_mthd(push, 0x2028 + (head->base.index * 0x400), 1);
evo_data(push, m->clock * 1000);
diff --git a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
index 938d910a1b1e..859131a8bc3c 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/headc57d.c
@@ -173,14 +173,15 @@ headc57d_mode(struct nv50_head *head, struct
nv50_head_atom *asyh)
struct nv50_dmac *core = _disp(head->base.base.dev)->core->chan;
struct nv50_head_mode *m = >mode;
u32 *push;
- if ((push = evo_wait(core, 12))) {
+ if ((push = evo_wait(core, 13))) {
evo_mthd(push, 0x2064 + (head->base.index * 0x400), 5);
evo_data(push, (m->v.active << 16) | m->h.active );
evo_data(push, (m->v.synce << 16) | m->h.synce );
evo_data(push, (m->v.blanke << 16) | m->h.blanke );
evo_data(push, (m->v.blanks << 16) | m->h.blanks );
evo_data(push, (m->v.blank2e << 16) | m->v.blank2s);
- evo_mthd(push, 0x200c + (head->base.index * 0x400), 1);
+ evo_mthd(push, 0x2008 + (head->base.index * 0x400), 2);
+ evo_data(push, m->interlace);
evo_data(push, m->clock * 1000);
evo_mthd(push, 0x2028 + (head->base.index * 0x400), 1);
evo_data(push, m->clock * 1000);
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 43bcbb6d73c4..6dae00da5d7e 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -1065,7 +1065,7 @@ nouveau_connector_mode_valid(struct drm_connector
*connector,
return get_slave_funcs(encoder)->mode_valid(encoder, mode);
case DCB_OUTPUT_DP:
if (mode->flags & DRM_MODE_FLAG_INTERLACE &&
- !nv_encoder->dp.caps.interlace)
+ !nv_encoder->caps.dp_interlace)
return MODE_NO_INTERLACE;
max_clock = nv_encoder->dp.link_nr;
--
2.26.2
[PATCH v3 5/5] drm/nouveau/kms/nv50-: Share DP SST mode_valid() handling with MST
Currently, the nv50_mstc_mode_valid() function is happy to take any and
all modes, even the ones we can't actually support sometimes like
interlaced modes.
Luckily, the only difference between the mode validation that needs to
be performed for MST vs. SST is that eventually we'll need to check the
minimum PBN against the MSTB's full PBN capabilities (remember-we don't
care about the current bw state here). Otherwise, all of the other code
can be shared.
So, we move all of the common mode validation in
nouveau_connector_mode_valid() into a separate helper,
nv50_dp_mode_valid(), and use that from both nv50_mstc_mode_valid() and
nouveau_connector_mode_valid(). Note that we allow for returning the
calculated clock that nv50_dp_mode_valid() came up with, since we'll
eventually want to use that for PBN calculation in
nv50_mstc_mode_valid().
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 9 +++-
drivers/gpu/drm/nouveau/nouveau_connector.c | 46 -
drivers/gpu/drm/nouveau/nouveau_connector.h | 5 +++
drivers/gpu/drm/nouveau/nouveau_dp.c| 31 ++
drivers/gpu/drm/nouveau/nouveau_encoder.h | 4 ++
5 files changed, 75 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index c49a6c47c66f..f3a77267ff09 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -1052,7 +1052,14 @@ static enum drm_mode_status
nv50_mstc_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
{
- return MODE_OK;
+ struct nv50_mstc *mstc = nv50_mstc(connector);
+ struct nouveau_encoder *outp = mstc->mstm->outp;
+
+ /* TODO: calculate the PBN from the dotclock and validate against the
+* MSTB's max possible PBN
+*/
+
+ return nv50_dp_mode_valid(connector, outp, mode, NULL);
}
static int
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c
b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 6dae00da5d7e..1b383ae0248f 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -38,6 +38,7 @@
#include "nouveau_reg.h"
#include "nouveau_drv.h"
#include "dispnv04/hw.h"
+#include "dispnv50/disp.h"
#include "nouveau_acpi.h"
#include "nouveau_display.h"
@@ -1033,6 +1034,29 @@ get_tmds_link_bandwidth(struct drm_connector *connector)
return 112000 * duallink_scale;
}
+enum drm_mode_status
+nouveau_conn_mode_clock_valid(const struct drm_display_mode *mode,
+ const unsigned min_clock,
+ const unsigned max_clock,
+ unsigned int *clock_out)
+{
+ unsigned int clock = mode->clock;
+
+ if ((mode->flags & DRM_MODE_FLAG_3D_MASK) ==
+ DRM_MODE_FLAG_3D_FRAME_PACKING)
+ clock *= 2;
+
+ if (clock < min_clock)
+ return MODE_CLOCK_LOW;
+ if (clock > max_clock)
+ return MODE_CLOCK_HIGH;
+
+ if (clock_out)
+ *clock_out = clock;
+
+ return MODE_OK;
+}
+
static enum drm_mode_status
nouveau_connector_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
@@ -1041,7 +1065,6 @@ nouveau_connector_mode_valid(struct drm_connector
*connector,
struct nouveau_encoder *nv_encoder = nv_connector->detected_encoder;
struct drm_encoder *encoder = to_drm_encoder(nv_encoder);
unsigned min_clock = 25000, max_clock = min_clock;
- unsigned clock = mode->clock;
switch (nv_encoder->dcb->type) {
case DCB_OUTPUT_LVDS:
@@ -1064,29 +1087,14 @@ nouveau_connector_mode_valid(struct drm_connector
*connector,
case DCB_OUTPUT_TV:
return get_slave_funcs(encoder)->mode_valid(encoder, mode);
case DCB_OUTPUT_DP:
- if (mode->flags & DRM_MODE_FLAG_INTERLACE &&
- !nv_encoder->caps.dp_interlace)
- return MODE_NO_INTERLACE;
-
- max_clock = nv_encoder->dp.link_nr;
- max_clock *= nv_encoder->dp.link_bw;
- clock = clock * (connector->display_info.bpc * 3) / 10;
- break;
+ return nv50_dp_mode_valid(connector, nv_encoder, mode, NULL);
default:
BUG();
return MODE_BAD;
}
- if ((mode->flags & DRM_MODE_FLAG_3D_MASK) ==
DRM_MODE_FLAG_3D_FRAME_PACKING)
- clock *= 2;
-
- if (clock < min_clock)
- return MODE_CLOCK_LOW;
-
- if (clock > max_clock)
- return MODE_CLOCK_HIGH;
-
- return MODE_OK;
+ return nouveau_conn_mode_clock_valid(mode, min_clock, max_clock,
+NULL);
}
static struct drm_encoder *
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.h
[PATCH v3 4/5] drm/nouveau/kms/nv50-: Move 8BPC limit for MST into nv50_mstc_get_modes()
This just limits the BPC for MST connectors to a maximum of 8 from
nv50_mstc_get_modes(), instead of doing so during
nv50_msto_atomic_check(). This doesn't introduce any functional changes
yet (other then userspace now lying about the max bpc, but we can't
support that yet anyway so meh). But, we'll need this in a moment so
that we can share mode validation between SST and MST which will fix
some real world issues.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index f67dffe8c005..c49a6c47c66f 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -904,15 +904,9 @@ nv50_msto_atomic_check(struct drm_encoder *encoder,
if (!state->duplicated) {
const int clock = crtc_state->adjusted_mode.clock;
- /*
-* XXX: Since we don't use HDR in userspace quite yet, limit
-* the bpc to 8 to save bandwidth on the topology. In the
-* future, we'll want to properly fix this by dynamically
-* selecting the highest possible bpc that would fit in the
-* topology
-*/
- asyh->or.bpc = min(connector->display_info.bpc, 8U);
- asyh->dp.pbn = drm_dp_calc_pbn_mode(clock, asyh->or.bpc * 3,
false);
+ asyh->or.bpc = connector->display_info.bpc;
+ asyh->dp.pbn = drm_dp_calc_pbn_mode(clock, asyh->or.bpc * 3,
+ false);
}
slots = drm_dp_atomic_find_vcpi_slots(state, >mgr, mstc->port,
@@ -1072,8 +1066,17 @@ nv50_mstc_get_modes(struct drm_connector *connector)
if (mstc->edid)
ret = drm_add_edid_modes(>connector, mstc->edid);
- if (!mstc->connector.display_info.bpc)
- mstc->connector.display_info.bpc = 8;
+ /*
+* XXX: Since we don't use HDR in userspace quite yet, limit the bpc
+* to 8 to save bandwidth on the topology. In the future, we'll want
+* to properly fix this by dynamically selecting the highest possible
+* bpc that would fit in the topology
+*/
+ if (connector->display_info.bpc)
+ connector->display_info.bpc =
+ clamp(connector->display_info.bpc, 6U, 8U);
+ else
+ connector->display_info.bpc = 8;
if (mstc->native)
drm_mode_destroy(mstc->connector.dev, mstc->native);
--
2.26.2
Re: [PATCH v7 00/18] pstore: mtd: support crash log to block and mtd device
On Sun, May 10, 2020 at 01:24:18PM -0700, Kees Cook wrote: > pstore/ram: Move dump_oops to end of module_param list > pstore/platform: Switch pstore_info::name to const > pstore/platform: Move module params after declarations > pstore/platform: Use backend name for console registration > pstore/ram: Refactor ftrace buffer merging > pstore/ftrace: Provide ftrace log merging routine > printk: Introduce kmsg_dump_reason_str() For those following along, I've added these to for-next/pstore, as they're all prep patches for the rest of this series. -- Kees Cook
Re: [PATCH 0/5] cachefiles, nfs: Fixes
On Fri, May 08 2020, David Howells wrote:
> Hi Linus, Trond, Anna,
>
> Can you pull these fixes for cachefiles and NFS's use of fscache? Should
> they go through the NFS tree or directly upstream? The things fixed are:
hi David,
thanks for these fscache fixes. Here is another for your consideration.
NeilBrown
From: NeilBrown
Date: Tue, 12 May 2020 08:32:25 +1000
Subject: [PATCH] cachefiles: fix inverted ASSERTion.
bmap() returns a negative result precisely when a_ops->bmap is NULL.
A recent patch converted
ASSERT(inode->i_mapping->a_ops->bmap);
to an assertion that bmap(inode, ...) returns a negative number.
This inverts the sense of the assertion.
So change it back : ASSERT(ret == 0)
Fixes: 10d83e11a582 ("cachefiles: drop direct usage of ->bmap method.")
Signed-off-by: NeilBrown
---
fs/cachefiles/rdwr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/cachefiles/rdwr.c b/fs/cachefiles/rdwr.c
index 1dc97f2d6201..a4573c96660c 100644
--- a/fs/cachefiles/rdwr.c
+++ b/fs/cachefiles/rdwr.c
@@ -431,7 +431,7 @@ int cachefiles_read_or_alloc_page(struct fscache_retrieval
*op,
block <<= shift;
ret = bmap(inode, );
- ASSERT(ret < 0);
+ ASSERT(ret == 0);
_debug("%llx -> %llx",
(unsigned long long) (page->index << shift),
--
2.26.2
signature.asc
Description: PGP signature
[PATCH] x86/platform/uv: HUB RTC cleanup
Remove unused event code and other cleanup for HUB RTC.
Signed-off-by: Dimitri Sivanich
---
arch/x86/platform/uv/uv_time.c | 362 +
1 file changed, 8 insertions(+), 354 deletions(-)
diff --git a/arch/x86/platform/uv/uv_time.c b/arch/x86/platform/uv/uv_time.c
index 7af31b245636..1777b7164ff8 100644
--- a/arch/x86/platform/uv/uv_time.c
+++ b/arch/x86/platform/uv/uv_time.c
@@ -1,25 +1,18 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/*
- * SGI RTC clock/timer routines.
+ * HPE RTC clock routine.
*
+ * Copyright (C) 2020 Hewlett Packard Enterprise, All rights reserved.
* Copyright (c) 2009-2013 Silicon Graphics, Inc. All Rights Reserved.
* Copyright (c) Dimitri Sivanich
*/
#include
-#include
-
#include
#include
-#include
-#include
-#include
-#include
-#define RTC_NAME "sgi_rtc"
+#define RTC_NAME "hub_rtc"
static u64 uv_read_rtc(struct clocksource *cs);
-static int uv_rtc_next_event(unsigned long, struct clock_event_device *);
-static int uv_rtc_shutdown(struct clock_event_device *evt);
static struct clocksource clocksource_uv = {
.name = RTC_NAME,
@@ -29,325 +22,23 @@ static struct clocksource clocksource_uv = {
.flags = CLOCK_SOURCE_IS_CONTINUOUS,
};
-static struct clock_event_device clock_event_device_uv = {
- .name = RTC_NAME,
- .features = CLOCK_EVT_FEAT_ONESHOT,
- .shift = 20,
- .rating = 400,
- .irq= -1,
- .set_next_event = uv_rtc_next_event,
- .set_state_shutdown = uv_rtc_shutdown,
- .event_handler = NULL,
-};
-
-static DEFINE_PER_CPU(struct clock_event_device, cpu_ced);
-
-/* There is one of these allocated per node */
-struct uv_rtc_timer_head {
- spinlock_t lock;
- /* next cpu waiting for timer, local node relative: */
- int next_cpu;
- /* number of cpus on this node: */
- int ncpus;
- struct {
- int lcpu; /* systemwide logical cpu number */
- u64 expires;/* next timer expiration for this cpu */
- } cpu[1];
-};
-
-/*
- * Access to uv_rtc_timer_head via blade id.
- */
-static struct uv_rtc_timer_head**blade_info __read_mostly;
-
-static int uv_rtc_evt_enable;
-
-/*
- * Hardware interface routines
- */
-
-/* Send IPIs to another node */
-static void uv_rtc_send_IPI(int cpu)
-{
- unsigned long apicid, val;
- int pnode;
-
- apicid = cpu_physical_id(cpu);
- pnode = uv_apicid_to_pnode(apicid);
- apicid |= uv_apicid_hibits;
- val = (1UL << UVH_IPI_INT_SEND_SHFT) |
- (apicid << UVH_IPI_INT_APIC_ID_SHFT) |
- (X86_PLATFORM_IPI_VECTOR << UVH_IPI_INT_VECTOR_SHFT);
-
- uv_write_global_mmr64(pnode, UVH_IPI_INT, val);
-}
-
-/* Check for an RTC interrupt pending */
-static int uv_intr_pending(int pnode)
-{
- if (is_uv1_hub())
- return uv_read_global_mmr64(pnode, UVH_EVENT_OCCURRED0) &
- UV1H_EVENT_OCCURRED0_RTC1_MASK;
- else if (is_uvx_hub())
- return uv_read_global_mmr64(pnode, UVXH_EVENT_OCCURRED2) &
- UVXH_EVENT_OCCURRED2_RTC_1_MASK;
- return 0;
-}
-
-/* Setup interrupt and return non-zero if early expiration occurred. */
-static int uv_setup_intr(int cpu, u64 expires)
-{
- u64 val;
- unsigned long apicid = cpu_physical_id(cpu) | uv_apicid_hibits;
- int pnode = uv_cpu_to_pnode(cpu);
-
- uv_write_global_mmr64(pnode, UVH_RTC1_INT_CONFIG,
- UVH_RTC1_INT_CONFIG_M_MASK);
- uv_write_global_mmr64(pnode, UVH_INT_CMPB, -1L);
-
- if (is_uv1_hub())
- uv_write_global_mmr64(pnode, UVH_EVENT_OCCURRED0_ALIAS,
- UV1H_EVENT_OCCURRED0_RTC1_MASK);
- else
- uv_write_global_mmr64(pnode, UVXH_EVENT_OCCURRED2_ALIAS,
- UVXH_EVENT_OCCURRED2_RTC_1_MASK);
-
- val = (X86_PLATFORM_IPI_VECTOR << UVH_RTC1_INT_CONFIG_VECTOR_SHFT) |
- ((u64)apicid << UVH_RTC1_INT_CONFIG_APIC_ID_SHFT);
-
- /* Set configuration */
- uv_write_global_mmr64(pnode, UVH_RTC1_INT_CONFIG, val);
- /* Initialize comparator value */
- uv_write_global_mmr64(pnode, UVH_INT_CMPB, expires);
-
- if (uv_read_rtc(NULL) <= expires)
- return 0;
-
- return !uv_intr_pending(pnode);
-}
-
-/*
- * Per-cpu timer tracking routines
- */
-
-static __init void uv_rtc_deallocate_timers(void)
-{
- int bid;
-
- for_each_possible_blade(bid) {
- kfree(blade_info[bid]);
- }
- kfree(blade_info);
-}
-
-/* Allocate per-node list of cpu timer expiration times. */
-static __init int uv_rtc_allocate_timers(void)
-{
- int cpu;
-
-
Re: [PATCH v1 net-next 3/3] net: dsa: felix: add support Credit Based Shaper(CBS) for hardware offload
On Mon, 11 May 2020 13:43:32 +0800 Xiaoliang Yang wrote: > +int vsc9959_qos_port_cbs_set(struct dsa_switch *ds, int port, > + struct tc_cbs_qopt_offload *cbs_qopt) static
Re: [PATCH 2/8] dt-bindings: intc: Convert ingenic,intc.txt to YAML
On Sun, 26 Apr 2020 20:58:50 +0200, Paul Cercueil wrote: > Convert the ingenic,intc.txt doc file to ingenic,intc.yaml. > > Some compatible strings now require a fallback, as the controller > generally works the same across the SoCs families. > > Signed-off-by: Paul Cercueil > --- > .../interrupt-controller/ingenic,intc.txt | 28 - > .../interrupt-controller/ingenic,intc.yaml| 63 +++ > 2 files changed, 63 insertions(+), 28 deletions(-) > delete mode 100644 > Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.txt > create mode 100644 > Documentation/devicetree/bindings/interrupt-controller/ingenic,intc.yaml > Applied, thanks!
Re: [PATCH 1/8] dt-bindings: clock: Convert ingenic,cgu.txt to YAML
On Sun, 26 Apr 2020 20:58:49 +0200, Paul Cercueil wrote: > Convert the ingenic,cgu.txt doc file to ingenic,cgu.yaml. > > The binding documentation has been updated as well. The node can have a > child node that corresponds to the USB PHY, which happens to be present > in the middle of the CGU registers. > > Signed-off-by: Paul Cercueil > --- > .../devicetree/bindings/clock/ingenic,cgu.txt | 57 > .../bindings/clock/ingenic,cgu.yaml | 122 ++ > 2 files changed, 122 insertions(+), 57 deletions(-) > delete mode 100644 Documentation/devicetree/bindings/clock/ingenic,cgu.txt > create mode 100644 Documentation/devicetree/bindings/clock/ingenic,cgu.yaml > Applied, thanks!
Re: [PATCH v3 05/16] mfd: Add support for Kontron sl28cpld management controller
Am 2020-05-11 23:44, schrieb Michael Walle:
Am 2020-05-11 23:13, schrieb Rob Herring:
On Thu, Apr 23, 2020 at 07:45:32PM +0200, Michael Walle wrote:
This patch adds core support for the board management controller
found
on the SMARC-sAL28 board. It consists of the following functions:
- watchdog
- GPIO controller
- PWM controller
- fan sensor
- interrupt controller
At the moment, this controller is used on the Kontron SMARC-sAL28
board.
Please note that the MFD driver is defined as bool in the Kconfig
because the next patch will add interrupt support.
Signed-off-by: Michael Walle
---
drivers/mfd/Kconfig| 19 +
drivers/mfd/Makefile | 2 +
drivers/mfd/sl28cpld.c | 153
+
3 files changed, 174 insertions(+)
create mode 100644 drivers/mfd/sl28cpld.c
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 0a59249198d3..be0c8d93c526 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -2060,5 +2060,24 @@ config SGI_MFD_IOC3
If you have an SGI Origin, Octane, or a PCI IOC3 card,
then say Y. Otherwise say N.
+config MFD_SL28CPLD
+ bool "Kontron sl28 core driver"
+ depends on I2C=y
+ depends on OF
+ select REGMAP_I2C
+ select MFD_CORE
+ help
+ This option enables support for the board management controller
+ found on the Kontron sl28 CPLD. You have to select individual
+ functions, such as watchdog, GPIO, etc, under the corresponding
menus
+ in order to enable them.
+
+ Currently supported boards are:
+
+ Kontron SMARC-sAL28
+
+ To compile this driver as a module, choose M here: the module
will be
+ called sl28cpld.
+
endmenu
endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index f935d10cbf0f..9bc38863b9c7 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -259,3 +259,5 @@ obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o
obj-$(CONFIG_MFD_STMFX)+= stmfx.o
obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
+
+obj-$(CONFIG_MFD_SL28CPLD) += sl28cpld.o
diff --git a/drivers/mfd/sl28cpld.c b/drivers/mfd/sl28cpld.c
new file mode 100644
index ..1e5860cc7ffc
--- /dev/null
+++ b/drivers/mfd/sl28cpld.c
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * MFD core for the sl28cpld.
+ *
+ * Copyright 2019 Kontron Europe GmbH
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SL28CPLD_VERSION 0x03
+#define SL28CPLD_WATCHDOG_BASE 0x04
+#define SL28CPLD_HWMON_FAN_BASE0x0b
+#define SL28CPLD_PWM0_BASE 0x0c
+#define SL28CPLD_PWM1_BASE 0x0e
+#define SL28CPLD_GPIO0_BASE0x10
+#define SL28CPLD_GPIO1_BASE0x15
+#define SL28CPLD_GPO_BASE 0x1a
+#define SL28CPLD_GPI_BASE 0x1b
+#define SL28CPLD_INTC_BASE 0x1c
If you want to use 'reg' in the binding, these are the numbers you
should be using rather than making up numbering!
My motivation is that I don't want to hardcode the internal addresses
of the management controller in the device tree. For example if they
will move around with a later update of the controller, so a driver can
be compatible with both the old and the new version. If they are in the
device tree, only one register layout is possible.
However, I still don't think you need any child nodes. All the data in
the DT binding is right here in the driver already. There's no
advantage
to putting child nodes in DT, because this driver still has to be
updated if you add more nodes.
But then any phandle will reference the mfd device. And for example
there
are two different interrupt controllers, that is the INTC and the
GPIO[01],
which will then be combined into one device tree node, right?
So the mfd node would be
cpld: sl28cpld@4a {
interrupt-controller;
#interrupt-cells = <2>;
gpio-controller;
#gpio-cells = <2>;
[..]
};
and then depending on the mapping one could use:
interrupts-extended = < 0 FLAGS>; /* gpio0 line 0 */
interrupts-extended = < 8 FLAGS>; /* gpio1 line 0 */
interrupts-extended = < 12 FLAGS>; /* irq0 */
gpios = < 0> /* gpio0 line 0 */
But there is also offset 12, but then it is the GPI controller:
gpios = < 12> /* gpi line 0, nothing to do with irq0 */
I don't know if this is good practice, I guess you have to tell me. And
is it possible to combine any sub device into the mfd node in that way?
Oh I don't think that will work for the watchdog. If you just have one
watchdog it just looks odd.
cpld: sl28cpld@4a {
interrupt-controller;
#interrupt-cells = <2>;
gpio-controller;
#gpio-cells = <2>;
timeout-sec = <10>; /* watchdog property */
};
And won't pass the dtbindings check because the nodename is not
"watchdog(@[0-9]+)?". But it really falls short if you want to have
two watchdogs with different properties.
-michael
Re: [PATCH] dt-bindings: timer: Document allwinner,erratum-unknown1 property
On Sun, 26 Apr 2020 11:20:32 -0500, Samuel Holland wrote:
> This arch_timer property was added in commit c950ca8c35ee
> ("clocksource/drivers/arch_timer: Workaround for Allwinner A64 timer
> instability")
> but I omitted the device tree binding documentation. Now
> `make dtbs_check` prints the following warning for all A64 boards:
>
> timer: 'allwinner,erratum-unknown1' does not match any of the regexes:
> 'pinctrl-[0-9]+'
>
> Resolve this by documenting the erratum property.
>
> Signed-off-by: Samuel Holland
> ---
> Documentation/devicetree/bindings/timer/arm,arch_timer.yaml | 6 ++
> 1 file changed, 6 insertions(+)
>
Applied, thanks!
Re: [PATCH v3 2/7] dt-bindings: ASoC: sun4i-i2s: Add H6 compatible
On Sun, 26 Apr 2020 12:41:10 +0200, Clément Péron wrote: > From: Jernej Skrabec > > H6 I2S is very similar to H3, except that it supports up to 16 channels > and thus few registers have fields on different position. > > Signed-off-by: Jernej Skrabec > Signed-off-by: Marcus Cooper > Signed-off-by: Clément Péron > --- > .../devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml | 2 ++ > 1 file changed, 2 insertions(+) > Acked-by: Rob Herring
Re: [PATCH] dt-bindings: gpu: add power-domains #cooling-cells to arm, mali-bifrost.yaml
On Sat, 25 Apr 2020 17:40:37 +0200, Johan Jonker wrote: > A test with the command below gives this error: > > arch/arm64/boot/dts/rockchip/px30-evb.dt.yaml: gpu@ff40: > '#cooling-cells', 'power-domains' > do not match any of the regexes: 'pinctrl-[0-9]+' > > With the conversion to yaml it also filters things > in a node that are used by other drivers like > '#cooling-cells' and 'power-domains' > for Rockchip px30 gpu nodes, > so add them to 'arm,mali-bifrost.yaml'. > > make ARCH=arm64 dtbs_check > DT_SCHEMA_FILES=Documentation/devicetree/bindings/gpu/ > arm,mali-bifrost.yaml > > Signed-off-by: Johan Jonker > --- > Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml | 6 ++ > 1 file changed, 6 insertions(+) > Applied, thanks!
Re: [PATCH] dt-bindings: usb: dwc2: add power-domains property
On Sat, 25 Apr 2020 19:08:33 +0200, Johan Jonker wrote: > A test with the command below gives this error: > > arch/arm64/boot/dts/rockchip/px30-evb.dt.yaml: usb@ff30: > 'power-domains' does not match any of the regexes: 'pinctrl-[0-9]+' > > With the conversion to yaml it also filters things > in a node that are used by other drivers like > 'power-domains' for Rockchip px30 usb nodes, > so add them to 'dwc2.yaml'. > > make ARCH=arm64 dtbs_check > DT_SCHEMA_FILES=Documentation/devicetree/bindings/usb/dwc2.yaml > > Signed-off-by: Johan Jonker > --- > Documentation/devicetree/bindings/usb/dwc2.yaml | 3 +++ > 1 file changed, 3 insertions(+) > Applied, thanks!
Re: [PATCH 5/5] exec: Move the call of prepare_binprm into search_binary_handler
On Sat, May 09, 2020 at 02:42:52PM -0500, Eric W. Biederman wrote: > > The code in prepare_binary_handler needs to be run every time > search_binary_handler is called so move the call into search_binary_handler > itself to make the code simpler and easier to understand. > > Signed-off-by: "Eric W. Biederman" Yes, nice. :) I don't see any ordering dependencies here. The only thing I see is a potential for more "work done by kernel before bailing" in the sense that the arg copying will be performed before we check the kernel_read() result. I struggle to see how that might be a problem, and this get us to fewer exec.c exports. Yay! Reviewed-by: Kees Cook -- Kees Cook
Re: [PATCH v11 05/56] Input: atmel_mxt_ts - output status from T48 Noise Supression
On Thu, May 07, 2020 at 10:56:05PM -0700, Jiada Wang wrote:
> From: Nick Dyer
>
> This patch outputs status from T48 Noise Supression
>
> Signed-off-by: Nick Dyer
> Acked-by: Benson Leung
> Acked-by: Yufeng Shen
> (cherry picked from ndyer/linux/for-upstream commit
> 2895a6ff150a49f27a02938f8d262be238b296d8)
> Signed-off-by: George G. Davis
> Signed-off-by: Jiada Wang
> ---
> drivers/input/touchscreen/atmel_mxt_ts.c | 25
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
> b/drivers/input/touchscreen/atmel_mxt_ts.c
> index 7e6a66e3e1e0..a53985a7736f 100644
> --- a/drivers/input/touchscreen/atmel_mxt_ts.c
> +++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> @@ -324,6 +324,7 @@ struct mxt_data {
> u16 T18_address;
> u8 T19_reportid;
> u16 T44_address;
> + u8 T48_reportid;
> u8 T100_reportid_min;
> u8 T100_reportid_max;
>
> @@ -978,6 +979,24 @@ static void mxt_proc_t100_message(struct mxt_data *data,
> u8 *message)
> data->update_input = true;
> }
>
> +static int mxt_proc_t48_messages(struct mxt_data *data, u8 *msg)
> +{
> + struct device *dev = >client->dev;
> + u8 status, state;
> +
> + status = msg[1];
> + state = msg[4];
> +
> + dev_dbg(dev, "T48 state %d status %02X %s%s%s%s%s\n", state, status,
> + status & 0x01 ? "FREQCHG " : "",
> + status & 0x02 ? "APXCHG " : "",
> + status & 0x04 ? "ALGOERR " : "",
> + status & 0x10 ? "STATCHG " : "",
> + status & 0x20 ? "NLVLCHG " : "");
Should we define symbolic names for these bits, like you did for T42
in the next patch?
Thanks.
--
Dmitry
Re: [PATCH v2 1/2] dt-bindings: mfd: Add ENE KB3930 Embedded Controller binding
On Sat, 25 Apr 2020 00:11:22 +0200, Lubomir Rintel wrote: > Add binding document for the ENE KB3930 Embedded Controller. > > Signed-off-by: Lubomir Rintel > > --- > Changes since v1: > - Addressed binding validation failure > > .../devicetree/bindings/mfd/ene-kb3930.yaml | 55 +++ > 1 file changed, 55 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/ene-kb3930.yaml > Reviewed-by: Rob Herring
Re: [PATCH v11 04/56] Input: atmel_mxt_ts - split large i2c transfers into blocks
Hi Jiada, Nick, On Thu, May 07, 2020 at 10:56:04PM -0700, Jiada Wang wrote: > From: Nick Dyer > > On some firmware variants, the size of the info block exceeds what can > be read in a single transfer. Is this limitation of the mXT controller or maybe it is issue with implementation of the particular i2c adapter and should be dealt with there? Thanks. -- Dmitry
Re: [PATCH v4 4/5] dt-bindings: remoteproc: Add documentation for ZynqMP R5 rproc bindings
On Fri, Apr 24, 2020 at 10:36:09AM -0700, Ben Levinsky wrote:
> Add binding for ZynqMP R5 OpenAMP.
>
> Represent the RPU domain resources in one device node. Each RPU
> processor is a subnode of the top RPU domain node.
This needs to be sorted out as part of the system DT effort that Xilinx
is working on. I can't see this binding co-existing with it.
>
> Signed-off-by: Ben Levinsky
> Signed-off-by: Jason Wu
> Signed-off-by: Wendy Liang
> Signed-off-by: Michal Simek
> ---
> Changes since v2:
> - update zynqmp_r5 yaml parsing to not raise warnings for extra
> information in children of R5 node. The warning "node has a unit
> name, but no reg or ranges property" will still be raised though
> as this particular node is needed to describe the
> '#address-cells' and '#size-cells' information.
> Changes since 3:
> - remove warning '/example-0/rpu@ff9a/r5@0:
> node has a unit name, but no reg or ranges property'
> by adding reg to r5 node.
> ---
>
> .../remoteproc/xilinx,zynqmp-r5-remoteproc.yaml| 127
> +
> 1 file changed, 127 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
>
> diff --git
> a/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
>
> b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
> new file mode 100644
> index 000..41520b6
> --- /dev/null
> +++
> b/Documentation/devicetree/bindings/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml
> @@ -0,0 +1,127 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id:
> "http://devicetree.org/schemas/remoteproc/xilinx,zynqmp-r5-remoteproc.yaml#;
> +$schema: "http://devicetree.org/meta-schemas/core.yaml#;
> +
> +title: Xilinx R5 remote processor controller bindings
> +
> +description:
> + This document defines the binding for the remoteproc component that loads
> and
> + boots firmwares on the Xilinx Zynqmp and Versal family chipset.
> +
> +maintainers:
> + - Ed Mooring
> + - Ben Levinsky
> +
> +properties:
> + compatible:
> +const: "xlnx,zynqmp-r5-remoteproc-1.0"
> +
> + core_conf:
> +description:
> + R5 core configuration (valid string - split or lock-step)
> +maxItems: 1
> +
> + interrupts:
> +description:
> + Interrupt mapping for remoteproc IPI. It is required if the
> + user uses the remoteproc driver with the RPMsg kernel driver.
> +maxItems: 6
> +
> + memory-region:
> +maxItems: 4
> +minItems: 4
> + pnode-id:
> +maxItems: 1
What is this?
> + mboxes:
> +maxItems: 2
> + mbox-names:
> +maxItems: 2
> +
> + r5@0:
> +type: object
> +required:
> +- '#address-cells'
> +- '#size-cells'
> +- pnode-id
> +examples:
> + - |
> + reserved-memory {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + rpu0vdev0vring0: rpu0vdev0vring0@3ed4 {
> + no-map;
> + reg = <0x3ed4 0x4000>;
> + };
> + rpu0vdev0vring1: rpu0vdev0vring1@3ed44000 {
> + no-map;
> + reg = <0x3ed44000 0x4000>;
> + };
> + rpu0vdev0buffer: rpu0vdev0buffer@3ed48000 {
> + no-map;
> + reg = <0x3ed48000 0x10>;
> + };
> + rproc_0_reserved: rproc@3ed00 {
> + no-map;
> + reg = <0x3ed0 0x4>;
> + };
> + };
> + rpu: rpu@ff9a {
> + compatible = "xlnx,zynqmp-r5-remoteproc-1.0";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + core_conf = "split";
If split, then where is the 2nd core?
> + reg = <0xFF9A 0x1>;
> + r5_0: r5@0 {
Unit-addresses are based on 'reg' values.
> + ranges;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + reg = <0xFF9A0100 0x1000>;
> + memory-region = <_0_reserved>, <>,
> <>, <>;
> + pnode-id = <0x7>;
> + mboxes = <_mailbox_rpu0 0>, <_mailbox_rpu0 1>;
> + mbox-names = "tx", "rx";
> + tcm_0_a: tcm_0@0 {
> +#address-cells = <1>;
> +#size-cells = <1>;
> +reg = <0xFFE0 0x1>;
> +pnode-id = <0xf>;
These nodes probably need some sort of compatible. And don't the TCMs
have different addresses for R5 vs. the A cores?
> + };
> + tcm_0_b: tcm_0@1 {
> +#address-cells = <2>;
> +#size-cells = <2>;
> +reg = <0xFFE2 0x1>;
> +pnode-id = <0x10>;
> + };
> + };
> + };
> +
> +
> + zynqmp_ipi1 {
> + compatible = "xlnx,zynqmp-ipi-mailbox";
> + interrupt-parent = <>;
> +
Re: [PATCH V4] f2fs: Avoid double lock for cp_rwsem during checkpoint
On 05/11, Chao Yu wrote:
> On 2020/5/10 3:03, Jaegeuk Kim wrote:
> > On 05/09, Chao Yu wrote:
> >> On 2020/5/9 0:10, Jaegeuk Kim wrote:
> >>> Hi Sayali,
> >>>
> >>> In order to address the perf regression, how about this?
> >>>
> >>> >From 48418af635884803ffb35972df7958a2e6649322 Mon Sep 17 00:00:00 2001
> >>> From: Jaegeuk Kim
> >>> Date: Fri, 8 May 2020 09:08:37 -0700
> >>> Subject: [PATCH] f2fs: avoid double lock for cp_rwsem during checkpoint
> >>>
> >>> There could be a scenario where f2fs_sync_node_pages gets
> >>> called during checkpoint, which in turn tries to flush
> >>> inline data and calls iput(). This results in deadlock as
> >>> iput() tries to hold cp_rwsem, which is already held at the
> >>> beginning by checkpoint->block_operations().
> >>>
> >>> Call stack :
> >>>
> >>> Thread A Thread B
> >>> f2fs_write_checkpoint()
> >>> - block_operations(sbi)
> >>> - f2fs_lock_all(sbi);
> >>> - down_write(>cp_rwsem);
> >>>
> >>> - open()
> >>> - igrab()
> >>> - write() write inline data
> >>> - unlink()
> >>> - f2fs_sync_node_pages()
> >>> - if (is_inline_node(page))
> >>> - flush_inline_data()
> >>>- ilookup()
> >>> page = f2fs_pagecache_get_page()
> >>> if (!page)
> >>> goto iput_out;
> >>> iput_out:
> >>> -close()
> >>> -iput()
> >>>iput(inode);
> >>>- f2fs_evict_inode()
> >>> - f2fs_truncate_blocks()
> >>> - f2fs_lock_op()
> >>>- down_read(>cp_rwsem);
> >>>
> >>> Fixes: 2049d4fcb057 ("f2fs: avoid multiple node page writes due to
> >>> inline_data")
> >>> Signed-off-by: Sayali Lokhande
> >>> Signed-off-by: Jaegeuk Kim
> >>> ---
> >>> fs/f2fs/node.c | 4 ++--
> >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> >>> index 1db8cabf727ef..626d7daca09de 100644
> >>> --- a/fs/f2fs/node.c
> >>> +++ b/fs/f2fs/node.c
> >>> @@ -1870,8 +1870,8 @@ int f2fs_sync_node_pages(struct f2fs_sb_info *sbi,
> >>> goto continue_unlock;
> >>> }
> >>>
> >>> - /* flush inline_data */
> >>> - if (is_inline_node(page)) {
> >>> + /* flush inline_data, if it's not sync path. */
> >>> + if (do_balance && is_inline_node(page)) {
> >>
> >> IIRC, this flow was designed to avoid running out of free space issue
> >> during checkpoint:
> >>
> >> 2049d4fcb057 ("f2fs: avoid multiple node page writes due to inline_data")
> >>
> >> The sceanrio is:
> >> 1. create fully node blocks
> >> 2. flush node blocks
> >> 3. write inline_data for all the node blocks again
> >> 4. flush node blocks redundantly
> >>
> >> I guess this may cause failing one case of fstest.
> >
> > Yeah, actually I was hitting 204 failure, and thus, revised like this.
> > Now, I don't see any regression in fstest.
> >
> >>From 8f1882acfb0a5fc43e5a2bbd576a8f3c681a7d2c Mon Sep 17 00:00:00 2001
> > From: Sayali Lokhande
> > Date: Thu, 30 Apr 2020 16:28:29 +0530
> > Subject: [PATCH] f2fs: Avoid double lock for cp_rwsem during checkpoint
> >
> > There could be a scenario where f2fs_sync_node_pages gets
> > called during checkpoint, which in turn tries to flush
> > inline data and calls iput(). This results in deadlock as
> > iput() tries to hold cp_rwsem, which is already held at the
> > beginning by checkpoint->block_operations().
> >
> > Call stack :
> >
> > Thread AThread B
> > f2fs_write_checkpoint()
> > - block_operations(sbi)
> > - f2fs_lock_all(sbi);
> > - down_write(>cp_rwsem);
> >
> > - open()
> > - igrab()
> > - write() write inline data
> > - unlink()
> > - f2fs_sync_node_pages()
> > - if (is_inline_node(page))
> > - flush_inline_data()
> >- ilookup()
> > page = f2fs_pagecache_get_page()
> > if (!page)
> > goto iput_out;
> > iput_out:
> > -close()
> > -iput()
> >iput(inode);
> >- f2fs_evict_inode()
> > - f2fs_truncate_blocks()
> > - f2fs_lock_op()
> >- down_read(>cp_rwsem);
> >
> > Fixes: 2049d4fcb057 ("f2fs: avoid multiple node page writes due to
> > inline_data")
> > Signed-off-by: Sayali Lokhande
> > Signed-off-by: Jaegeuk Kim
> > ---
> > fs/f2fs/checkpoint.c | 9 -
> > fs/f2fs/f2fs.h | 4 ++--
> > fs/f2fs/node.c | 10 +-
> > 3 files changed, 15 insertions(+), 8 deletions(-)
> >
> > diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
> > index d49f7a01d8a26..928aea4ff663d 100644
> > --- a/fs/f2fs/checkpoint.c
> > +++ b/fs/f2fs/checkpoint.c
> > @@ -1168,6 +1168,12 @@ static int block_operations(struct f2fs_sb_info *sbi)
> > };
> > int err = 0, cnt = 0;
> >
> > + /*
> > +* Let's flush node
Re: [PATCH 4/5] exec: Allow load_misc_binary to call prepare_binfmt unconditionally
On Sat, May 09, 2020 at 02:42:23PM -0500, Eric W. Biederman wrote:
>
> Add a flag preserve_creds that binfmt_misc can set to prevent
> credentials from being updated. This allows binfmrt_misc to always
> call prepare_binfmt. Allowing the credential computation logic to be
> consolidated.
>
> Ref: c407c033de84 ("[PATCH] binfmt_misc: improve calculation of interpreter's
> credentials")
> Signed-off-by: "Eric W. Biederman"
> ---
> fs/binfmt_misc.c| 15 +++
> fs/exec.c | 14 +-
> include/linux/binfmts.h | 2 ++
> 3 files changed, 14 insertions(+), 17 deletions(-)
>
> diff --git a/fs/binfmt_misc.c b/fs/binfmt_misc.c
> index 127fae9c21ab..16bfafd2671d 100644
> --- a/fs/binfmt_misc.c
> +++ b/fs/binfmt_misc.c
> @@ -218,19 +218,10 @@ static int load_misc_binary(struct linux_binprm *bprm)
> goto error;
>
> bprm->file = interp_file;
> - if (fmt->flags & MISC_FMT_CREDENTIALS) {
> - loff_t pos = 0;
> -
> - /*
> - * No need to call prepare_binprm(), it's already been
> - * done. bprm->buf is stale, update from interp_file.
> - */
> - memset(bprm->buf, 0, BINPRM_BUF_SIZE);
> - retval = kernel_read(bprm->file, bprm->buf, BINPRM_BUF_SIZE,
> - );
> - } else
> - retval = prepare_binprm(bprm);
> + if (fmt->flags & MISC_FMT_CREDENTIALS)
> + bprm->preserve_creds = 1;
>
> + retval = prepare_binprm(bprm);
> if (retval < 0)
> goto error;
>
> diff --git a/fs/exec.c b/fs/exec.c
> index 8bbf5fa785a6..01dbeb025c46 100644
> --- a/fs/exec.c
> +++ b/fs/exec.c
> @@ -1630,14 +1630,18 @@ static void bprm_fill_uid(struct linux_binprm *bprm)
> */
> int prepare_binprm(struct linux_binprm *bprm)
> {
> - int retval;
> loff_t pos = 0;
>
> - bprm_fill_uid(bprm);
> + if (!bprm->preserve_creds) {
nit: hint this to the common execution path:
if (likely(!bprm->preserve_creds) {
> + int retval;
>
> - retval = cap_bprm_set_creds(bprm);
> - if (retval)
> - return retval;
> + bprm_fill_uid(bprm);
> +
> + retval = cap_bprm_set_creds(bprm);
> + if (retval)
> + return retval;
> + }
> + bprm->preserve_creds = 0;
>
> memset(bprm->buf, 0, BINPRM_BUF_SIZE);
> return kernel_read(bprm->file, bprm->buf, BINPRM_BUF_SIZE, );
> diff --git a/include/linux/binfmts.h b/include/linux/binfmts.h
> index 89f1135dcb75..cb016f001e7a 100644
> --- a/include/linux/binfmts.h
> +++ b/include/linux/binfmts.h
> @@ -26,6 +26,8 @@ struct linux_binprm {
> unsigned long p; /* current top of mem */
> unsigned long argmin; /* rlimit marker for copy_strings() */
> unsigned int
> + /* Don't update the creds for an interpreter (see binfmt_misc)
> */
I'd like a much more verbose comment here. How about this:
/*
* Skip setting new privileges for an interpreter (see
* binfmt_misc) on the next call to prepare_binprm().
*/
> + preserve_creds:1,
Nit pick: we've seen there is a logical difference here between "creds"
(which mean "the creds struct itself") and "privileges" (which are
stored in the cred struct). I think we should reinforce this distinction
here and name this:
preserve_privileges:1,
> /*
>* True if most recent call to the commoncaps bprm_set_creds
>* hook (due to multiple prepare_binprm() calls from the
> --
> 2.25.0
>
Otherwise, yeah, this seems okay to me.
--
Kees Cook
linux-next: Signed-off-by missing for commit in the net-next tree
Hi all,
Commit
be904b855200 ("sfc: make capability checking a nic_type function")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgp4jUme3tRDf.pgp
Description: OpenPGP digital signature
[PATCH v3] KVM: nVMX: Tweak handling of failure code for nested VM-Enter failure
Use an enum for passing around the failure code for a failed VM-Enter
that results in VM-Exit to provide a level of indirection from the final
resting place of the failure code, vmcs.EXIT_QUALIFICATION. The exit
qualification field is an unsigned long, e.g. passing around
'u32 exit_qual' throws up red flags as it suggests KVM may be dropping
bits when reporting errors to L1. This is a red herring because the
only defined failure codes are 0, 2, 3, and 4, i.e. don't come remotely
close to overflowing a u32.
Setting vmcs.EXIT_QUALIFICATION on entry failure is further complicated
by the MSR load list, which returns the (1-based) entry that failed, and
the number of MSRs to load is a 32-bit VMCS field. At first blush, it
would appear that overflowing a u32 is possible, but the number of MSRs
that can be loaded is hardcapped at 4096 (limited by MSR_IA32_VMX_MISC).
In other words, there are two completely disparate types of data that
eventually get stuffed into vmcs.EXIT_QUALIFICATION, neither of which is
an 'unsigned long' in nature. This was presumably the reasoning for
switching to 'u32' when the related code was refactored in commit
ca0bde28f2ed6 ("kvm: nVMX: Split VMCS checks from nested_vmx_run()").
Using an enum for the failure code addresses the technically-possible-
but-will-never-happen scenario where Intel defines a failure code that
doesn't fit in a 32-bit integer. The enum variables and values will
either be automatically sized (gcc 5.4 behavior) or be subjected to some
combination of truncation. The former case will simply work, while the
latter will trigger a compile-time warning unless the compiler is being
particularly unhelpful.
Separating the failure code from the failed MSR entry allows for
disassociating both from vmcs.EXIT_QUALIFICATION, which avoids the
conundrum where KVM has to choose between 'u32 exit_qual' and tracking
values as 'unsigned long' that have no business being tracked as such.
To cement the split, set vmcs12->exit_qualification directly from the
entry error code or failed MSR index instead of bouncing through a local
variable.
Opportunistically rename the variables in load_vmcs12_host_state() and
vmx_set_nested_state() to call out that they're ignored, set exit_reason
on demand on nested VM-Enter failure, and add a comment in
nested_vmx_load_msr() to call out that returning 'i + 1' can't wrap.
No functional change intended.
Reported-by: Vitaly Kuznetsov
Cc: Jim Mattson
Signed-off-by: Sean Christopherson
---
v3:
- Set exit qual and reason in prepare_vmcs02() failure path. [kernel
test robot]
v2:
- Set vmcs12->exit_qualification directly to avoid writing the failed
MSR index (a u32) to the entry_failure_code enum. [Jim]
- Set exit_reason on demand since the "goto vm_exit" paths need to set
vmcs12->exit_qualification anyways, i.e. already have curly braces.
arch/x86/include/asm/vmx.h | 10
arch/x86/kvm/vmx/nested.c | 47 +++---
2 files changed, 34 insertions(+), 23 deletions(-)
diff --git a/arch/x86/include/asm/vmx.h b/arch/x86/include/asm/vmx.h
index 5e090d1f03f8d..cd7de4b401fee 100644
--- a/arch/x86/include/asm/vmx.h
+++ b/arch/x86/include/asm/vmx.h
@@ -527,10 +527,12 @@ struct vmx_msr_entry {
/*
* Exit Qualifications for entry failure during or after loading guest state
*/
-#define ENTRY_FAIL_DEFAULT 0
-#define ENTRY_FAIL_PDPTE 2
-#define ENTRY_FAIL_NMI 3
-#define ENTRY_FAIL_VMCS_LINK_PTR 4
+enum vm_entry_failure_code {
+ ENTRY_FAIL_DEFAULT = 0,
+ ENTRY_FAIL_PDPTE= 2,
+ ENTRY_FAIL_NMI = 3,
+ ENTRY_FAIL_VMCS_LINK_PTR= 4,
+};
/*
* Exit Qualifications for EPT Violations
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 2c36f3f531088..8f1b41599f58d 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -922,6 +922,7 @@ static u32 nested_vmx_load_msr(struct kvm_vcpu *vcpu, u64
gpa, u32 count)
}
return 0;
fail:
+ /* Note, max_msr_list_size is at most 4096, i.e. this can't wrap. */
return i + 1;
}
@@ -1117,7 +1118,7 @@ static bool nested_vmx_transition_mmu_sync(struct
kvm_vcpu *vcpu)
* @entry_failure_code.
*/
static int nested_vmx_load_cr3(struct kvm_vcpu *vcpu, unsigned long cr3, bool
nested_ept,
- u32 *entry_failure_code)
+ enum vm_entry_failure_code *entry_failure_code)
{
if (cr3 != kvm_read_cr3(vcpu) || (!nested_ept && pdptrs_changed(vcpu)))
{
if (CC(!nested_cr3_valid(vcpu, cr3))) {
@@ -2470,7 +2471,7 @@ static void prepare_vmcs02_rare(struct vcpu_vmx *vmx,
struct vmcs12 *vmcs12)
* is assigned to entry_failure_code on failure.
*/
static int prepare_vmcs02(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12,
- u32 *entry_failure_code)
+ enum
Re: [PATCH] mm: fix LRU balancing effect of new transparent huge pages
On Mon, May 11, 2020 at 2:58 PM Andrew Morton wrote:
>
> On Mon, 11 May 2020 14:38:23 -0700 Shakeel Butt wrote:
>
> > On Mon, May 11, 2020 at 2:11 PM Andrew Morton
> > wrote:
> > >
> > > On Sat, 9 May 2020 07:19:46 -0700 Shakeel Butt
> > > wrote:
> > >
> > > > Currently, THP are counted as single pages until they are split right
> > > > before being swapped out. However, at that point the VM is already in
> > > > the middle of reclaim, and adjusting the LRU balance then is useless.
> > > >
> > > > Always account THP by the number of basepages, and remove the fixup
> > > > from the splitting path.
> > >
> > > Confused. What kernel is this applicable to?
> >
> > It is still applicable to the latest Linux kernel.
>
> The patch has
>
> > @@ -288,7 +288,7 @@ static void __activate_page(struct page *page, struct
> > lruvec *lruvec,
> >
> > __count_vm_events(PGACTIVATE, nr_pages);
> > __count_memcg_events(lruvec_memcg(lruvec), PGACTIVATE,
> > nr_pages);
> > - update_page_reclaim_stat(lruvec, file, 1);
> > + update_page_reclaim_stat(lruvec, file, 1, nr_pages);
> > }
> > }
>
> but current mainline is quite different:
>
> static void __activate_page(struct page *page, struct lruvec *lruvec,
> void *arg)
> {
> if (PageLRU(page) && !PageActive(page) && !PageUnevictable(page)) {
> int file = page_is_file_lru(page);
> int lru = page_lru_base_type(page);
>
> del_page_from_lru_list(page, lruvec, lru);
> SetPageActive(page);
> lru += LRU_ACTIVE;
> add_page_to_lru_list(page, lruvec, lru);
> trace_mm_lru_activate(page);
>
> __count_vm_event(PGACTIVATE);
> update_page_reclaim_stat(lruvec, file, 1);
> }
> }
>
> q:/usr/src/linux-5.7-rc5> patch -p1 --dry-run < ~/x.txt
> checking file mm/swap.c
> Hunk #2 FAILED at 288.
> Hunk #3 FAILED at 546.
> Hunk #4 FAILED at 564.
> Hunk #5 FAILED at 590.
> Hunk #6 succeeded at 890 (offset -9 lines).
> Hunk #7 succeeded at 915 (offset -9 lines).
> Hunk #8 succeeded at 958 with fuzz 2 (offset -10 lines).
> 4 out of 8 hunks FAILED
>
Oh sorry my mistake. It is dependent on the first two patches at [1].
Basically I replaced the third patch of the series with this one. I
should have re-send them all together.
[1] http://lkml.kernel.org/r/20200508212215.181307-1-shake...@google.com
Re: [PATCH v7 1/9] firmware: arm_scmi: Add notification protocol-registration
Hi Dave
thanks for the review first of all.
On Wed, May 06, 2020 at 04:25:50PM +0100, Dave Martin wrote:
> On Mon, May 04, 2020 at 05:38:47PM +0100, Cristian Marussi wrote:
> > Add core SCMI Notifications protocol-registration support: allow protocols
> > to register their own set of supported events, during their initialization
> > phase. Notification core can track multiple platform instances by their
> > handles.
> >
> > Reviewed-by: Jonathan Cameron
> > Signed-off-by: Cristian Marussi
> > ---
> > V4 --> V5
> > - fixed kernel-doc
> > - added barriers for registered protocols and events
> > - using kfifo_alloc and devm_add_action_or_reset
> > V3 --> V4
> > - removed scratch ISR buffer, move scratch BH buffer into protocol
> > descriptor
> > - converted registered_protocols and registered_events from hashtables
> > into bare fixed-sized arrays
> > - removed unregister protocols' routines (never called really)
> > V2 --> V3
> > - added scmi_notify_instance to track target platform instance
> > V1 --> V2
> > - splitted out of V1 patch 04
> > - moved from IDR maps to real HashTables to store events
> > - scmi_notifications_initialized is now an atomic_t
> > - reviewed protocol registration/unregistration to use devres
> > - fixed:
> > drivers/firmware/arm_scmi/notify.c:483:18-23: ERROR:
> > reference preceded by free on line 482
> >
> > Reported-by: kbuild test robot
> > Reported-by: Julia Lawall
> > ---
> > drivers/firmware/arm_scmi/Makefile | 2 +-
> > drivers/firmware/arm_scmi/common.h | 4 +
> > drivers/firmware/arm_scmi/notify.c | 444 +
> > drivers/firmware/arm_scmi/notify.h | 56
> > include/linux/scmi_protocol.h | 3 +
> > 5 files changed, 508 insertions(+), 1 deletion(-)
> > create mode 100644 drivers/firmware/arm_scmi/notify.c
> > create mode 100644 drivers/firmware/arm_scmi/notify.h
>
> [...]
>
> > diff --git a/drivers/firmware/arm_scmi/notify.c
> > b/drivers/firmware/arm_scmi/notify.c
>
> [...]
>
> > +int scmi_register_protocol_events(const struct scmi_handle *handle,
> > + u8 proto_id, size_t queue_sz,
> > + const struct scmi_protocol_event_ops *ops,
> > + const struct scmi_event *evt, int num_events,
> > + int num_sources)
> > +{
> > + int i;
> > + size_t payld_sz = 0;
> > + struct scmi_registered_protocol_events_desc *pd;
> > + struct scmi_notify_instance *ni = handle->notify_priv;
> > +
> > + if (!ops || !evt || proto_id >= SCMI_MAX_PROTO)
> > + return -EINVAL;
> > +
> > + /* Ensure atomic value is updated */
> > + smp_mb__before_atomic();
> > + if (unlikely(!ni || !atomic_read(>initialized)))
> > + return -EAGAIN;
>
> The atomics/barriers don't look quite right to me here.
>
> I'd have expected:
>
> scmi_register_protocol_events()
> {
> if (atomic_read(>initialized))
> return -EAGAIN;
> smp_mb_after_atomic();
>
> /* ... */
> }
>
> to pair with:
>
> scmi_notification_init()
> {
> /* ... */
>
> smp_mb__before_atomic();
> atomic_set(>enabled, 1);
> }
>
>
> ...however, do we need to allow these two functions to race with each
> other at all? (I haven't tried to understand the wider context here,
> so if there really is no way to avoid initialisation racing with use I
> guess we may have to do something like this. We don't want callers
> to dumbly spin on this function though.)
>
>
> In other patches in the series, calls to scmi_register_protocol_events()
> seem to be assuming there is no race: the return value is not checked.
> Possibly a bug?
>
I think you are right in these regards, there's no need of an atomic here
for 'initialized' and using -EAGAIN on !initialized as error code in
scmi_register_protocol_events() is wrong too in this context.
The aim is to detect when general SCMI notification core initialization has
failed as a whole and in that case inhibit any further SCMI protocols events'
registration attempt during general protocol init (since init has failed and
no related data has been allocated and readied).
No attempt should be made to re-register on failure because the failure to
init the notif stuff is permanent when happens (not solvable with deferred
re-probing) and there's no race in checking this condition
(more on this down below)
So I think I'll just drop the 'initialized' field as a whole and simply use
the value of handle->notify_priv (ni) to detect if initialization was
successfull or not, like:
scmi_register_protocol_events()
{
...
if (unlikely(!ni)) // ni is NULL when init has failed
return -ENOMEM;
}
(..plus barriers where needed)
and could probably check the ret value too in the caller to printout some
debug info in case of other-than-ENOMEM errors. (due anyway to a broken
implementation not to runtime errors)
As said there's no race to
Re: [GIT PULL] RISC-V Fixes for 5.7-rc5
On Mon, 11 May 2020 12:04:09 PDT (-0700), Linus Torvalds wrote:
On Mon, May 11, 2020 at 1:13 AM Andreas Schwab wrote:
On Mai 09 2020, Linus Torvalds wrote:
> glibc depending on kernel version is WRONG. It's bogus. You can't do
> feature detection based on kernel version, it's fundamentally broken.
>
> So I really would prefer to see glibc fixed not to do that stupid
> thing, instead of adding pointless vdso notes to the kernel.
I'm not aware of any discussion or bug report on this issue. Any
pointer?
We've discussed it informally several times, but that really is just
"I remember mentioning this before" than anything else.
Basically, testing kernel versions is pretty much always a bug. You
_will_ get it wrong, sometimes spectacularly (we've had programs
literally break when the major number changed, because they only
checked the minor number).
Other times you'll get it wrong in subtler ways - testing for features
by version number is wrong, if that feature is then disabled by a
config option (a lot of new kernel features work that way).
Or, the already mentioned "distros often port back features to their
older kernels". The latest example of that is Wireguard being ported
back to Ubuntu 20.04 - using kernel version 5.4, even though WG was
actually upstreamed in 5.6.
So the whole "look at kernel version to determine if it does X" is
simply fundamentally wrong.
Why is glibc doing it in the first place? Is it some historical thing
that is simply irrelevant on RISC-V simply because RISC-V doesn't have
that kind of history, perhaps?
I don't know if Andreas had something else in mind, but there's actually a
RISC-V specific reason we _do_ need this: the 64-bit time_t conversion.
Essentially what happened is that I screwed up by merging the rv32 Linux port
before the rv32 glibc port. As part of the rv32 upstreaming process we
realized that it would be better in the long term to just drop the 32-bit
time_t support from the kernel, but at that point we already had the Linux UABI
defined.
We ended up changing the user ABI on 32-bit systems as of d4c08b9776b3 ("riscv:
Use latest system call ABI"). We didn't have any rv32 userspace at that time
(and we still don't have glibc or any Linux capable hardware), so we figured it
would be OK to break the rules and change the ABI. The obvious result is that
32-bit userspace won't work with old kernels, so I'd assumed this was being
used to quickly sanity check the kernel.
Andreas would know better than I do, though, as I don't really do much glibc
stuff any more.
Linus
[PATCH] kernel: sysctl: ignore invalid taint bits introduced via kernel.tainted and taint the kernel with TAINT_USER on writes
The sysctl knob allows any user with SYS_ADMIN capability to
taint the kernel with any arbitrary value, but this might
produce an invalid flags bitset being committed to tainted_mask.
This patch introduces a simple way for proc_taint() to ignore
any eventual invalid bit coming from the user input before
committing those bits to the kernel tainted_mask, as well as
it makes clear use of TAINT_USER flag to mark the kernel
tainted by user everytime a taint value is written
to the kernel.tainted sysctl.
Signed-off-by: Rafael Aquini
---
kernel/sysctl.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 8a176d8727a3..f0a4fb38ac62 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2623,17 +2623,32 @@ static int proc_taint(struct ctl_table *table, int
write,
return err;
if (write) {
+ int i;
+
+ /*
+* Ignore user input that would make us committing
+* arbitrary invalid TAINT flags in the loop below.
+*/
+ tmptaint &= (1UL << TAINT_FLAGS_COUNT) - 1;
+
/*
* Poor man's atomic or. Not worth adding a primitive
* to everyone's atomic.h for this
*/
- int i;
for (i = 0; i < BITS_PER_LONG && tmptaint >> i; i++) {
if ((tmptaint >> i) & 1)
add_taint(i, LOCKDEP_STILL_OK);
}
+
+ /*
+* Users with SYS_ADMIN capability can include any arbitrary
+* taint flag by writing to this interface. If that's the case,
+* we also need to mark the kernel "tainted by user".
+*/
+ add_taint(TAINT_USER, LOCKDEP_STILL_OK);
}
+
return err;
}
--
2.25.4
Re: [PATCH 13/17] staging: wfx: fix endianness of the field 'len'
Hi Jerome,
I love your patch! Perhaps something to improve:
[auto build test WARNING on staging/staging-testing]
[also build test WARNING on next-20200511]
[cannot apply to v5.7-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Jerome-Pouiller/staging-wfx-fix-support-for-big-endian-hosts/20200512-031750
base: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
ae73e7784871ebe2c43da619b4a1e2c9ff81508d
config: m68k-allmodconfig (attached as .config)
compiler: m68k-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross ARCH=m68k
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
In file included from include/linux/byteorder/big_endian.h:5,
from arch/m68k/include/uapi/asm/byteorder.h:5,
from include/asm-generic/bitops/le.h:6,
from arch/m68k/include/asm/bitops.h:528,
from include/linux/bitops.h:29,
from include/linux/kernel.h:12,
from include/asm-generic/bug.h:19,
from arch/m68k/include/asm/bug.h:32,
from include/linux/bug.h:5,
from include/linux/gpio/consumer.h:6,
from drivers/staging/wfx/bh.c:8:
drivers/staging/wfx/bh.c: In function 'tx_helper':
>> drivers/staging/wfx/bh.c:202:39: warning: passing argument 1 of '__swab16s'
>> makes pointer from integer without a cast [-Wint-conversion]
202 | cpu_to_le16s(((struct hif_msg *)data)->len);
include/uapi/linux/byteorder/big_endian.h:96:38: note: in definition of
macro '__cpu_to_le16s'
96 | #define __cpu_to_le16s(x) __swab16s((x))
| ^
>> drivers/staging/wfx/bh.c:202:2: note: in expansion of macro 'cpu_to_le16s'
202 | cpu_to_le16s(((struct hif_msg *)data)->len);
| ^~~~
In file included from include/linux/swab.h:5,
from include/uapi/linux/byteorder/big_endian.h:13,
from include/linux/byteorder/big_endian.h:5,
from arch/m68k/include/uapi/asm/byteorder.h:5,
from include/asm-generic/bitops/le.h:6,
from arch/m68k/include/asm/bitops.h:528,
from include/linux/bitops.h:29,
from include/linux/kernel.h:12,
from include/asm-generic/bug.h:19,
from arch/m68k/include/asm/bug.h:32,
from include/linux/bug.h:5,
from include/linux/gpio/consumer.h:6,
from drivers/staging/wfx/bh.c:8:
include/uapi/linux/swab.h:240:37: note: expected '__u16 *' {aka 'short
unsigned int *'} but argument is of type 'u16' {aka 'short unsigned int'}
240 | static inline void __swab16s(__u16 *p)
| ~~~^
vim +/__swab16s +202 drivers/staging/wfx/bh.c
169
170 static void tx_helper(struct wfx_dev *wdev, struct hif_msg *hif)
171 {
172 int ret;
173 void *data;
174 bool is_encrypted = false;
175 size_t len = hif->len;
176
177 WARN(len < sizeof(*hif), "try to send corrupted data");
178
179 hif->seqnum = wdev->hif.tx_seqnum;
180 wdev->hif.tx_seqnum = (wdev->hif.tx_seqnum + 1) %
(HIF_COUNTER_MAX + 1);
181
182 if (wfx_is_secure_command(wdev, hif->id)) {
183 len = round_up(len - sizeof(hif->len), 16) +
sizeof(hif->len) +
184 sizeof(struct hif_sl_msg_hdr) +
185 sizeof(struct hif_sl_tag);
186 // AES support encryption in-place. However, mac80211
access to
187 // 802.11 header after frame was sent (to get MAC
addresses).
188 // So, keep origin buffer clear.
189 data = kmalloc(len, GFP_KERNEL);
190 if (!data)
191 goto end;
192 is_encrypted = true;
193 ret = wfx_sl_encode(wdev, hif, data);
194 if (ret)
195 goto end;
196 } else {
197 data = hif;
198 }
199 WARN(len > wdev->hw_caps.size_inp_ch_buf,
200 "%s:
Re: [PATCH 1/2] mfd: mfd-core: Add mechanism for removal of a subset of children
Hi Charles,
I love your patch! Perhaps something to improve:
[auto build test WARNING on ljones-mfd/for-mfd-next]
[also build test WARNING on v5.7-rc5 next-20200511]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Charles-Keepax/mfd-mfd-core-Add-mechanism-for-removal-of-a-subset-of-children/20200512-032030
base: https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git for-mfd-next
config: s390-randconfig-r034-20200511 (attached as .config)
compiler: s390-linux-gcc (GCC) 9.3.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day GCC_VERSION=9.3.0 make.cross ARCH=s390
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All warnings (new ones prefixed by >>):
drivers/mfd/mfd-core.c: In function 'mfd_remove_devices_fn':
>> drivers/mfd/mfd-core.c:290:12: warning: cast from pointer to integer of
>> different size [-Wpointer-to-int-cast]
290 | int tag = (int)data;
|^
drivers/mfd/mfd-core.c: In function 'mfd_remove_devices_by_tag':
>> drivers/mfd/mfd-core.c:310:40: warning: cast to pointer from integer of
>> different size [-Wint-to-pointer-cast]
310 | device_for_each_child_reverse(parent, (void *)tag,
|^
vim +290 drivers/mfd/mfd-core.c
285
286 static int mfd_remove_devices_fn(struct device *dev, void *data)
287 {
288 struct platform_device *pdev;
289 const struct mfd_cell *cell;
> 290 int tag = (int)data;
291
292 if (dev->type != _dev_type)
293 return 0;
294
295 pdev = to_platform_device(dev);
296 cell = mfd_get_cell(pdev);
297
298 if (tag && cell->tag != tag)
299 return 0;
300
301 regulator_bulk_unregister_supply_alias(dev,
cell->parent_supplies,
302
cell->num_parent_supplies);
303
304 platform_device_unregister(pdev);
305 return 0;
306 }
307
308 void mfd_remove_devices_by_tag(struct device *parent, int tag)
309 {
> 310 device_for_each_child_reverse(parent, (void *)tag,
311mfd_remove_devices_fn);
312 }
313 EXPORT_SYMBOL(mfd_remove_devices_by_tag);
314
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
Re: [PATCH] mm: fix LRU balancing effect of new transparent huge pages
On Mon, 11 May 2020 14:38:23 -0700 Shakeel Butt wrote:
> On Mon, May 11, 2020 at 2:11 PM Andrew Morton
> wrote:
> >
> > On Sat, 9 May 2020 07:19:46 -0700 Shakeel Butt wrote:
> >
> > > Currently, THP are counted as single pages until they are split right
> > > before being swapped out. However, at that point the VM is already in
> > > the middle of reclaim, and adjusting the LRU balance then is useless.
> > >
> > > Always account THP by the number of basepages, and remove the fixup
> > > from the splitting path.
> >
> > Confused. What kernel is this applicable to?
>
> It is still applicable to the latest Linux kernel.
The patch has
> @@ -288,7 +288,7 @@ static void __activate_page(struct page *page, struct
> lruvec *lruvec,
>
> __count_vm_events(PGACTIVATE, nr_pages);
> __count_memcg_events(lruvec_memcg(lruvec), PGACTIVATE,
> nr_pages);
> - update_page_reclaim_stat(lruvec, file, 1);
> + update_page_reclaim_stat(lruvec, file, 1, nr_pages);
> }
> }
but current mainline is quite different:
static void __activate_page(struct page *page, struct lruvec *lruvec,
void *arg)
{
if (PageLRU(page) && !PageActive(page) && !PageUnevictable(page)) {
int file = page_is_file_lru(page);
int lru = page_lru_base_type(page);
del_page_from_lru_list(page, lruvec, lru);
SetPageActive(page);
lru += LRU_ACTIVE;
add_page_to_lru_list(page, lruvec, lru);
trace_mm_lru_activate(page);
__count_vm_event(PGACTIVATE);
update_page_reclaim_stat(lruvec, file, 1);
}
}
q:/usr/src/linux-5.7-rc5> patch -p1 --dry-run < ~/x.txt
checking file mm/swap.c
Hunk #2 FAILED at 288.
Hunk #3 FAILED at 546.
Hunk #4 FAILED at 564.
Hunk #5 FAILED at 590.
Hunk #6 succeeded at 890 (offset -9 lines).
Hunk #7 succeeded at 915 (offset -9 lines).
Hunk #8 succeeded at 958 with fuzz 2 (offset -10 lines).
4 out of 8 hunks FAILED
[PATCH v2] Kconfig: default to CC_OPTIMIZE_FOR_PERFORMANCE_O3 for gcc >= 10
GCC 10 appears to have changed -O2 in order to make compilation time faster when using -flto, seemingly at the expense of performance, in particular with regards to how the inliner works. Since -O3 these days shouldn't have the same set of bugs as 10 years ago, this commit defaults new kernel compiles to -O3 when using gcc >= 10. Cc: linux-kbu...@vger.kernel.org Cc: x...@kernel.org Cc: sta...@vger.kernel.org Cc: hjl.to...@gmail.com Cc: Peter Zijlstra Cc: Jakub Jelinek Cc: Oleksandr Natalenko Cc: Arnd Bergmann Cc: Andrew Morton Cc: David Laight Cc: Linus Torvalds Cc: Masahiro Yamada Signed-off-by: Jason A. Donenfeld --- Changes v1->v2: - [Oleksandr] Remove O3 dependency on ARC. init/Kconfig | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/init/Kconfig b/init/Kconfig index 9e22ee8fbd75..f76ec3ccc883 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -1245,7 +1245,8 @@ config BOOT_CONFIG choice prompt "Compiler optimization level" - default CC_OPTIMIZE_FOR_PERFORMANCE + default CC_OPTIMIZE_FOR_PERFORMANCE_O3 if GCC_VERSION >= 10 + default CC_OPTIMIZE_FOR_PERFORMANCE if (GCC_VERSION < 10 || CC_IS_CLANG) config CC_OPTIMIZE_FOR_PERFORMANCE bool "Optimize for performance (-O2)" @@ -1256,7 +1257,6 @@ config CC_OPTIMIZE_FOR_PERFORMANCE config CC_OPTIMIZE_FOR_PERFORMANCE_O3 bool "Optimize more for performance (-O3)" - depends on ARC imply CC_DISABLE_WARN_MAYBE_UNINITIALIZED # avoid false positives help Choosing this option will pass "-O3" to your compiler to optimize -- 2.26.2
Re: [PATCH 3/5] exec: Remove recursion from search_binary_handler
On Mon, May 11, 2020 at 09:33:21AM -0500, Eric W. Biederman wrote: > Linus Torvalds writes: > > > On Sat, May 9, 2020 at 9:30 PM Tetsuo Handa > > wrote: > >> > >> Wouldn't this change cause > >> > >> if (fd_binary > 0) > >> ksys_close(fd_binary); > >> bprm->interp_flags = 0; > >> bprm->interp_data = 0; > >> > >> not to be called when "Search for the interpreter" failed? > > > > Good catch. We seem to have some subtle magic wrt the fd_binary file > > descriptor, which depends on the recursive behavior. > > Yes. I Tetsuo I really appreciate you noticing this. This is exactly > the kind of behavior I am trying to flush out and keep from being > hidden. > > > I'm not seeing how to fix it cleanly with the "turn it into a loop". > > Basically, that binfmt_misc use-case isn't really a tail-call. > > I have reservations about installing a new file descriptor before > we process the close on exec logic and the related security modules > closing file descriptors that your new credentials no longer give > you access to logic. Hm, this does feel odd. In looking at this, it seems like this file never gets close-on-exec set, and doesn't have its flags changed from its original open: .open_flag = O_LARGEFILE | O_RDONLY | __FMODE_EXEC, only the UMH path through exec doesn't explicitly open a file by name from what I can see, so we'll only have these flags. > I haven't yet figured out how opening a file descriptor during exec > should fit into all of that. > > What I do see is that interp_data is just a parameter that is smuggled > into the call of search binary handler. And the next binary handler > needs to be binfmt_elf for it to make much sense, as only binfmt_elf > (and binfmt_elf_fdpic) deals with BINPRM_FLAGS_EXECFD. > > So I think what needs to happen is to rename bprm->interp_data to > bprm->execfd, remove BINPRM_FLAGS_EXECFD and make closing that file > descriptor free_bprm's responsiblity. Yeah, I would agree. As far as the close handling, I don't think there is a difference here: it interp_data was closed on the binfmt_misc.c error path, and in the new world it would be the exec error path -- both would be under the original credentials. > I hope such a change will make it easier to see all of the pieces that > are intereacting during exec. Right -- I'm not sure which piece should "consume" bprm->execfd though, which I think is what you're asking next... > I am still asking: is the installation of that file descriptor useful if > it is not exported passed to userspace as an AT_EXECFD note? > > I will dig in and see what I can come up with. Should binfmt_misc do the install, or can the consuming binfmt do it? i.e. when binfmt_elf sees bprm->execfd, does it perform the install instead? -- Kees Cook
Re: [PATCH v17 00/10] Landlock LSM
On 11/05/2020 21:21, Mickaël Salaün wrote: > Hi, > > This new patch series brings some improvements and add new tests: > > Use smaller userspace structures (attributes) to save space, and check > at built time that every attribute don't contain hole and are 8-bits > aligned. 8-bytes aligned, of course.
Re: [PATCH 1/1] dt-bindings: input: touchscreen: elants_i2c: convert to YAML
On Mon, May 11, 2020 at 03:37:09PM -0500, Rob Herring wrote: > On Thu, 23 Apr 2020 19:32:53 +0200, David Heidelberg wrote: > > Convert elants_i2c.txt DT binding to YAML and put into correct directory. > > > > Reviewed-by: Dmitry Osipenko > > Signed-off-by: David Heidelberg > > --- > > .../devicetree/bindings/input/elants_i2c.txt | 34 - > > .../input/touchscreen/elan,elants_i2c.yaml| 69 +++ > > 2 files changed, 69 insertions(+), 34 deletions(-) > > delete mode 100644 Documentation/devicetree/bindings/input/elants_i2c.txt > > create mode 100644 > > Documentation/devicetree/bindings/input/touchscreen/elan,elants_i2c.yaml > > > > Reviewed-by: Rob Herring Applied, thank you. -- Dmitry
[PATCH v3] security/keys: rewrite big_key crypto to use library interface
A while back, I noticed that the crypto and crypto API usage in big_keys
were entirely broken in multiple ways, so I rewrote it. Now, I'm
rewriting it again, but this time using the simpler ChaCha20Poly1305
library function. This makes the file considerably more simple; the
diffstat alone should justify this commit. It also should be faster,
since it no longer requires a mutex around the "aead api object" (nor
allocations), allowing us to encrypt multiple items in parallel. We also
benefit from being able to pass any type of pointer, so we can get rid
of the ridiculously complex custom page allocator that big_key really
doesn't need.
Cc: David Howells
Cc: Andy Lutomirski
Cc: Greg KH
Cc: Linus Torvalds
Cc: kernel-harden...@lists.openwall.com
Reviewed-by: Eric Biggers
Signed-off-by: Jason A. Donenfeld
---
Changes v2->v3:
- [Eric] Unify kernel_read/write handling in big_key_preparse and
big_key_read.
- [Eric] Update commit message.
Changes v1->v2:
- [Eric] Return -EBADMSG instead of -EINVAL if the authtag fails.
- [Eric] Select CONFIG_CRYPTO, since it's required by the LIB selection.
- [Eric] Zero out buffers that formerly contained either plaintext or
ciphertext keys.
- [Jason] If kernel_read() fails, return that error value, instead of
relying on the subsequent decryption to fail.
Note v1:
I finally got around to updating this patch from the mailing list posts
back in 2017-2018, using the library interface that we eventually
merged in 2019. I haven't retested this for functionality, but nothing
much has changed, so I suspect things should still be good to go.
security/keys/Kconfig | 3 +-
security/keys/big_key.c | 240 ++--
2 files changed, 35 insertions(+), 208 deletions(-)
diff --git a/security/keys/Kconfig b/security/keys/Kconfig
index 47c041563d41..7da6c1b496f9 100644
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -61,8 +61,7 @@ config BIG_KEYS
depends on KEYS
depends on TMPFS
select CRYPTO
- select CRYPTO_AES
- select CRYPTO_GCM
+ select CRYPTO_LIB_CHACHA20POLY1305
help
This option provides support for holding large keys within the kernel
(for example Kerberos ticket caches). The data may be stored out to
diff --git a/security/keys/big_key.c b/security/keys/big_key.c
index 82008f900930..d43f3daab2b8 100644
--- a/security/keys/big_key.c
+++ b/security/keys/big_key.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-or-later
/* Large capacity key type
*
- * Copyright (C) 2017 Jason A. Donenfeld . All Rights
Reserved.
+ * Copyright (C) 2017-2020 Jason A. Donenfeld . All Rights
Reserved.
* Copyright (C) 2013 Red Hat, Inc. All Rights Reserved.
* Written by David Howells (dhowe...@redhat.com)
*/
@@ -12,20 +12,10 @@
#include
#include
#include
-#include
#include
-#include
#include
#include
-#include
-#include
-
-struct big_key_buf {
- unsigned intnr_pages;
- void*virt;
- struct scatterlist *sg;
- struct page *pages[];
-};
+#include
/*
* Layout of key payload words.
@@ -37,14 +27,6 @@ enum {
big_key_len,
};
-/*
- * Crypto operation with big_key data
- */
-enum big_key_op {
- BIG_KEY_ENC,
- BIG_KEY_DEC,
-};
-
/*
* If the data is under this limit, there's no point creating a shm file to
* hold it as the permanently resident metadata for the shmem fs will be at
@@ -52,16 +34,6 @@ enum big_key_op {
*/
#define BIG_KEY_FILE_THRESHOLD (sizeof(struct inode) + sizeof(struct dentry))
-/*
- * Key size for big_key data encryption
- */
-#define ENC_KEY_SIZE 32
-
-/*
- * Authentication tag length
- */
-#define ENC_AUTHTAG_SIZE 16
-
/*
* big_key defined keys take an arbitrary string as the description and an
* arbitrary blob of data as the payload
@@ -75,136 +47,20 @@ struct key_type key_type_big_key = {
.destroy= big_key_destroy,
.describe = big_key_describe,
.read = big_key_read,
- /* no ->update(); don't add it without changing big_key_crypt() nonce */
+ /* no ->update(); don't add it without changing chacha20poly1305's
nonce */
};
-/*
- * Crypto names for big_key data authenticated encryption
- */
-static const char big_key_alg_name[] = "gcm(aes)";
-#define BIG_KEY_IV_SIZEGCM_AES_IV_SIZE
-
-/*
- * Crypto algorithms for big_key data authenticated encryption
- */
-static struct crypto_aead *big_key_aead;
-
-/*
- * Since changing the key affects the entire object, we need a mutex.
- */
-static DEFINE_MUTEX(big_key_aead_lock);
-
-/*
- * Encrypt/decrypt big_key data
- */
-static int big_key_crypt(enum big_key_op op, struct big_key_buf *buf, size_t
datalen, u8 *key)
-{
- int ret;
- struct aead_request *aead_req;
- /* We always use a zero nonce. The reason we can get away with this is
-* because we're
