Re: [PATCH 1/2] PCI/switechtec: Add missing __iomem and __user tags to fix sparse warnings

[Bjorn Helgaas]

On Tue, Jul 28, 2020 at 01:24:33PM -0600, Logan Gunthorpe wrote:
> Fix a number of missing __iomem and __user tags in the ioctl functions of
> the switchtec driver. This fixes a number of sparse warnings of the form:
> 
>   sparse: sparse: incorrect type in ... (different address spaces)
> 
> Fixes: 52eabba5bcdb ("switchtec: Add IOCTLs to the Switchtec driver")
> Signed-off-by: Logan Gunthorpe 

Applied to pci/switchtec for v5.9, thanks!

> ---
> 
> Here are a couple quick patches to fix some sparse warnings I was
> notified about a couple weeks ago.
> 
> I've split them into two patches based on Fixes tag, but they could be
> squashed depending on the preference.
> 
> Thanks!
> 
> drivers/pci/switch/switchtec.c | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/pci/switch/switchtec.c b/drivers/pci/switch/switchtec.c
> index 850cfeb74608..3d5da7f44378 100644
> --- a/drivers/pci/switch/switchtec.c
> +++ b/drivers/pci/switch/switchtec.c
> @@ -940,7 +940,7 @@ static u32 __iomem *event_hdr_addr(struct switchtec_dev 
> *stdev,
>   size_t off;
> 
>   if (event_id < 0 || event_id >= SWITCHTEC_IOCTL_MAX_EVENTS)
> - return ERR_PTR(-EINVAL);
> + return (u32 __iomem *)ERR_PTR(-EINVAL);
> 
>   off = event_regs[event_id].offset;
> 
> @@ -948,10 +948,10 @@ static u32 __iomem *event_hdr_addr(struct switchtec_dev 
> *stdev,
>   if (index == SWITCHTEC_IOCTL_EVENT_LOCAL_PART_IDX)
>   index = stdev->partition;
>   else if (index < 0 || index >= stdev->partition_count)
> - return ERR_PTR(-EINVAL);
> + return (u32 __iomem *)ERR_PTR(-EINVAL);
>   } else if (event_regs[event_id].map_reg == pff_ev_reg) {
>   if (index < 0 || index >= stdev->pff_csr_count)
> - return ERR_PTR(-EINVAL);
> + return (u32 __iomem *)ERR_PTR(-EINVAL);
>   }
> 
>   return event_regs[event_id].map_reg(stdev, off, index);
> @@ -1057,11 +1057,11 @@ static int ioctl_event_ctl(struct switchtec_dev 
> *stdev,
>  }
> 
>  static int ioctl_pff_to_port(struct switchtec_dev *stdev,
> -  struct switchtec_ioctl_pff_port *up)
> +  struct switchtec_ioctl_pff_port __user *up)
>  {
>   int i, part;
>   u32 reg;
> - struct part_cfg_regs *pcfg;
> + struct part_cfg_regs __iomem *pcfg;
>   struct switchtec_ioctl_pff_port p;
> 
>   if (copy_from_user(, up, sizeof(p)))
> @@ -1104,10 +1104,10 @@ static int ioctl_pff_to_port(struct switchtec_dev 
> *stdev,
>  }
> 
>  static int ioctl_port_to_pff(struct switchtec_dev *stdev,
> -  struct switchtec_ioctl_pff_port *up)
> +  struct switchtec_ioctl_pff_port __user *up)
>  {
>   struct switchtec_ioctl_pff_port p;
> - struct part_cfg_regs *pcfg;
> + struct part_cfg_regs __iomem *pcfg;
> 
>   if (copy_from_user(, up, sizeof(p)))
>   return -EFAULT;
> 
> base-commit: 92ed301919932f13b9172e525674157e983d
> --
> 2.20.1

Re: [PATCH v5 2/5] media: venus: core: Fix error handling in probe

[Bjorn Andersson]

On Wed 29 Jul 00:16 PDT 2020, Rajendra Nayak wrote:

> Post a successful pm_ops->core_get, an error in probe
> should exit by doing a pm_ops->core_put which seems
> to be missing. So fix it.
> 
> Signed-off-by: Rajendra Nayak 
> Acked-by: Stanimir Varbanov 

Reviewed-by: Bjorn Andersson 

> ---
>  drivers/media/platform/qcom/venus/core.c | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/platform/qcom/venus/core.c 
> b/drivers/media/platform/qcom/venus/core.c
> index 203c653..bfcaba3 100644
> --- a/drivers/media/platform/qcom/venus/core.c
> +++ b/drivers/media/platform/qcom/venus/core.c
> @@ -224,13 +224,15 @@ static int venus_probe(struct platform_device *pdev)
>  
>   ret = dma_set_mask_and_coherent(dev, core->res->dma_mask);
>   if (ret)
> - return ret;
> + goto err_core_put;
>  
>   if (!dev->dma_parms) {
>   dev->dma_parms = devm_kzalloc(dev, sizeof(*dev->dma_parms),
> GFP_KERNEL);
> - if (!dev->dma_parms)
> - return -ENOMEM;
> + if (!dev->dma_parms) {
> + ret = -ENOMEM;
> + goto err_core_put;
> + }
>   }
>   dma_set_max_seg_size(dev, DMA_BIT_MASK(32));
>  
> @@ -242,11 +244,11 @@ static int venus_probe(struct platform_device *pdev)
>   IRQF_TRIGGER_HIGH | IRQF_ONESHOT,
>   "venus", core);
>   if (ret)
> - return ret;
> + goto err_core_put;
>  
>   ret = hfi_create(core, _core_ops);
>   if (ret)
> - return ret;
> + goto err_core_put;
>  
>   pm_runtime_enable(dev);
>  
> @@ -302,6 +304,9 @@ static int venus_probe(struct platform_device *pdev)
>   pm_runtime_set_suspended(dev);
>   pm_runtime_disable(dev);
>   hfi_destroy(core);
> +err_core_put:
> + if (core->pm_ops->core_put)
> + core->pm_ops->core_put(dev);
>   return ret;
>  }
>  
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
> 

Re: [PATCH v5 1/5] dt-bindings: media: venus: Add an optional power domain for perf voting

[Bjorn Andersson]

On Wed 29 Jul 00:16 PDT 2020, Rajendra Nayak wrote:

> Venus needs to vote for the performance state of a power domain (cx)
> to be able to support DVFS. This 'cx' power domain is controlled by
> rpmh and is a common power domain (scalable) not specific to
> venus alone. This is optional in the sense that, leaving this power
> domain out does not really impact the functionality but just makes
> the platform a little less power efficient.
> 
> Signed-off-by: Rajendra Nayak 
> Reviewed-by: Rob Herring 

Reviewed-by: Bjorn Andersson 

> ---
>  Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml| 6 +-
>  Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml | 6 +-
>  2 files changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml 
> b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> index 55f2d67..04e303b 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml
> @@ -25,12 +25,16 @@ properties:
>  maxItems: 1
>  
>power-domains:
> -maxItems: 2
> +minItems: 2
> +maxItems: 3
>  
>power-domain-names:
> +minItems: 2
> +maxItems: 3
>  items:
>- const: venus
>- const: vcodec0
> +  - const: cx
>  
>clocks:
>  maxItems: 5
> diff --git 
> a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml 
> b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
> index 157dff8..90013d4 100644
> --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
> +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml
> @@ -25,13 +25,17 @@ properties:
>  maxItems: 1
>  
>power-domains:
> -maxItems: 3
> +minItems: 3
> +maxItems: 4
>  
>power-domain-names:
> +minItems: 3
> +maxItems: 4
>  items:
>- const: venus
>- const: vcodec0
>- const: vcodec1
> +  - const: cx
>  
>clocks:
>  maxItems: 7
> -- 
> QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
> of Code Aurora Forum, hosted by The Linux Foundation
> 

Re: [RFC][PATCH] locking/refcount: Provide __refcount API to obtain the old value

[Kees Cook]

On Wed, Jul 29, 2020 at 01:11:20PM +0200, pet...@infradead.org wrote:
> Subject: locking/refcount: Provide __refcount API to obtain the old value
> From: Peter Zijlstra 
> Date: Wed Jul 29 13:00:57 CEST 2020
> 
> David requested means to obtain the old/previous value from the
> refcount API for tracing purposes.
> 
> Duplicate (most of) the API as __refcount*() with an additional
> 'int *' argument into which, if !NULL, the old value will be stored.
> 
> Requested-by: David Howells 
> Signed-off-by: Peter Zijlstra (Intel) 

This looks good to me. Thanks for poking at it!

Reviewed-by: Kees Cook 

-- 
Kees Cook

Re: [PATCH v4 5/5] irqchip/irq-pruss-intc: Add support for ICSSG INTC on K3 SoCs

[David Lechner]

On 7/28/20 4:18 AM, Grzegorz Jaszczyk wrote:

From: Suman Anna 

The K3 AM65x and J721E SoCs have the next generation of the PRU-ICSS IP,
commonly called ICSSG. The PRUSS INTC present within the ICSSG supports
more System Events (160 vs 64), more Interrupt Channels and Host Interrupts
(20 vs 10) compared to the previous generation PRUSS INTC instances. The
first 2 and the last 10 of these host interrupt lines are used by the
PRU and other auxiliary cores and sub-modules within the ICSSG, with 8
host interrupts connected to MPU. The host interrupts 5, 6, 7 are also
connected to the other ICSSG instances within the SoC and can be
partitioned as per system integration through the board dts files.

Enhance the PRUSS INTC driver to add support for this ICSSG INTC
instance.

Signed-off-by: Suman Anna 
Signed-off-by: Grzegorz Jaszczyk 
---


There is not much left in this patch. Might as well squash this into
"irqchip/irq-pruss-intc: Add a PRUSS irqchip driver for PRUSS interrupts".

Re: [RFC][PATCH] locking/refcount: Provide __refcount API to obtain the old value

[Kees Cook]

On Wed, Jul 29, 2020 at 01:37:31PM +0200, pet...@infradead.org wrote:
> On Wed, Jul 29, 2020 at 01:11:20PM +0200, pet...@infradead.org wrote:
> 
> > Subject: locking/refcount: Provide __refcount API to obtain the old value
> > From: Peter Zijlstra 
> > Date: Wed Jul 29 13:00:57 CEST 2020
> > 
> > David requested means to obtain the old/previous value from the
> > refcount API for tracing purposes.
> > 
> > Duplicate (most of) the API as __refcount*() with an additional
> > 'int *' argument into which, if !NULL, the old value will be stored.
> > 
> > Requested-by: David Howells 
> > Signed-off-by: Peter Zijlstra (Intel) 
> > ---
> >  include/linux/refcount.h |   65 
> > +--
> >  1 file changed, 57 insertions(+), 8 deletions(-)
> > 
> > --- a/include/linux/refcount.h
> > +++ b/include/linux/refcount.h
> > @@ -165,7 +165,7 @@ static inline unsigned int refcount_read
> >   *
> >   * Return: false if the passed refcount is 0, true otherwise
> >   */
> > -static inline __must_check bool refcount_add_not_zero(int i, refcount_t *r)
> > +static inline __must_check bool __refcount_add_not_zero(int i, refcount_t 
> > *r, int *oldp)
> >  {
> > int old = refcount_read(r);
> >  
> > @@ -174,12 +174,20 @@ static inline __must_check bool refcount
> > break;
> > } while (!atomic_try_cmpxchg_relaxed(>refs, , old + i));
> >  
> > +   if (oldp)
> > +   *oldp = old;
> > +
> > if (unlikely(old < 0 || old + i < 0))
> > refcount_warn_saturate(r, REFCOUNT_ADD_NOT_ZERO_OVF);
> >  
> > return old;
> >  }
> >  
> > +static inline __must_check bool refcount_add_not_zero(int i, refcount_t *r)
> > +{
> > +   return __refcount_add_not_zero(i, r, NULL);
> > +}
> 
> so, I could also emulate C++'s
> 
> bool refcount_add_not_zero(int i, refcount_t *r, int *oldp = NULL)
> 
> style by going to town on this with a bunch of CPP magic, but I don't
> think that'll actually make things clearer.

Erg. No, I like the __-version better -- it looks more like other kernel
APIs.

-- 
Kees Cook

Re: [PATCH v2] PCI: Fix kerneldoc of pci_vc_do_save_buffer()

[Krzysztof Kozlowski]

On Wed, Jul 29, 2020 at 02:24:16PM -0500, Bjorn Helgaas wrote:
> On Wed, Jul 29, 2020 at 08:26:20AM +0200, Krzysztof Kozlowski wrote:
> > Fix W=1 compile warnings (invalid kerneldoc):
> > 
> > drivers/pci/vc.c:188: warning: Excess function parameter 'name' 
> > description in 'pci_vc_do_save_buffer'
> > 
> > Signed-off-by: Krzysztof Kozlowski 
> 
> This looks great, but would you mind doing all the ones in drivers/pci
> at the same time?  When I tested this, I also found the following, and
> I don't think it's worth doing them one at a time:
> 
>   $ make W=1 drivers/pci/
>   drivers/pci/hotplug/acpi_pcihp.c:69: warning: Function parameter or member 
> 'pdev' not described in 'acpi_get_hp_hw_control_from_firmware'
>   drivers/pci/hotplug/acpi_pcihp.c:69: warning: Excess function parameter 
> 'dev' description in 'acpi_get_hp_hw_control_from_firmware'
>   drivers/pci/hotplug/acpi_pcihp.c:199: warning: Function parameter or member 
> 'handle' not described in 'acpi_pci_detect_ejectable'
>   drivers/pci/endpoint/functions/pci-epf-test.c:189: warning: Function 
> parameter or member 'epf_test' not described in 'pci_epf_test_clean_dma_chan'
>   drivers/pci/endpoint/functions/pci-epf-test.c:189: warning: Excess function 
> parameter 'epf' description in 'pci_epf_test_clean_dma_chan'
>   drivers/pci/endpoint/pci-ep-cfs.c:17: warning: Function parameter or member 
> 'functions_idr' not described in 'DEFINE_IDR'
>   drivers/pci/endpoint/pci-epc-core.c:18: warning: cannot understand function 
> prototype: 'struct class *pci_epc_class; '
>   drivers/pci/endpoint/pci-epf-core.c:18: warning: Function parameter or 
> member 'pci_epf_mutex' not described in 'DEFINE_MUTEX'
>   drivers/pci/endpoint/pci-epf-core.c:80: warning: Function parameter or 
> member 'epf' not described in 'pci_epf_free_space'
>   drivers/pci/endpoint/pci-epf-core.c:107: warning: Function parameter or 
> member 'epf' not described in 'pci_epf_alloc_space'
>   drivers/pci/endpoint/pci-epc-mem.c:16: warning: Incorrect use of kernel-doc 
> format:  * pci_epc_mem_get_order() - determine the allocation order of a 
> memory size
>   drivers/pci/endpoint/pci-epc-mem.c:24: warning: Function parameter or 
> member 'mem' not described in 'pci_epc_mem_get_order'
>   drivers/pci/endpoint/pci-epc-mem.c:24: warning: Function parameter or 
> member 'size' not described in 'pci_epc_mem_get_order'
>   drivers/pci/setup-bus.c:62: warning: Function parameter or member 
> 'min_align' not described in 'add_to_list'
>   drivers/pci/vc.c:188: warning: Excess function parameter 'name' description 
> in 'pci_vc_do_save_buffer'
>   drivers/pci/of.c:262: warning: Function parameter or member 'ib_resources' 
> not described in 'devm_of_pci_get_host_bridge_resources'
>   drivers/pci/ats.c:196: warning: Function parameter or member 'pdev' not 
> described in 'pci_enable_pri'
>   drivers/pci/ats.c:196: warning: Function parameter or member 'reqs' not 
> described in 'pci_enable_pri'
>   drivers/pci/pci-pf-stub.c:20: warning: cannot understand function 
> prototype: 'const struct pci_device_id pci_pf_stub_whitelist[] = '

Sure, I can work on more of them. Somehow this one got enabled on my
build (usually it does not contain PCI) and I decided to fix it.

It's a compiler warning so still even one-at-a-time brings us closer to
clean builds.

Best regards,
Krzysztof

Re: [PATCH 6/7] ARM: s3c64xx: Switch to generic watchdog driver reset

[Krzysztof Kozlowski]

On Wed, Jul 29, 2020 at 09:15:44PM +0200, Krzysztof Kozlowski wrote:
> On Wed, Jul 29, 2020 at 07:33:33PM +0200, Tomasz Figa wrote:
> > Hi Krzysztof,
> > 
> > 2020年7月29日(水) 18:11 Krzysztof Kozlowski :
> > >
> > > Similarly to commit f6361c6b3880 ("ARM: S3C24XX: remove separate restart
> > > code"), the platform watchdog reset code can be removed in favor of
> > > a generic watchdog driver which already handles reset.
> > >
> > > This allows removal of a bunch of machine code and fixes also W=1
> > > compile warnings:
> > >
> > > arch/arm/plat-samsung/watchdog-reset.c:29:6: warning: no previous 
> > > prototype for 'samsung_wdt_reset' [-Wmissing-prototypes]
> > >29 | void samsung_wdt_reset(void)
> > >   |  ^
> > > arch/arm/plat-samsung/watchdog-reset.c:69:13: warning: no previous 
> > > prototype for 'samsung_wdt_reset_of_init' [-Wmissing-prototypes]
> > >69 | void __init samsung_wdt_reset_of_init(void)
> > >   | ^
> > > arch/arm/plat-samsung/watchdog-reset.c:89:13: warning: no previous 
> > > prototype for 'samsung_wdt_reset_init' [-Wmissing-prototypes]
> > >89 | void __init samsung_wdt_reset_init(void __iomem *base)
> > >
> > > Signed-off-by: Krzysztof Kozlowski 
> > > ---
> > >  arch/arm/mach-s3c64xx/Kconfig   |  3 +-
> > >  arch/arm/mach-s3c64xx/common.c  | 15 +---
> > >  arch/arm/mach-s3c64xx/common.h  |  2 -
> > >  arch/arm/mach-s3c64xx/mach-anw6410.c|  1 -
> > >  arch/arm/mach-s3c64xx/mach-crag6410.c   |  1 -
> > >  arch/arm/mach-s3c64xx/mach-hmt.c|  1 -
> > >  arch/arm/mach-s3c64xx/mach-mini6410.c   |  1 -
> > >  arch/arm/mach-s3c64xx/mach-ncp.c|  1 -
> > >  arch/arm/mach-s3c64xx/mach-real6410.c   |  1 -
> > >  arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c | 17 -
> > >  arch/arm/mach-s3c64xx/mach-smartq5.c|  1 -
> > >  arch/arm/mach-s3c64xx/mach-smartq7.c|  1 -
> > >  arch/arm/mach-s3c64xx/mach-smdk6400.c   |  1 -
> > >  arch/arm/mach-s3c64xx/mach-smdk6410.c   |  1 -
> > >  arch/arm/mach-s3c64xx/watchdog-reset.h  | 16 -
> > >  arch/arm/plat-samsung/Kconfig   |  6 --
> > >  arch/arm/plat-samsung/Makefile  |  1 -
> > >  arch/arm/plat-samsung/watchdog-reset.c  | 93 -
> > >  18 files changed, 5 insertions(+), 158 deletions(-)
> > >  delete mode 100644 arch/arm/mach-s3c64xx/watchdog-reset.h
> > >  delete mode 100644 arch/arm/plat-samsung/watchdog-reset.c
> > >
> > 
> > Thanks for the patch! Please see my comments inline.
> > 
> > > diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
> > > index e208c2b48853..f3fcb570edf5 100644
> > > --- a/arch/arm/mach-s3c64xx/Kconfig
> > > +++ b/arch/arm/mach-s3c64xx/Kconfig
> > > @@ -18,9 +18,10 @@ menuconfig ARCH_S3C64XX
> > > select PM_GENERIC_DOMAINS if PM
> > > select S3C_DEV_NAND if ATAGS
> > > select S3C_GPIO_TRACK if ATAGS
> > > +   select S3C2410_WATCHDOG
> > > select SAMSUNG_ATAGS if ATAGS
> > > select SAMSUNG_WAKEMASK if PM
> > > -   select SAMSUNG_WDT_RESET
> > > +   select WATCHDOG
> > > help
> > >   Samsung S3C64XX series based systems
> > >
> > > diff --git a/arch/arm/mach-s3c64xx/common.c 
> > > b/arch/arm/mach-s3c64xx/common.c
> > > index a655bf0c7802..42e96d196f61 100644
> > > --- a/arch/arm/mach-s3c64xx/common.c
> > > +++ b/arch/arm/mach-s3c64xx/common.c
> > > @@ -50,7 +50,6 @@
> > >
> > >  #include "common.h"
> > >  #include "irq-uart.h"
> > > -#include "watchdog-reset.h"
> > >
> > >  /* External clock frequency */
> > >  static unsigned long xtal_f __ro_after_init = 1200;
> > > @@ -232,10 +231,11 @@ void __init s3c64xx_init_irq(u32 vic0_valid, u32 
> > > vic1_valid)
> > > /*
> > >  * FIXME: there is no better place to put this at the moment
> > >  * (s3c64xx_clk_init needs ioremap and must happen before 
> > > init_time
> > > -* samsung_wdt_reset_init needs clocks)
> > > +* samsung_wdt_reset_init needs clocks).  However
> > > +* samsung_wdt_reset_init() was removed in favor of watchdog 
> > > driver
> > > +* so this should be revised.
> > 
> > This leaves the comment referring to an inexistent function.
> 
> Yes, I left it as a reference/reason. Although might be quite confusing
> now...
> 
> > 
> > I wonder if this being here is actually a problem at all. It's legacy
> > code and probably there isn't much value in reshuffling it further.
> > Rather than that, we would probably want to make sure that everything
> > migrated to DT and just drop the board files.
> 
> Maybe let's remove the FIXME and leave the clock init. Since all these
> times no one fixed the FIXME, so now with limited hardware access I do
> not expect any movements here.
> 
> > 
> > >  */
> > > s3c64xx_clk_init(NULL, xtal_f, xusbxti_f, soc_is_s3c6400(), 
> > > S3C_VA_SYS);
> > > -   

Re: [PATCH v2] PCI: Fix kerneldoc of pci_vc_do_save_buffer()

[Bjorn Helgaas]

On Wed, Jul 29, 2020 at 08:26:20AM +0200, Krzysztof Kozlowski wrote:
> Fix W=1 compile warnings (invalid kerneldoc):
> 
> drivers/pci/vc.c:188: warning: Excess function parameter 'name' 
> description in 'pci_vc_do_save_buffer'
> 
> Signed-off-by: Krzysztof Kozlowski 

This looks great, but would you mind doing all the ones in drivers/pci
at the same time?  When I tested this, I also found the following, and
I don't think it's worth doing them one at a time:

  $ make W=1 drivers/pci/
  drivers/pci/hotplug/acpi_pcihp.c:69: warning: Function parameter or member 
'pdev' not described in 'acpi_get_hp_hw_control_from_firmware'
  drivers/pci/hotplug/acpi_pcihp.c:69: warning: Excess function parameter 'dev' 
description in 'acpi_get_hp_hw_control_from_firmware'
  drivers/pci/hotplug/acpi_pcihp.c:199: warning: Function parameter or member 
'handle' not described in 'acpi_pci_detect_ejectable'
  drivers/pci/endpoint/functions/pci-epf-test.c:189: warning: Function 
parameter or member 'epf_test' not described in 'pci_epf_test_clean_dma_chan'
  drivers/pci/endpoint/functions/pci-epf-test.c:189: warning: Excess function 
parameter 'epf' description in 'pci_epf_test_clean_dma_chan'
  drivers/pci/endpoint/pci-ep-cfs.c:17: warning: Function parameter or member 
'functions_idr' not described in 'DEFINE_IDR'
  drivers/pci/endpoint/pci-epc-core.c:18: warning: cannot understand function 
prototype: 'struct class *pci_epc_class; '
  drivers/pci/endpoint/pci-epf-core.c:18: warning: Function parameter or member 
'pci_epf_mutex' not described in 'DEFINE_MUTEX'
  drivers/pci/endpoint/pci-epf-core.c:80: warning: Function parameter or member 
'epf' not described in 'pci_epf_free_space'
  drivers/pci/endpoint/pci-epf-core.c:107: warning: Function parameter or 
member 'epf' not described in 'pci_epf_alloc_space'
  drivers/pci/endpoint/pci-epc-mem.c:16: warning: Incorrect use of kernel-doc 
format:  * pci_epc_mem_get_order() - determine the allocation order of a memory 
size
  drivers/pci/endpoint/pci-epc-mem.c:24: warning: Function parameter or member 
'mem' not described in 'pci_epc_mem_get_order'
  drivers/pci/endpoint/pci-epc-mem.c:24: warning: Function parameter or member 
'size' not described in 'pci_epc_mem_get_order'
  drivers/pci/setup-bus.c:62: warning: Function parameter or member 'min_align' 
not described in 'add_to_list'
  drivers/pci/vc.c:188: warning: Excess function parameter 'name' description 
in 'pci_vc_do_save_buffer'
  drivers/pci/of.c:262: warning: Function parameter or member 'ib_resources' 
not described in 'devm_of_pci_get_host_bridge_resources'
  drivers/pci/ats.c:196: warning: Function parameter or member 'pdev' not 
described in 'pci_enable_pri'
  drivers/pci/ats.c:196: warning: Function parameter or member 'reqs' not 
described in 'pci_enable_pri'
  drivers/pci/pci-pf-stub.c:20: warning: cannot understand function prototype: 
'const struct pci_device_id pci_pf_stub_whitelist[] = '

> ---
> 
> Changes since v1:
> 1. Fix subject
> ---
>  drivers/pci/vc.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/pci/vc.c b/drivers/pci/vc.c
> index 5486f8768c86..5fc59ac31145 100644
> --- a/drivers/pci/vc.c
> +++ b/drivers/pci/vc.c
> @@ -172,7 +172,6 @@ static void pci_vc_enable(struct pci_dev *dev, int pos, 
> int res)
>   * @dev: device
>   * @pos: starting position of VC capability (VC/VC9/MFVC)
>   * @save_state: buffer for save/restore
> - * @name: for error message
>   * @save: if provided a buffer, this indicates what to do with it
>   *
>   * Walking Virtual Channel config space to size, save, or restore it
> -- 
> 2.17.1
> 

[PATCH] lib: kunit: add list_sort test conversion to KUnit

[Vitor Massaru Iha]

This adds the conversion of the runtime tests of test_list_sort,
from `lib/test_list_sort.c` to KUnit tests.

Please apply this commit first (linux-kselftest/kunit-fixes):
3f37d14b8a3152441f36b6bc74000996679f0998 kunit: kunit_config: Fix parsing of 
CONFIG options with space

Code Style Documentation: [0]

Signed-off-by: Vitor Massaru Iha 
Link: [0] 
https://lore.kernel.org/linux-kselftest/20200620054944.167330-1-david...@google.com/T/#u
---
 lib/Kconfig.debug   | 29 +---
 lib/Makefile|  2 +-
 lib/{test_list_sort.c => list_sort_kunit.c} | 73 +++--
 3 files changed, 58 insertions(+), 46 deletions(-)
 rename lib/{test_list_sort.c => list_sort_kunit.c} (62%)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 9ad9210d70a1..de4fd020a4af 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1854,16 +1854,6 @@ config LKDTM
Documentation on how to use the module can be found in
Documentation/fault-injection/provoke-crashes.rst
 
-config TEST_LIST_SORT
-   tristate "Linked list sorting test"
-   depends on DEBUG_KERNEL || m
-   help
- Enable this to turn on 'list_sort()' function test. This test is
- executed only once during system boot (so affects only boot time),
- or at module load time.
-
- If unsure, say N.
-
 config TEST_MIN_HEAP
tristate "Min heap test"
depends on DEBUG_KERNEL || m
@@ -2173,6 +2163,25 @@ config LIST_KUNIT_TEST
 
  If unsure, say N.
 
+config LIST_SORT_KUNIT
+   tristate "KUnit Linked list sorting test"
+   depends on KUNIT
+   depends on DEBUG_KERNEL || m
+   help
+ Enable this to turn on 'list_sort()' function test. This test is
+ executed only once during system boot (so affects only boot time),
+ or at module load time.
+
+  KUnit tests run during boot and output the results to the debug log
+ in TAP format (http://testanything.org/). Only useful for kernel devs
+ running the KUnit test harness, and not intended for inclusion into a
+ production build.
+
+ For more information on KUnit and unit tests in general please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit/.
+
+ If unsure, say N.
+
 config LINEAR_RANGES_TEST
tristate "KUnit test for linear_ranges"
depends on KUNIT
diff --git a/lib/Makefile b/lib/Makefile
index b1c42c10073b..798724b7cde0 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -71,7 +71,6 @@ obj-$(CONFIG_TEST_UBSAN) += test_ubsan.o
 CFLAGS_test_ubsan.o += $(call cc-disable-warning, vla)
 UBSAN_SANITIZE_test_ubsan.o := y
 obj-$(CONFIG_TEST_KSTRTOX) += test-kstrtox.o
-obj-$(CONFIG_TEST_LIST_SORT) += test_list_sort.o
 obj-$(CONFIG_TEST_MIN_HEAP) += test_min_heap.o
 obj-$(CONFIG_TEST_LKM) += test_module.o
 obj-$(CONFIG_TEST_VMALLOC) += test_vmalloc.o
@@ -317,4 +316,5 @@ obj-$(CONFIG_OBJAGG) += objagg.o
 
 # KUnit tests
 obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
+obj-$(CONFIG_LIST_SORT_KUNIT) += list_sort_kunit.o
 obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
diff --git a/lib/test_list_sort.c b/lib/list_sort_kunit.c
similarity index 62%
rename from lib/test_list_sort.c
rename to lib/list_sort_kunit.c
index 1f017d3b610e..20cbacbb7d6c 100644
--- a/lib/test_list_sort.c
+++ b/lib/list_sort_kunit.c
@@ -1,13 +1,10 @@
 // SPDX-License-Identifier: GPL-2.0-only
-#define pr_fmt(fmt) "list_sort_test: " fmt
+#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
-#include 
 #include 
 #include 
-#include 
-#include 
-#include 
 #include 
+#include 
 
 /*
  * The pattern of set bits in the list length determines which cases
@@ -29,28 +26,28 @@ struct debug_el {
 /* Array, containing pointers to all elements in the test list */
 static struct debug_el **elts __initdata;
 
-static int __init check(struct debug_el *ela, struct debug_el *elb)
+static int __init check(struct kunit *context, struct debug_el *ela, struct 
debug_el *elb)
 {
if (ela->serial >= TEST_LIST_LEN) {
-   pr_err("error: incorrect serial %d\n", ela->serial);
+   KUNIT_FAIL(context, "incorrect serial %d", ela->serial);
return -EINVAL;
}
if (elb->serial >= TEST_LIST_LEN) {
-   pr_err("error: incorrect serial %d\n", elb->serial);
+   KUNIT_FAIL(context, "incorrect serial %d", elb->serial);
return -EINVAL;
}
if (elts[ela->serial] != ela || elts[elb->serial] != elb) {
-   pr_err("error: phantom element\n");
+   KUNIT_FAIL(context, "phantom element");
return -EINVAL;
}
if (ela->poison1 != TEST_POISON1 || ela->poison2 != TEST_POISON2) {
-   pr_err("error: bad poison: %#x/%#x\n",
-   ela->poison1, ela->poison2);
+   KUNIT_FAIL(context, "bad poison: %#x/%#x",
+  ela->poison1, 

Re: [PATCH v4 4/5] irqchip/irq-pruss-intc: Implement irq_{get,set}_irqchip_state ops

[David Lechner]

On 7/28/20 4:18 AM, Grzegorz Jaszczyk wrote:

From: David Lechner 

This implements the irq_get_irqchip_state and irq_set_irqchip_state
callbacks for the TI PRUSS INTC driver. The set callback can be used
by drivers to "kick" a PRU by injecting a PRU system event.

Example:


We could improve this example by showing a device tree node of a
firmware-defined device implemented in the PRU:

/* Software-defined UART in PRU */
pru_uart: serial@ {
compatible = "ti,pru-uart";
...
interrupt-parent = <_intc>;
/* PRU system event 31, channel 0, host event 0 */
interrupts = <31 0 0>, ...;
interrupt-names = "kick", ...;
...
},

Then driver would request the IRQ during probe:

data->kick_irq = of_irq_get_byname(dev, "kick");
if (data->kick_irq < 0)
...


And later the driver would use the IRQ to kick the PRU:

irq_set_irqchip_state(data->kick_irq, IRQCHIP_STATE_PENDING, true);



  irq_set_irqchip_state(irq, IRQCHIP_STATE_PENDING, true);

Signed-off-by: David Lechner 
Signed-off-by: Suman Anna 
Signed-off-by: Grzegorz Jaszczyk 
Reviewed-by: Lee Jones 
---

Re: kernel BUG at include/linux/swapops.h:LINE!

[Kirill A. Shutemov]

On Mon, Jul 27, 2020 at 01:03:10PM +0100, Matthew Wilcox wrote:
> On Mon, Jul 27, 2020 at 01:31:40PM +0300, Kirill A. Shutemov wrote:
> > On Sun, Jul 26, 2020 at 05:49:04PM +0100, Matthew Wilcox wrote:
> > > On Fri, Jul 24, 2020 at 02:13:11PM +0300, Kirill A. Shutemov wrote:
> > > > On Thu, Jul 23, 2020 at 03:37:44PM +0800, Hillf Danton wrote:
> > > > > 
> > > > > On Tue, 21 Jul 2020 14:11:31 +0300 Kirill A. Shutemov wrote:
> > > > > > On Mon, Jul 20, 2020 at 04:51:44PM -0700, Andrew Morton wrote:
> > > > > > > On Sun, 19 Jul 2020 14:10:19 -0700 syzbot wrote:
> > > > > > > 
> > > > > > > > syzbot has found a reproducer for the following issue on:
> > > > > > > > 
> > > > > > > > HEAD commit:4c43049f Add linux-next specific files for 
> > > > > > > > 20200716
> > > > > > > > git tree:   linux-next
> > > > > > > > console output: 
> > > > > > > > https://syzkaller.appspot.com/x/log.txt?x=12c5608710
> > > > > > > > kernel config:  
> > > > > > > > https://syzkaller.appspot.com/x/.config?x=2c76d72659687242
> > > > > > > > dashboard link: 
> > > > > > > > https://syzkaller.appspot.com/bug?extid=c48f34012b06c4ac67dd
> > > > > > > > compiler:   gcc (GCC) 10.1.0-syz 20200507
> > > > > > > > syz repro:  
> > > > > > > > https://syzkaller.appspot.com/x/repro.syz?x=1344abeb10
> > > > > > > > 
> > > > > > > > IMPORTANT: if you fix the issue, please add the following tag 
> > > > > > > > to the commit:
> > > > > > > > Reported-by: 
> > > > > > > > syzbot+c48f34012b06c4ac6...@syzkaller.appspotmail.com
> > > > > > > 
> > > > > > > Thanks.
> > > > > > > 
> > > > > > > __handle_mm_fault
> > > > > > >   ->pmd_migration_entry_wait
> > > > > > > ->migration_entry_to_page
> > > > > > > 
> > > > > > > stumbled onto an unlocked page.
> > > > > > > 
> > > > > > > I don't immediately see a cause.  Perhaps Matthew's "THP prep 
> > > > > > > patches",
> > > > > > > perhaps something else.
> > > > > > > 
> > > > > > > Is it possible to perform a bisection?
> > > > > > 
> > > > > > Maybe it's related to the new lock_page_async()?
> > > > > 
> > > > > Or is there likely the window that after copy_huge_pmd() the src pmd 
> > > > > migrate
> > > > > entry is removed and the page unlocked but the dst is not?
> > > > 
> > > > No.
> > > > 
> > > > copy_huge_pmd() runs with exclusive mmap_lock on the source side and
> > > > destination side is not running yet.
> > > 
> > > The one I'm hitting is huge related though.
> > > 
> > > I added this debug:
> > > 
> > > +++ b/include/linux/swapops.h
> > > @@ -165,8 +165,9 @@ static inline struct page 
> > > *device_private_entry_to_page(swp_entry_t entry)
> > >  #ifdef CONFIG_MIGRATION
> > >  static inline swp_entry_t make_migration_entry(struct page *page, int 
> > > write)
> > >  {
> > > -   BUG_ON(!PageLocked(compound_head(page)));
> > > +   VM_BUG_ON_PAGE(!PageLocked(page), page);
> > >  
> > > +if (PageCompound(page)) printk("pfn %lx order %d\n", page_to_pfn(page), 
> > > thp_order(thp_head(page)));
> > > return swp_entry(write ? SWP_MIGRATION_WRITE : SWP_MIGRATION_READ,
> > > page_to_pfn(page));
> > >  }
> > > @@ -194,7 +195,11 @@ static inline struct page 
> > > *migration_entry_to_page(swp_entry_t entry)
> > >  * Any use of migration entries may only occur while the
> > >  * corresponding page is locked
> > >  */
> > > -   BUG_ON(!PageLocked(compound_head(p)));
> > > +   if (!PageLocked(p)) {
> > > +   dump_page(p, "not locked");
> > > +   printk("swap entry %d.%lx\n", swp_type(entry), 
> > > swp_offset(entry));
> > > +   BUG();
> > > +   }
> > > return p;
> > >  }
> > >  
> > > 
> > > and got useful output (while running generic/086):
> > > 
> > > 1457 086 (20181): drop_caches: 3
> > > 1457 page:a216ae9a refcount:2 mapcount:0 mapping:9ba7bfed 
> > > index:0x2227 pfn:0x229e7
> > > 1457 aops:def_blk_aops ino:0
> > > 1457 flags: 0x40002030(lru|active|private)
> > > 1457 raw: 40002030 f5b4416b5a48 f5b4408a7988 
> > > 9e9c34848578
> > > 1457 raw: 2227 9e9bd18f0d00 0002 
> > > 
> > > 1457 page dumped because: not locked
> > > 1457 swap entry 30.229e7
> > > 1457 [ cut here ]
> > > 1457 kernel BUG at include/linux/swapops.h:201!
> > > 1457 invalid opcode:  [#1] SMP PTI
> > > 1457 CPU: 3 PID: 646 Comm: check Kdump: loaded Tainted: GW
> > >  5.8.0-rc6-00067-gd8b18bdf9870-dirty #355
> > > 1457 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 
> > > 04/01/2014
> > > 1457 RIP: 0010:__migration_entry_wait+0x109/0x110
> > > [...]
> > > 
> > > Looking back in the trace, I see:
> > > 
> > > ...
> > > 1457 pfn 229e5 order 9
> > > 1457 pfn 229e6 order 9
> > > 1457 pfn 229e7 order 9
> > > 1457 pfn 229e8 order 9
> > > 1457 pfn 229e9 order 9
> > > ...
> > > 
> > > so I would say we have a refcount problem.  I've 

[PATCH v4 1/3] staging: rtl8723bs: Fix coding style errors

[Aditya Jain]

Fixing ERROR: "foo *bar" should be "foo *bar" in hal_phy_cfg.h
as reported by checkpatch.pl

Signed-off-by: Aditya Jain 
---
 .../staging/rtl8723bs/include/hal_phy_cfg.h| 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/rtl8723bs/include/hal_phy_cfg.h 
b/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
index 419ddb0733aa..7e48abc4c760 100644
--- a/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
+++ b/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
@@ -42,7 +42,7 @@ u32   Data
 
 u32
 PHY_QueryRFReg_8723B(
-struct adapter *   Adapter,
+struct adapter *Adapter,
 u8 eRFPath,
 u32RegAddr,
 u32BitMask
@@ -50,7 +50,7 @@ u32   BitMask
 
 void
 PHY_SetRFReg_8723B(
-struct adapter *   Adapter,
+struct adapter *Adapter,
 u8 eRFPath,
 u32RegAddr,
 u32BitMask,
@@ -66,7 +66,7 @@ s32 PHY_MACConfig8723B(struct adapter *padapter);
 
 void
 PHY_SetTxPowerIndex(
-struct adapter *   Adapter,
+struct adapter *Adapter,
 u32PowerIndex,
 u8 RFPath,
 u8 Rate
@@ -74,7 +74,7 @@ u8Rate
 
 u8
 PHY_GetTxPowerIndex(
-struct adapter *   padapter,
+struct adapter *padapter,
 u8 RFPath,
 u8 Rate,
 enum CHANNEL_WIDTH BandWidth,
@@ -83,19 +83,19 @@ u8  Channel
 
 void
 PHY_GetTxPowerLevel8723B(
-struct adapter *   Adapter,
-   s32*powerlevel
+struct adapter *Adapter,
+   s32 *powerlevel
);
 
 void
 PHY_SetTxPowerLevel8723B(
-struct adapter *   Adapter,
+struct adapter *Adapter,
 u8 channel
);
 
 void
 PHY_SetBWMode8723B(
-struct adapter *   Adapter,
+struct adapter *Adapter,
 enum CHANNEL_WIDTH Bandwidth,  /*  20M or 40M */
 unsigned char  Offset  /*  Upper, Lower, or Don't care 
*/
 );
@@ -108,7 +108,7 @@ u8 channel
 
 void
 PHY_SetSwChnlBWMode8723B(
-struct adapter *   Adapter,
+struct adapter *Adapter,
 u8 channel,
 enum CHANNEL_WIDTH Bandwidth,
 u8 Offset40,
-- 
2.25.1

[PATCH] MAINTAINERS: Drop Vincent Sanders from Simtec S3C boards

[Krzysztof Kozlowski]

Vincent Sanders' email bounces with code 550 (user does not exist) so
remove the entry from Simtec S3C24xx boards.

Cc: Simtec Linux Team 
Cc: linux-samsung-...@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski 
---
 MAINTAINERS | 2 --
 1 file changed, 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index f5d7cf3c3aaa..371db77df175 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15819,13 +15819,11 @@ F:drivers/video/fbdev/simplefb.c
 F: include/linux/platform_data/simplefb.h
 
 SIMTEC EB110ATX (Chalice CATS)
-M: Vincent Sanders 
 M: Simtec Linux Team 
 S: Supported
 W: http://www.simtec.co.uk/products/EB110ATX/
 
 SIMTEC EB2410ITX (BAST)
-M: Vincent Sanders 
 M: Simtec Linux Team 
 S: Supported
 W: http://www.simtec.co.uk/products/EB2410ITX/
-- 
2.17.1

[PATCH v4 0/3] Fix coding style issues in staging

[Aditya Jain]

Hey everyone,

Following the comments received I've updated the patch.
The patch cleans up coding style issues in the file
drivers/staging/rtl8723bs/include/hal_phy_cfg.h

Changelog:

v1:
Fixed ERROR: "foo * bar" should be "foo *bar" reported by
checkpatch.pl

v1 -> v2:
Cleaned up multiline function declarations as suggested
by Greg and adjusted spacing in macro definitions to align them.

v2 -> v3:
Broke the single patch in v2 into multiple patches with each
patch doing one single task.

v3 -> v4:
1. Corrected the patch subject following Larry's suggestion.
2. Merged the second and third patches into one following Greg's 
comment.
3. Removed comments from the PHY_SetBWMode8723B function declaration.

Aditya Jain (3):
  staging: rtl8723bs: Fix coding style errors
  staging: rtl8723bs: Clean up function declations
  staging: rtl8723bs: Align macro definitions

 .../staging/rtl8723bs/include/hal_phy_cfg.h   | 116 +-
 1 file changed, 32 insertions(+), 84 deletions(-)

-- 
2.25.1

[PATCH v4 2/3] staging: rtl8723bs: Clean up function declations

[Aditya Jain]

Clean up multiline function declartions in hal_phy_cfg.h
to improve code readablility

Signed-off-by: Aditya Jain 
---
 .../staging/rtl8723bs/include/hal_phy_cfg.h   | 110 +-
 1 file changed, 29 insertions(+), 81 deletions(-)

diff --git a/drivers/staging/rtl8723bs/include/hal_phy_cfg.h 
b/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
index 7e48abc4c760..0eb3e57f4082 100644
--- a/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
+++ b/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
@@ -25,37 +25,16 @@
 /*--Define structure 
End*/
 
 /*--Exported Function prototype-*/
-u32
-PHY_QueryBBReg_8723B(
-struct adapter *Adapter,
-u32RegAddr,
-u32BitMask
-   );
-
-void
-PHY_SetBBReg_8723B(
-struct adapter *Adapter,
-u32RegAddr,
-u32BitMask,
-u32Data
-   );
-
-u32
-PHY_QueryRFReg_8723B(
-struct adapter *Adapter,
-u8 eRFPath,
-u32RegAddr,
-u32BitMask
-   );
-
-void
-PHY_SetRFReg_8723B(
-struct adapter *Adapter,
-u8 eRFPath,
-u32RegAddr,
-u32BitMask,
-u32Data
-   );
+u32 PHY_QueryBBReg_8723B(struct adapter *Adapter, u32 RegAddr, u32 BitMask);
+
+void PHY_SetBBReg_8723B(struct adapter *Adapter, u32 RegAddr,
+   u32 BitMask, u32 Data);
+
+u32 PHY_QueryRFReg_8723B(struct adapter *Adapter, u8 eRFPath,
+u32 RegAddr, u32 BitMask);
+
+void PHY_SetRFReg_8723B(struct adapter *Adapter, u8 eRFPath,
+   u32 RegAddr, u32 BitMask, u32 Data);
 
 /* MAC/BB/RF HAL config */
 int PHY_BBConfig8723B(struct adapter *Adapter);
@@ -64,56 +43,25 @@ int PHY_RFConfig8723B(struct adapter *Adapter);
 
 s32 PHY_MACConfig8723B(struct adapter *padapter);
 
-void
-PHY_SetTxPowerIndex(
-struct adapter *Adapter,
-u32PowerIndex,
-u8 RFPath,
-u8 Rate
-   );
-
-u8
-PHY_GetTxPowerIndex(
-struct adapter *padapter,
-u8 RFPath,
-u8 Rate,
-enum CHANNEL_WIDTH BandWidth,
-u8 Channel
-   );
-
-void
-PHY_GetTxPowerLevel8723B(
-struct adapter *Adapter,
-   s32 *powerlevel
-   );
-
-void
-PHY_SetTxPowerLevel8723B(
-struct adapter *Adapter,
-u8 channel
-   );
-
-void
-PHY_SetBWMode8723B(
-struct adapter *Adapter,
-enum CHANNEL_WIDTH Bandwidth,  /*  20M or 40M */
-unsigned char  Offset  /*  Upper, Lower, or Don't care 
*/
-);
-
-void
-PHY_SwChnl8723B(/*  Call after initialization */
-struct adapter *Adapter,
-u8 channel
-   );
-
-void
-PHY_SetSwChnlBWMode8723B(
-struct adapter *Adapter,
-u8 channel,
-enum CHANNEL_WIDTH Bandwidth,
-u8 Offset40,
-u8 Offset80
-);
+void PHY_SetTxPowerIndex(struct adapter *Adapter, u32 PowerIndex,
+u8 RFPath, u8 Rate);
+
+u8 PHY_GetTxPowerIndex(struct adapter *padapter, u8 RFPath, u8 Rate,
+   enum CHANNEL_WIDTH BandWidth, u8 Channel);
+
+void PHY_GetTxPowerLevel8723B(struct adapter *Adapter, s32 *powerlevel);
+
+void PHY_SetTxPowerLevel8723B(struct adapter *Adapter, u8 channel);
+
+void PHY_SetBWMode8723B(struct adapter *Adapter, enum CHANNEL_WIDTH Bandwidth,
+   unsigned char Offset);
+
+/*  Call after initialization */
+void PHY_SwChnl8723B(struct adapter *Adapter, u8 channel);
+
+void PHY_SetSwChnlBWMode8723B(struct adapter *Adapter, u8 channel,
+   enum CHANNEL_WIDTH Bandwidth,
+   u8 Offset40, u8 Offset80);
 
 /*--Exported Function prototype 
End-*/
 
-- 
2.25.1

[PATCH v4 3/3] staging: rtl8723bs: Align macro definitions

[Aditya Jain]

Adjust spacing in macro definitions to align them and improve
readbility

Signed-off-by: Aditya Jain 
---
 drivers/staging/rtl8723bs/include/hal_phy_cfg.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8723bs/include/hal_phy_cfg.h 
b/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
index 0eb3e57f4082..ed3488a09d79 100644
--- a/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
+++ b/drivers/staging/rtl8723bs/include/hal_phy_cfg.h
@@ -8,11 +8,11 @@
 #define __INC_HAL8723BPHYCFG_H__
 
 /*--Define Parameters---*/
-#define LOOP_LIMIT 5
-#define MAX_STALL_TIME 50  /* us */
+#define LOOP_LIMIT 5
+#define MAX_STALL_TIME 50  /* us */
 #define AntennaDiversityValue  0x80/* Adapter->bSoftwareAntennaDiversity ? 
0x00:0x80) */
 #define MAX_TXPWR_IDX_NMODE_92S63
-#define Reset_Cnt_Limit3
+#define Reset_Cnt_Limit3
 
 #define MAX_AGGR_NUM   0x07
 
-- 
2.25.1

Re: [PATCH 2/2] mm, util: account_locked_vm() does not hold mmap_lock

[Hugh Dickins]

On Sun, 26 Jul 2020, Pengfei Li wrote:

> Since mm->locked_vm is already an atomic counter, account_locked_vm()
> does not need to hold mmap_lock.

I am worried that this patch, already added to mmotm, along with its
1/2 making locked_vm an atomic64, might be rushed into v5.9 with just
that two-line commit description, and no discussion at all.

locked_vm belongs fundamentally to mm/mlock.c, and the lock to guard
it is mmap_lock; and mlock() has some complicated stuff to do under
that lock while it decides how to adjust locked_vm.

It is very easy to convert an unsigned long to an atomic64_t, but
"atomic read, check limit and do stuff, atomic add" does not give
the same guarantee as holding the right lock around it all.

(At the very least, __account_locked_vm() in 1/2 should be changed to
replace its atomic64_add by an atomic64_cmpxchg, to enforce the limit
that it just checked.  But that will be no more than lipstick on a pig,
when the right lock that everyone else agrees upon is not being held.)

Now, it can be argued that our locked_vm and pinned_vm maintenance
is so random and deficient, and too difficult to keep right across
a sprawl of drivers, that we should just be grateful for those that
do volunteer to subject themselves to RLIMIT_MEMLOCK limitation,
and never mind if it's a little racy.

And it may well be that all those who have made considerable efforts
in the past to improve the situation, have more interesting things to
devote their time to, and would prefer not to get dragged back here.

But let's at least give this a little more visibility, and hope
to hear opinions one way or the other from those who care.

Hugh

> 
> Signed-off-by: Pengfei Li 
> ---
>  drivers/vfio/vfio_iommu_type1.c |  8 ++--
>  mm/util.c   | 15 +++
>  2 files changed, 5 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/vfio/vfio_iommu_type1.c b/drivers/vfio/vfio_iommu_type1.c
> index 78013be07fe7..53818fce78a6 100644
> --- a/drivers/vfio/vfio_iommu_type1.c
> +++ b/drivers/vfio/vfio_iommu_type1.c
> @@ -376,12 +376,8 @@ static int vfio_lock_acct(struct vfio_dma *dma, long 
> npage, bool async)
>   if (!mm)
>   return -ESRCH; /* process exited */
>  
> - ret = mmap_write_lock_killable(mm);
> - if (!ret) {
> - ret = __account_locked_vm(mm, abs(npage), npage > 0, dma->task,
> -   dma->lock_cap);
> - mmap_write_unlock(mm);
> - }
> + ret = __account_locked_vm(mm, abs(npage), npage > 0,
> + dma->task, dma->lock_cap);
>  
>   if (async)
>   mmput(mm);
> diff --git a/mm/util.c b/mm/util.c
> index 473add0dc275..320fdd537aea 100644
> --- a/mm/util.c
> +++ b/mm/util.c
> @@ -424,8 +424,7 @@ void arch_pick_mmap_layout(struct mm_struct *mm, struct 
> rlimit *rlim_stack)
>   * @task:task used to check RLIMIT_MEMLOCK
>   * @bypass_rlim: %true if checking RLIMIT_MEMLOCK should be skipped
>   *
> - * Assumes @task and @mm are valid (i.e. at least one reference on each), and
> - * that mmap_lock is held as writer.
> + * Assumes @task and @mm are valid (i.e. at least one reference on each).
>   *
>   * Return:
>   * * 0   on success
> @@ -437,8 +436,6 @@ int __account_locked_vm(struct mm_struct *mm, unsigned 
> long pages, bool inc,
>   unsigned long locked_vm, limit;
>   int ret = 0;
>  
> - mmap_assert_write_locked(mm);
> -
>   locked_vm = atomic64_read(>locked_vm);
>   if (inc) {
>   if (!bypass_rlim) {
> @@ -476,17 +473,11 @@ EXPORT_SYMBOL_GPL(__account_locked_vm);
>   */
>  int account_locked_vm(struct mm_struct *mm, unsigned long pages, bool inc)
>  {
> - int ret;
> -
>   if (pages == 0 || !mm)
>   return 0;
>  
> - mmap_write_lock(mm);
> - ret = __account_locked_vm(mm, pages, inc, current,
> -   capable(CAP_IPC_LOCK));
> - mmap_write_unlock(mm);
> -
> - return ret;
> + return __account_locked_vm(mm, pages, inc,
> + current, capable(CAP_IPC_LOCK));
>  }
>  EXPORT_SYMBOL_GPL(account_locked_vm);
>  
> -- 
> 2.26.2

Re: [PATCH v5 2/2] remoteproc: core: Register the character device interface

[Bjorn Andersson]

On Wed 29 Jul 10:40 PDT 2020, Siddharth Gupta wrote:

> Add the character device during rproc_add. This would create
> a character device node at /dev/remoteproc. Userspace
> applications can interact with the remote processor using this
> interface.
> 

Reviewed-by: Bjorn Andersson 

> Signed-off-by: Rishabh Bhatnagar 
> Signed-off-by: Siddharth Gupta 
> ---
>  drivers/remoteproc/remoteproc_core.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 277d3bf..7f90eee 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -1986,6 +1986,11 @@ int rproc_add(struct rproc *rproc)
>   /* create debugfs entries */
>   rproc_create_debug_dir(rproc);
>  
> + /* add char device for this remoteproc */
> + ret = rproc_char_device_add(rproc);
> + if (ret < 0)
> + return ret;
> +
>   /*
>* Remind ourselves the remote processor has been attached to rather
>* than booted by the remoteproc core.  This is important because the
> @@ -2262,6 +2267,7 @@ int rproc_del(struct rproc *rproc)
>   mutex_unlock(>lock);
>  
>   rproc_delete_debug_dir(rproc);
> + rproc_char_device_remove(rproc);
>  
>   /* the rproc is downref'ed as soon as it's removed from the klist */
>   mutex_lock(_list_mutex);
> @@ -2430,6 +2436,7 @@ static int __init remoteproc_init(void)
>  {
>   rproc_init_sysfs();
>   rproc_init_debugfs();
> + rproc_init_cdev();
>   rproc_init_panic();
>  
>   return 0;
> -- 
> Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH v5 1/2] remoteproc: Add remoteproc character device interface

[Bjorn Andersson]

On Wed 29 Jul 10:40 PDT 2020, Siddharth Gupta wrote:

> Add the character device interface into remoteproc framework.
> This interface can be used in order to boot/shutdown remote
> subsystems and provides a basic ioctl based interface to implement
> supplementary functionality. An ioctl call is implemented to enable
> the shutdown on release feature which will allow remote processors to
> be shutdown when the controlling userpsace application crashes or hangs.

s/userspace/userspace/

But no need to resend just because of that.

> 
> Signed-off-by: Rishabh Bhatnagar 
> Signed-off-by: Siddharth Gupta 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  Documentation/userspace-api/ioctl/ioctl-number.rst |   1 +
>  drivers/remoteproc/Kconfig |   9 ++
>  drivers/remoteproc/Makefile|   1 +
>  drivers/remoteproc/remoteproc_cdev.c   | 124 
> +
>  drivers/remoteproc/remoteproc_internal.h   |  28 +
>  include/linux/remoteproc.h |   5 +
>  include/uapi/linux/remoteproc_cdev.h   |  37 ++
>  7 files changed, 205 insertions(+)
>  create mode 100644 drivers/remoteproc/remoteproc_cdev.c
>  create mode 100644 include/uapi/linux/remoteproc_cdev.h
> 
> diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst 
> b/Documentation/userspace-api/ioctl/ioctl-number.rst
> index 59472cd..2a19883 100644
> --- a/Documentation/userspace-api/ioctl/ioctl-number.rst
> +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst
> @@ -339,6 +339,7 @@ Code  Seq#Include File
>Comments
>  0xB4  00-0F  linux/gpio.h
> 
>  0xB5  00-0F  uapi/linux/rpmsg.h  
> 
>  0xB6  alllinux/fpga-dfl.h
> +0xB7  alluapi/linux/remoteproc_cdev.h
> 
>  0xC0  00-0F  linux/usb/iowarrior.h
>  0xCA  00-0F  uapi/misc/cxl.h
>  0xCA  10-2F  uapi/misc/ocxl.h
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 48315dc..c6659dfe 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -14,6 +14,15 @@ config REMOTEPROC
>  
>  if REMOTEPROC
>  
> +config REMOTEPROC_CDEV
> + bool "Remoteproc character device interface"
> + help
> +   Say y here to have a character device interface for the remoteproc
> +   framework. Userspace can boot/shutdown remote processors through
> +   this interface.
> +
> +   It's safe to say N if you don't want to use this interface.
> +
>  config IMX_REMOTEPROC
>   tristate "IMX6/7 remoteproc support"
>   depends on ARCH_MXC
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 4d4307d..3dfa28e 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -10,6 +10,7 @@ remoteproc-y+= 
> remoteproc_debugfs.o
>  remoteproc-y += remoteproc_sysfs.o
>  remoteproc-y += remoteproc_virtio.o
>  remoteproc-y += remoteproc_elf_loader.o
> +obj-$(CONFIG_REMOTEPROC_CDEV)+= remoteproc_cdev.o
>  obj-$(CONFIG_IMX_REMOTEPROC) += imx_rproc.o
>  obj-$(CONFIG_INGENIC_VPU_RPROC)  += ingenic_rproc.o
>  obj-$(CONFIG_MTK_SCP)+= mtk_scp.o mtk_scp_ipi.o
> diff --git a/drivers/remoteproc/remoteproc_cdev.c 
> b/drivers/remoteproc/remoteproc_cdev.c
> new file mode 100644
> index 000..a7ac11c
> --- /dev/null
> +++ b/drivers/remoteproc/remoteproc_cdev.c
> @@ -0,0 +1,124 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Character device interface driver for Remoteproc framework.
> + *
> + * Copyright (c) 2020, The Linux Foundation. All rights reserved.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "remoteproc_internal.h"
> +
> +#define NUM_RPROC_DEVICES64
> +static dev_t rproc_major;
> +
> +static ssize_t rproc_cdev_write(struct file *filp, const char __user *buf, 
> size_t len, loff_t *pos)
> +{
> + struct rproc *rproc = container_of(filp->f_inode->i_cdev, struct rproc, 
> cdev);
> + int ret = 0;
> + char cmd[10];
> +
> + if (!len || len > sizeof(cmd))
> + return -EINVAL;
> +
> + ret = copy_from_user(cmd, buf, len);
> + if (ret)
> + return -EFAULT;
> +
> + if (!strncmp(cmd, "start", len)) {
> + if (rproc->state == RPROC_RUNNING)
> + return -EBUSY;
> +
> + ret = rproc_boot(rproc);
> + } else if (!strncmp(cmd, "stop", len)) {
> + if (rproc->state != RPROC_RUNNING)
> + return -EINVAL;
> +
> + rproc_shutdown(rproc);
> + } else {
> + 

Re: [PATCH v2] lib: kunit: Convert test_sort to KUnit test

[Andy Shevchenko]

On Wed, Jul 29, 2020 at 04:11:51PM -0300, Vitor Massaru Iha wrote:
> This adds the conversion of the test_sort.c to KUnit test.
> 
> Please apply this commit first (linux-kselftest/kunit-fixes):
> 3f37d14b8a3152441f36b6bc74000996679f0998 kunit: kunit_config: Fix parsing of 
> CONFIG options with space

Looks like you mixed up commit message and changelog / comments.

> Code Style Documentation: [0]
> 
> Fix these warnings Reported-by l...@intel.com
> 
> WARNING: modpost: vmlinux.o(.data+0x4fc70): Section mismatch in reference 
> from the variable sort_test_cases to the variable .init.text:sort_test
>The variable sort_test_cases references
>the variable __init sort_test
>If the reference is valid then annotate the
>variable with or __refdata (see linux/init.h) or name the variable
> 
> WARNING: modpost: lib/sort_kunit.o(.data+0x11c): Section mismatch in 
> reference from the variable sort_test_cases to the function 
> .init.text:sort_test()
>The variable sort_test_cases references
>the function __init sort_test()

> Signed-off-by: Vitor Massaru Iha 
> Reported-by: kernel test robot 
> Link: [0] 
> https://lore.kernel.org/linux-kselftest/20200620054944.167330-1-david...@google.com/T/#u

This should be in different order: Link, Reported-by, SoB.
Also [0] is unnecessary

>  lib/{test_sort.c => sort_kunit.c} | 31 +++

Still opened question why kunit is a suffix? Can't we leave same name? Can't we
do it rather prefix?

-- 
With Best Regards,
Andy Shevchenko

Re: [Intel-gfx] [PATCH v12 2/3] drm/i915: add syncobj timeline support

[Kees Cook]

On Wed, Jul 29, 2020 at 10:51:23AM -0700, Linus Torvalds wrote:
> On Wed, Jul 29, 2020 at 5:24 AM Daniel Vetter  wrote:
> >
> > Do we have a access_ok_array or so? Instead of duplicating overflow checks
> > everywhere and getting it all wrong ...
> 
> I really really think you should get away from access_ok() entirely.
> 
> Please just get rid of it, and use "copy_from_user()" instead.

Yes please. :) It also makes code SO much easier to audit (both
automatically and manually).

-- 
Kees Cook

Re: linux-next: build failure after merge of the vfs tree

[Al Viro]

On Wed, Jul 29, 2020 at 08:33:05AM +0200, Christoph Hellwig wrote:
> Thanks,
> 
> I've sent out a fixed version.

#work.quota-compat and #for-next rebuilt (and pushed) with it...

Re: [PATCH net-next v2] net: mvneta: fix comment about phylink_speed_down

[David Miller]

From: Jisheng Zhang 
Date: Wed, 29 Jul 2020 17:49:09 +0800

> mvneta has switched to phylink, so the comment should look
> like "We may have called phylink_speed_down before".
> 
> Signed-off-by: Jisheng Zhang 
> ---
> Since v1:
>   - drop patch2 which tries to avoid link flapping when changing mtu
> I need more time on the change mtu refactoring.

Applied, thank you.

Re: [PATCH 6/7] ARM: s3c64xx: Switch to generic watchdog driver reset

[Krzysztof Kozlowski]

On Wed, Jul 29, 2020 at 07:33:33PM +0200, Tomasz Figa wrote:
> Hi Krzysztof,
> 
> 2020年7月29日(水) 18:11 Krzysztof Kozlowski :
> >
> > Similarly to commit f6361c6b3880 ("ARM: S3C24XX: remove separate restart
> > code"), the platform watchdog reset code can be removed in favor of
> > a generic watchdog driver which already handles reset.
> >
> > This allows removal of a bunch of machine code and fixes also W=1
> > compile warnings:
> >
> > arch/arm/plat-samsung/watchdog-reset.c:29:6: warning: no previous 
> > prototype for 'samsung_wdt_reset' [-Wmissing-prototypes]
> >29 | void samsung_wdt_reset(void)
> >   |  ^
> > arch/arm/plat-samsung/watchdog-reset.c:69:13: warning: no previous 
> > prototype for 'samsung_wdt_reset_of_init' [-Wmissing-prototypes]
> >69 | void __init samsung_wdt_reset_of_init(void)
> >   | ^
> > arch/arm/plat-samsung/watchdog-reset.c:89:13: warning: no previous 
> > prototype for 'samsung_wdt_reset_init' [-Wmissing-prototypes]
> >89 | void __init samsung_wdt_reset_init(void __iomem *base)
> >
> > Signed-off-by: Krzysztof Kozlowski 
> > ---
> >  arch/arm/mach-s3c64xx/Kconfig   |  3 +-
> >  arch/arm/mach-s3c64xx/common.c  | 15 +---
> >  arch/arm/mach-s3c64xx/common.h  |  2 -
> >  arch/arm/mach-s3c64xx/mach-anw6410.c|  1 -
> >  arch/arm/mach-s3c64xx/mach-crag6410.c   |  1 -
> >  arch/arm/mach-s3c64xx/mach-hmt.c|  1 -
> >  arch/arm/mach-s3c64xx/mach-mini6410.c   |  1 -
> >  arch/arm/mach-s3c64xx/mach-ncp.c|  1 -
> >  arch/arm/mach-s3c64xx/mach-real6410.c   |  1 -
> >  arch/arm/mach-s3c64xx/mach-s3c64xx-dt.c | 17 -
> >  arch/arm/mach-s3c64xx/mach-smartq5.c|  1 -
> >  arch/arm/mach-s3c64xx/mach-smartq7.c|  1 -
> >  arch/arm/mach-s3c64xx/mach-smdk6400.c   |  1 -
> >  arch/arm/mach-s3c64xx/mach-smdk6410.c   |  1 -
> >  arch/arm/mach-s3c64xx/watchdog-reset.h  | 16 -
> >  arch/arm/plat-samsung/Kconfig   |  6 --
> >  arch/arm/plat-samsung/Makefile  |  1 -
> >  arch/arm/plat-samsung/watchdog-reset.c  | 93 -
> >  18 files changed, 5 insertions(+), 158 deletions(-)
> >  delete mode 100644 arch/arm/mach-s3c64xx/watchdog-reset.h
> >  delete mode 100644 arch/arm/plat-samsung/watchdog-reset.c
> >
> 
> Thanks for the patch! Please see my comments inline.
> 
> > diff --git a/arch/arm/mach-s3c64xx/Kconfig b/arch/arm/mach-s3c64xx/Kconfig
> > index e208c2b48853..f3fcb570edf5 100644
> > --- a/arch/arm/mach-s3c64xx/Kconfig
> > +++ b/arch/arm/mach-s3c64xx/Kconfig
> > @@ -18,9 +18,10 @@ menuconfig ARCH_S3C64XX
> > select PM_GENERIC_DOMAINS if PM
> > select S3C_DEV_NAND if ATAGS
> > select S3C_GPIO_TRACK if ATAGS
> > +   select S3C2410_WATCHDOG
> > select SAMSUNG_ATAGS if ATAGS
> > select SAMSUNG_WAKEMASK if PM
> > -   select SAMSUNG_WDT_RESET
> > +   select WATCHDOG
> > help
> >   Samsung S3C64XX series based systems
> >
> > diff --git a/arch/arm/mach-s3c64xx/common.c b/arch/arm/mach-s3c64xx/common.c
> > index a655bf0c7802..42e96d196f61 100644
> > --- a/arch/arm/mach-s3c64xx/common.c
> > +++ b/arch/arm/mach-s3c64xx/common.c
> > @@ -50,7 +50,6 @@
> >
> >  #include "common.h"
> >  #include "irq-uart.h"
> > -#include "watchdog-reset.h"
> >
> >  /* External clock frequency */
> >  static unsigned long xtal_f __ro_after_init = 1200;
> > @@ -232,10 +231,11 @@ void __init s3c64xx_init_irq(u32 vic0_valid, u32 
> > vic1_valid)
> > /*
> >  * FIXME: there is no better place to put this at the moment
> >  * (s3c64xx_clk_init needs ioremap and must happen before init_time
> > -* samsung_wdt_reset_init needs clocks)
> > +* samsung_wdt_reset_init needs clocks).  However
> > +* samsung_wdt_reset_init() was removed in favor of watchdog driver
> > +* so this should be revised.
> 
> This leaves the comment referring to an inexistent function.

Yes, I left it as a reference/reason. Although might be quite confusing
now...

> 
> I wonder if this being here is actually a problem at all. It's legacy
> code and probably there isn't much value in reshuffling it further.
> Rather than that, we would probably want to make sure that everything
> migrated to DT and just drop the board files.

Maybe let's remove the FIXME and leave the clock init. Since all these
times no one fixed the FIXME, so now with limited hardware access I do
not expect any movements here.

> 
> >  */
> > s3c64xx_clk_init(NULL, xtal_f, xusbxti_f, soc_is_s3c6400(), 
> > S3C_VA_SYS);
> > -   samsung_wdt_reset_init(S3C_VA_WATCHDOG);
> >
> > printk(KERN_DEBUG "%s: initialising interrupts\n", __func__);
> >
> > @@ -429,12 +429,3 @@ static int __init s3c64xx_init_irq_eint(void)
> > return 0;
> >  }
> >  arch_initcall(s3c64xx_init_irq_eint);
> > -
> > -void s3c64xx_restart(enum reboot_mode mode, const char *cmd)
> 

[PATCH] nvme: Use spin_lock_irqsave() when taking the ctrl->lock

[Logan Gunthorpe]

When locking the ctrl->lock spinlock IRQs need to be disabled to avoid a
dead lock. The new spin_lock() calls recently added produce the
following lockdep warning when running the blktest nvme/003:


WARNING: inconsistent lock state

inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
ksoftirqd/2/22 [HC0[0]:SC1[1]:HE0:SE0] takes:
888276a8c4c0 (>lock){+.?.}-{2:2}, at: 
nvme_keep_alive_end_io+0x50/0xc0
{SOFTIRQ-ON-W} state was registered at:
  lock_acquire+0x164/0x500
  _raw_spin_lock+0x28/0x40
  nvme_get_effects_log+0x37/0x1c0
  nvme_init_identify+0x9e4/0x14f0
  nvme_reset_work+0xadd/0x2360
  process_one_work+0x66b/0xb70
  worker_thread+0x6e/0x6c0
  kthread+0x1e7/0x210
  ret_from_fork+0x22/0x30
irq event stamp: 1449221
hardirqs last  enabled at (1449220): [] 
ktime_get+0xf9/0x140
hardirqs last disabled at (1449221): [] 
_raw_spin_lock_irqsave+0x25/0x60
softirqs last  enabled at (1449210): [] 
__do_softirq+0x447/0x595
softirqs last disabled at (1449215): [] 
run_ksoftirqd+0x35/0x50

other info that might help us debug this:
 Possible unsafe locking scenario:

   CPU0
   
  lock(>lock);
  
lock(>lock);

 *** DEADLOCK ***

no locks held by ksoftirqd/2/22.

stack backtrace:
CPU: 2 PID: 22 Comm: ksoftirqd/2 Not tainted 
5.8.0-rc4-eid-vmlocalyes-dbg-00157-g7236657c6b3a #1450
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.12.0-1 04/01/2014
Call Trace:
 dump_stack+0xc8/0x11a
 print_usage_bug.cold.63+0x235/0x23e
 mark_lock+0xa9c/0xcf0
 __lock_acquire+0xd9a/0x2b50
 lock_acquire+0x164/0x500
 _raw_spin_lock_irqsave+0x40/0x60
 nvme_keep_alive_end_io+0x50/0xc0
 blk_mq_end_request+0x158/0x210
 nvme_complete_rq+0x146/0x500
 nvme_loop_complete_rq+0x26/0x30 [nvme_loop]
 blk_done_softirq+0x187/0x1e0
 __do_softirq+0x118/0x595
 run_ksoftirqd+0x35/0x50
 smpboot_thread_fn+0x1d3/0x310
 kthread+0x1e7/0x210
 ret_from_fork+0x22/0x30

Fixes: be93e87e7802 ("nvme: support for multiple Command Sets Supported and 
Effects log pages")
Signed-off-by: Logan Gunthorpe 
---

Note: this patch may be squashed with the patch noted in the fixes
tag, currently in nvme-5.9.

 drivers/nvme/host/core.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
index 05aa568a60af..ed8872022219 100644
--- a/drivers/nvme/host/core.c
+++ b/drivers/nvme/host/core.c
@@ -2971,15 +2971,16 @@ int nvme_get_log(struct nvme_ctrl *ctrl, u32 nsid, u8 
log_page, u8 lsp, u8 csi,
 static struct nvme_cel *nvme_find_cel(struct nvme_ctrl *ctrl, u8 csi)
 {
struct nvme_cel *cel, *ret = NULL;
+   unsigned long flags;

-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
list_for_each_entry(cel, >cels, entry) {
if (cel->csi == csi) {
ret = cel;
break;
}
}
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);

return ret;
 }
@@ -2988,6 +2989,7 @@ static int nvme_get_effects_log(struct nvme_ctrl *ctrl, 
u8 csi,
struct nvme_effects_log **log)
 {
struct nvme_cel *cel = nvme_find_cel(ctrl, csi);
+   unsigned long flags;
int ret;

if (cel)
@@ -3006,9 +3008,9 @@ static int nvme_get_effects_log(struct nvme_ctrl *ctrl, 
u8 csi,

cel->csi = csi;

-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
list_add_tail(>entry, >cels);
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 out:
*log = >log;
return 0;

base-commit: b6cec06d19d90db5dbcc50034fb33983f6259b8b
--
2.20.1

Re: 回复: INFO: rcu detected stall in tc_modify_qdisc

[Vinicius Costa Gomes]

Hi,

"Zhang, Qiang"  writes:

> 
> 发件人: linux-kernel-ow...@vger.kernel.org  
> 代表 syzbot 
> 发送时间: 2020年7月29日 13:53
> 收件人: da...@davemloft.net; fweis...@gmail.com; j...@mojatatu.com; 
> j...@resnulli.us; linux-kernel@vger.kernel.org; mi...@kernel.org; 
> net...@vger.kernel.org; syzkaller-b...@googlegroups.com; t...@linutronix.de; 
> vinicius.go...@intel.com; xiyou.wangc...@gmail.com
> 主题: INFO: rcu detected stall in tc_modify_qdisc
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:181964e6 fix a braino in cmsghdr_from_user_compat_to_kern()
> git tree:   net
> console output: https://syzkaller.appspot.com/x/log.txt?x=12925e3890
> kernel config:  https://syzkaller.appspot.com/x/.config?x=f87a5e4232fdb267
> dashboard link: https://syzkaller.appspot.com/bug?extid=9f78d5c664a8c33f4cce
> compiler:   gcc (GCC) 10.1.0-syz 20200507
> syz repro:
> https://syzkaller.appspot.com/x/repro.syz?x=16587f8c90

It seems that syzkaller is generating an schedule with too small
intervals (3ns in this case) which causes a hrtimer busy-loop which
starves other kernel threads.

We could put some limits on the interval when running in software mode,
but I don't like this too much, because we are talking about users with
CAP_NET_ADMIN and they have easier ways to do bad things to the system.


Cheers,
-- 
Vinicius

Re: [PATCH v3 12/19] firmware_loader: Use security_post_load_data()

[Kees Cook]

On Wed, Jul 29, 2020 at 02:10:18PM -0400, Mimi Zohar wrote:
> Actually, the partial firmware read should be calling
> security_kernel_read_file().

Yup, it does[1], and when "whole_file" is true, it will call
security_kernel_post_read_file() with the buffer contents at the end.

> The sysfs firmware fallback is calling security_kernel_load_data().

Correct[2]; it has no file associated with it (same as the EFI platform
source).

> Which firmware is calling security_kernel_post_load_data()?

sysfs and platform both call it[2], matched with their
security_kernel_load_data() calls.

-Kees


[1] v4 patch 14: "fs/kernel_file_read: Add "offset" arg for partial reads"

https://lore.kernel.org/lkml/20200729175845.1745471-1-keesc...@chromium.org/T/#iZ2e.:..:20200729175845.1745471-15-keescook::40chromium.org:0fs:kernel_read_file.c
[2] v4 patch 10: "firmware_loader: Use security_post_load_data()"

https://lore.kernel.org/lkml/20200729175845.1745471-1-keesc...@chromium.org/T/#iZ2e.:..:20200729175845.1745471-11-keescook::40chromium.org:0drivers:base:firmware_loader:fallback.c

-- 
Kees Cook

[PATCH v2] lib: kunit: Convert test_sort to KUnit test

[Vitor Massaru Iha]

This adds the conversion of the test_sort.c to KUnit test.

Please apply this commit first (linux-kselftest/kunit-fixes):
3f37d14b8a3152441f36b6bc74000996679f0998 kunit: kunit_config: Fix parsing of 
CONFIG options with space

Code Style Documentation: [0]

Fix these warnings Reported-by l...@intel.com

WARNING: modpost: vmlinux.o(.data+0x4fc70): Section mismatch in reference from 
the variable sort_test_cases to the variable .init.text:sort_test
   The variable sort_test_cases references
   the variable __init sort_test
   If the reference is valid then annotate the
   variable with or __refdata (see linux/init.h) or name the variable

WARNING: modpost: lib/sort_kunit.o(.data+0x11c): Section mismatch in reference 
from the variable sort_test_cases to the function .init.text:sort_test()
   The variable sort_test_cases references
   the function __init sort_test()

Signed-off-by: Vitor Massaru Iha 
Reported-by: kernel test robot 
Link: [0] 
https://lore.kernel.org/linux-kselftest/20200620054944.167330-1-david...@google.com/T/#u
---
v2:
* Add Kunit Code Style reference in commit message;
* Fix l...@intel.com warning report;
---
 lib/Kconfig.debug | 26 +-
 lib/Makefile  |  2 +-
 lib/{test_sort.c => sort_kunit.c} | 31 +++
 3 files changed, 33 insertions(+), 26 deletions(-)
 rename lib/{test_sort.c => sort_kunit.c} (55%)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 9ad9210d70a1..1fe19e78d7ca 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1874,15 +1874,6 @@ config TEST_MIN_HEAP

  If unsure, say N.

-config TEST_SORT
-   tristate "Array-based sort test"
-   depends on DEBUG_KERNEL || m
-   help
- This option enables the self-test function of 'sort()' at boot,
- or at module load time.
-
- If unsure, say N.
-
 config KPROBES_SANITY_TEST
bool "Kprobes sanity tests"
depends on DEBUG_KERNEL
@@ -2185,6 +2176,23 @@ config LINEAR_RANGES_TEST

  If unsure, say N.

+config SORT_KUNIT
+   tristate "KUnit test for Array-based sort"
+   depends on DEBUG_KERNEL || m
+   help
+ This option enables the KUnit function of 'sort()' at boot,
+ or at module load time.
+
+ KUnit tests run during boot and output the results to the debug log
+ in TAP format (http://testanything.org/). Only useful for kernel devs
+ running the KUnit test harness, and not intended for inclusion into a
+ production build.
+
+ For more information on KUnit and unit tests in general please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit/.
+
+ If unsure, say N.
+
 config TEST_UDELAY
tristate "udelay test driver"
help
diff --git a/lib/Makefile b/lib/Makefile
index b1c42c10073b..c22bb13b0a08 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -77,7 +77,6 @@ obj-$(CONFIG_TEST_LKM) += test_module.o
 obj-$(CONFIG_TEST_VMALLOC) += test_vmalloc.o
 obj-$(CONFIG_TEST_OVERFLOW) += test_overflow.o
 obj-$(CONFIG_TEST_RHASHTABLE) += test_rhashtable.o
-obj-$(CONFIG_TEST_SORT) += test_sort.o
 obj-$(CONFIG_TEST_USER_COPY) += test_user_copy.o
 obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_keys.o
 obj-$(CONFIG_TEST_STATIC_KEYS) += test_static_key_base.o
@@ -318,3 +317,4 @@ obj-$(CONFIG_OBJAGG) += objagg.o
 # KUnit tests
 obj-$(CONFIG_LIST_KUNIT_TEST) += list-test.o
 obj-$(CONFIG_LINEAR_RANGES_TEST) += test_linear_ranges.o
+obj-$(CONFIG_SORT_KUNIT) += sort_kunit.o
diff --git a/lib/test_sort.c b/lib/sort_kunit.c
similarity index 55%
rename from lib/test_sort.c
rename to lib/sort_kunit.c
index 52edbe10f2e5..602a234f1e7d 100644
--- a/lib/test_sort.c
+++ b/lib/sort_kunit.c
@@ -1,7 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 #include 
-#include 
-#include 
+#include 

 /* a simple boot-time regression test */

@@ -12,13 +11,12 @@ static int __init cmpint(const void *a, const void *b)
return *(int *)a - *(int *)b;
 }

-static int __init test_sort_init(void)
+static void __init sort_test(struct kunit *test)
 {
-   int *a, i, r = 1, err = -ENOMEM;
+   int *a, i, r = 1;

a = kmalloc_array(TEST_LEN, sizeof(*a), GFP_KERNEL);
-   if (!a)
-   return err;
+   KUNIT_ASSERT_FALSE_MSG(test, a == NULL, "kmalloc_array failed");

for (i = 0; i < TEST_LEN; i++) {
r = (r * 725861) % 6599;
@@ -27,24 +25,25 @@ static int __init test_sort_init(void)

sort(a, TEST_LEN, sizeof(*a), cmpint, NULL);

-   err = -EINVAL;
for (i = 0; i < TEST_LEN-1; i++)
if (a[i] > a[i+1]) {
-   pr_err("test has failed\n");
+   KUNIT_FAIL(test, "test has failed");
goto exit;
}
-   err = 0;
-   pr_info("test passed\n");
 exit:
kfree(a);
-   return err;
 }

-static void __exit test_sort_exit(void)
-{
-}
+static struct 

[PATCH] nvmet-passthru: Reject commands with non-sgl flags set

[Logan Gunthorpe]

Any command with a non-SGL flag set (like fuse flags) should be
rejected.

Fixes: c1fef73f793b ("nvmet: add passthru code to process commands")
Signed-off-by: Logan Gunthorpe 
---

Note: this patch may be squashed with the patch noted in the fixes
tag, currently in nvme-5.9.

 drivers/nvme/target/passthru.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/nvme/target/passthru.c b/drivers/nvme/target/passthru.c
index 89d91dc999a6..f69c3ac82e58 100644
--- a/drivers/nvme/target/passthru.c
+++ b/drivers/nvme/target/passthru.c
@@ -326,6 +326,10 @@ static u16 nvmet_setup_passthru_command(struct nvmet_req 
*req)

 u16 nvmet_parse_passthru_io_cmd(struct nvmet_req *req)
 {
+   /* Reject any commands with non-sgl flags set (ie. fused commands) */
+   if (req->cmd->common.flags & ~NVME_CMD_SGL_ALL)
+   return NVME_SC_INVALID_FIELD;
+
switch (req->cmd->common.opcode) {
case nvme_cmd_resv_register:
case nvme_cmd_resv_report:
@@ -396,6 +400,10 @@ static u16 nvmet_passthru_get_set_features(struct 
nvmet_req *req)

 u16 nvmet_parse_passthru_admin_cmd(struct nvmet_req *req)
 {
+   /* Reject any commands with non-sgl flags set (ie. fused commands) */
+   if (req->cmd->common.flags & ~NVME_CMD_SGL_ALL)
+   return NVME_SC_INVALID_FIELD;
+
/*
 * Passthru all vendor specific commands
 */

base-commit: b6cec06d19d90db5dbcc50034fb33983f6259b8b
--
2.20.1

Re: [PATCH] drm/vkms: add missing drm_crtc_vblank_put to the get/put pair on flush

[Melissa Wen]

Melissa Wen

On Sat, Jul 25, 2020 at 3:12 PM Daniel Vetter  wrote:
>
> On Sat, Jul 25, 2020 at 7:45 PM Melissa Wen  wrote:
> >
> > On 07/25, Daniel Vetter wrote:
> > > On Sat, Jul 25, 2020 at 5:12 AM Sidong Yang  wrote:
> > > >
> > > > On Wed, Jul 22, 2020 at 05:17:05PM +0200, Daniel Vetter wrote:
> > > > > On Wed, Jul 22, 2020 at 4:06 PM Melissa Wen  
> > > > > wrote:
> > > > > >
> > > > > > On 07/22, dan...@ffwll.ch wrote:
> > > > > > > On Wed, Jul 22, 2020 at 08:04:11AM -0300, Melissa Wen wrote:
> > > > > > > > This patch adds a missing drm_crtc_vblank_put op to the pair
> > > > > > > > drm_crtc_vblank_get/put (inc/decrement counter to guarantee 
> > > > > > > > vblanks).
> > > > > > > >
> > > > > > > > It clears the execution of the following kms_cursor_crc 
> > > > > > > > subtests:
> > > > > > > > 1. pipe-A-cursor-[size,alpha-opaque, NxN-(on-screen, 
> > > > > > > > off-screen, sliding,
> > > > > > > >random, fast-moving])] - successful when running 
> > > > > > > > individually.
> > > > > > > > 2. pipe-A-cursor-dpms passes again
> > > > > > > > 3. pipe-A-cursor-suspend also passes
> > > > > > > >
> > > > > > > > The issue was initially tracked in the sequential execution of 
> > > > > > > > IGT
> > > > > > > > kms_cursor_crc subtest: when running the test sequence or one 
> > > > > > > > of its
> > > > > > > > subtests twice, the odd execs complete and the pairs get stuck 
> > > > > > > > in an
> > > > > > > > endless wait. In the IGT code, calling a wait_for_vblank before 
> > > > > > > > the start
> > > > > > > > of CRC capture prevented the busy-wait. But the problem 
> > > > > > > > persisted in the
> > > > > > > > pipe-A-cursor-dpms and -suspend subtests.
> > > > > > > >
> > > > > > > > Checking the history, the pipe-A-cursor-dpms subtest was 
> > > > > > > > successful when,
> > > > > > > > in vkms_atomic_commit_tail, instead of using the flip_done op, 
> > > > > > > > it used
> > > > > > > > wait_for_vblanks. Another way to prevent blocking was 
> > > > > > > > wait_one_vblank when
> > > > > > > > enabling crtc. However, in both cases, pipe-A-cursor-suspend 
> > > > > > > > persisted
> > > > > > > > blocking in the 2nd start of CRC capture, which may indicate 
> > > > > > > > that
> > > > > > > > something got stuck in the step of CRC setup. Indeed, 
> > > > > > > > wait_one_vblank in
> > > > > > > > the crc setup was able to sync things and free all 
> > > > > > > > kms_cursor_crc
> > > > > > > > subtests.
> > > > > > > >
> > > > > > > > Tracing and comparing a clean run with a blocked one:
> > > > > > > > - in a clean one, vkms_crtc_atomic_flush enables vblanks;
> > > > > > > > - when blocked, only in next op, vkms_crtc_atomic_enable, the 
> > > > > > > > vblanks
> > > > > > > > started. Moreover, a series of vkms_vblank_simulate flow out 
> > > > > > > > until
> > > > > > > > disabling vblanks.
> > > > > > > > Also watching the steps of vkms_crtc_atomic_flush, when the 
> > > > > > > > very first
> > > > > > > > drm_crtc_vblank_get returned an error, the subtest crashed. On 
> > > > > > > > the other
> > > > > > > > hand, when vblank_get succeeded, the subtest completed. 
> > > > > > > > Finally, checking
> > > > > > > > the flush steps: it increases counter to hold a vblank 
> > > > > > > > reference (get),
> > > > > > > > but there isn't a op to decreased it and release vblanks (put).
> > > > > > > >
> > > > > > > > Cc: Daniel Vetter 
> > > > > > > > Cc: Rodrigo Siqueira 
> > > > > > > > Cc: Haneen Mohammed 
> > > > > > > > Signed-off-by: Melissa Wen 
> > > > > > > > ---
> > > > > > > >  drivers/gpu/drm/vkms/vkms_crtc.c | 1 +
> > > > > > > >  1 file changed, 1 insertion(+)
> > > > > > > >
> > > > > > > > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c 
> > > > > > > > b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > > > > > index ac85e17428f8..a99d6b4a92dd 100644
> > > > > > > > --- a/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > > > > > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c
> > > > > > > > @@ -246,6 +246,7 @@ static void vkms_crtc_atomic_flush(struct 
> > > > > > > > drm_crtc *crtc,
> > > > > > > >
> > > > > > > > spin_unlock(>dev->event_lock);
> > > > > > > >
> > > > > > > > +   drm_crtc_vblank_put(crtc);
> > > > > > >
> > > > > > > Uh so I reviewed this a bit more carefully now, and I dont think 
> > > > > > > this is
> > > > > > > the correct bugfix. From the kerneldoc of 
> > > > > > > drm_crtc_arm_vblank_event():
> > > > > > >
> > > > > > >  * Caller must hold a vblank reference for the event @e acquired 
> > > > > > > by a
> > > > > > >  * drm_crtc_vblank_get(), which will be dropped when the next 
> > > > > > > vblank arrives.
> > > > > > >
> > > > > > > So when we call drm_crtc_arm_vblank_event then the vblank_put 
> > > > > > > gets called
> > > > > > > for us. And that's the only case where we successfully acquired a 
> > > > > > > vblank
> > > > > > > interrupt reference since on failure of drm_crtc_vblank_get (0 
> > > > > > > indicates
> > > > > > > success for 

Re: [PATCH 5/7] ARM: samsung: Kill useless HAVE_S3C2410_WATCHDOG

[Krzysztof Kozlowski]

On Wed, Jul 29, 2020 at 07:36:38PM +0200, Tomasz Figa wrote:
> 2020年7月29日(水) 19:02 Guenter Roeck :
> >
> > On Wed, Jul 29, 2020 at 06:09:40PM +0200, Krzysztof Kozlowski wrote:
> > > A separate Kconfig option HAVE_S3C2410_WATCHDOG for Samsung SoCs does
> > > not have sense, because:
> > > 1. All ARMv7 and ARMv8 Samsung SoCs have watchdog,
> > > 2. All architecture Kconfigs were selecting it (if WATCHDOG framework is
> > >chosen),
> > > 3. HAVE_S3C2410_WATCHDOG is doing nothing except being a dependency of
> > >actual Samsung SoC watchdog driver, which is enabled manually by
> > >specific defconfigs.
> > >
> > > HAVE_S3C2410_WATCHDOG can be safely removed.
> > >
> >
> > That is not really correct. HAVE_S3C2410_WATCHDOG is used to ensure
> > that users can only enable S3C2410_WATCHDOG if the watchdog actually
> > exists in a system. With this change, it can be enabled for all
> > architectures and platforms.
> >
> > NACK.
> >
> > Guenter
> >
> 
> I'd side with Guenter on this. We better not flood users' screens with
> options that are not relevant to their hardware.
> 
> An alternative here could be making CONFIG_S3C2410_WATCHDOG depend on
> a general symbol for Samsung SoC support if there is such, but then,
> are we 100% sure that all the Samsung SoCs would actually have exactly
> this watchdog? If a new one shows up, one would have to bring back
> this HAVE_S3C2410_WATCHDOG symbol.

Ah, good points. Indeed for all of such SoC drivers we usually just
depend on architecture to limit the choices on other architectures.
In this case it would be:
depends on ARCH_EXYNOS || ARCH_S3C24XX || ARCH_S3C64XX || ARCH_S5PV210 || 
COMPILE_TEST

I admit it is pretty long, but we already use this pattern. In shorter
version (less ARCH*) for all drivers, in full version also in:
drivers/iio/adc/Kconfig
drivers/gpu/drm/exynos/Kconfig

Have in mind that in general we follow the first approach and only three
drivers have still the HAVE_xxx option (also HAVE_S3C2410_I2C and
HAVE_S3C_RTC).

I can update therefore the "depends" while removing the
HAVE_S3C2410_WATCHDOG option or just keep it.

Best regards,
Krzysztof

Re: [PATCH 3/7] ARM: s3c: Remove plat-samsung/.../samsung-time.h

[Krzysztof Kozlowski]

On Wed, Jul 29, 2020 at 07:49:02PM +0200, Tomasz Figa wrote:
> 2020年7月29日(水) 18:11 Krzysztof Kozlowski :
> >
> > Remove the arch/arm/plat-samsung/include/plat/samsung-time.h header and
> > move the contents to common.h headers in mach-s3c24xx and mach-s3c64xx.
> > The definition of declared functions is already in common.c in mach
> > directories, so it is logically to put declaration next to them.
> >
> > This is also one step further towards removal of plat-samsung directory
> > and it fixes W=1 build warnings:
> >
> > arch/arm/mach-s3c64xx/common.c:174:13: warning:
> > no previous prototype for 'samsung_set_timer_source' 
> > [-Wmissing-prototypes]
> >   174 | void __init samsung_set_timer_source(unsigned int event, 
> > unsigned int source)
> >
> > arch/arm/mach-s3c64xx/common.c:180:13: warning:
> > no previous prototype for 'samsung_timer_init' 
> > [-Wmissing-prototypes]
> >   180 | void __init samsung_timer_init(void)
> >
> > Signed-off-by: Krzysztof Kozlowski 
> > ---
> >  arch/arm/mach-s3c24xx/common.h| 12 +
> >  arch/arm/mach-s3c24xx/mach-amlm5900.c |  2 --
> >  arch/arm/mach-s3c24xx/mach-anubis.c   |  1 -
> >  arch/arm/mach-s3c24xx/mach-at2440evb.c|  1 -
> >  arch/arm/mach-s3c24xx/mach-bast.c |  1 -
> >  arch/arm/mach-s3c24xx/mach-gta02.c|  1 -
> >  arch/arm/mach-s3c24xx/mach-h1940.c|  1 -
> >  arch/arm/mach-s3c24xx/mach-jive.c |  1 -
> >  arch/arm/mach-s3c24xx/mach-mini2440.c |  1 -
> >  arch/arm/mach-s3c24xx/mach-n30.c  |  1 -
> >  arch/arm/mach-s3c24xx/mach-nexcoder.c |  1 -
> >  arch/arm/mach-s3c24xx/mach-osiris.c   |  1 -
> >  arch/arm/mach-s3c24xx/mach-otom.c |  1 -
> >  arch/arm/mach-s3c24xx/mach-qt2410.c   |  1 -
> >  arch/arm/mach-s3c24xx/mach-rx1950.c   |  1 -
> >  arch/arm/mach-s3c24xx/mach-rx3715.c   |  1 -
> >  arch/arm/mach-s3c24xx/mach-smdk2410.c |  1 -
> >  arch/arm/mach-s3c24xx/mach-smdk2413.c |  1 -
> >  arch/arm/mach-s3c24xx/mach-smdk2416.c |  1 -
> >  arch/arm/mach-s3c24xx/mach-smdk2440.c |  1 -
> >  arch/arm/mach-s3c24xx/mach-smdk2443.c |  1 -
> >  arch/arm/mach-s3c24xx/mach-tct_hammer.c   |  1 -
> >  arch/arm/mach-s3c24xx/mach-vr1000.c   |  1 -
> >  arch/arm/mach-s3c24xx/mach-vstms.c|  1 -
> >  arch/arm/mach-s3c64xx/common.h| 13 ++
> >  arch/arm/mach-s3c64xx/mach-anw6410.c  |  1 -
> >  arch/arm/mach-s3c64xx/mach-crag6410.c |  1 -
> >  arch/arm/mach-s3c64xx/mach-hmt.c  |  1 -
> >  arch/arm/mach-s3c64xx/mach-mini6410.c |  1 -
> >  arch/arm/mach-s3c64xx/mach-ncp.c  |  1 -
> >  arch/arm/mach-s3c64xx/mach-real6410.c |  1 -
> >  arch/arm/mach-s3c64xx/mach-smartq.c   |  1 -
> >  arch/arm/mach-s3c64xx/mach-smartq5.c  |  1 -
> >  arch/arm/mach-s3c64xx/mach-smartq7.c  |  1 -
> >  arch/arm/mach-s3c64xx/mach-smdk6400.c |  1 -
> >  arch/arm/mach-s3c64xx/mach-smdk6410.c |  1 -
> >  .../plat-samsung/include/plat/samsung-time.h  | 26 ---
> >  37 files changed, 25 insertions(+), 61 deletions(-)
> >  delete mode 100644 arch/arm/plat-samsung/include/plat/samsung-time.h
> >
> 
> For the s3c64xx bits:
> 
> Reviewed-by: Tomasz Figa 
> 
> I suppose the next step would be renaming those functions to s3c24xx_*
> and s3c64xx_* to avoid naming collisions?

That's a good point. I will send a follow up patch. Thanks!

Best regards,
Krzysztof

Re: [PATCH] net/mlx5e: fix bpf_prog refcnt leaks in mlx5e_alloc_rq

[Saeed Mahameed]

On Wed, 2020-07-29 at 20:33 +0800, Xin Xiong wrote:
> The function invokes bpf_prog_inc(), which increases the refcount of
> a
> bpf_prog object "rq->xdp_prog" if the object isn't NULL.
> 
> The refcount leak issues take place in two error handling paths. When
> mlx5_wq_ll_create() or mlx5_wq_cyc_create() fails, the function
> simply
> returns the error code and forgets to drop the refcount increased
> earlier, causing a refcount leak of "rq->xdp_prog".
> 
> Fix this issue by jumping to the error handling path
> err_rq_wq_destroy
> when either function fails.
> 

Fixes: 422d4c401edd ("net/mlx5e: RX, Split WQ objects for different RQ
types")

> 
> Signed-off-by: Xin Xiong 
> Signed-off-by: Xiyu Yang 
> Signed-off-by: Xin Tan 
> ---
>  drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> index a836a02a2116..8e1b1ab416d8 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
> @@ -419,7 +419,7 @@ static int mlx5e_alloc_rq(struct mlx5e_channel
> *c,
>   err = mlx5_wq_ll_create(mdev, >wq, rqc_wq, 
> >mpwqe.wq,
>   >wq_ctrl);
>   if (err)
> - return err;
> + goto err_rq_wq_destroy;
>  
>   rq->mpwqe.wq.db = >mpwqe.wq.db[MLX5_RCV_DBR];
>  
> @@ -470,7 +470,7 @@ static int mlx5e_alloc_rq(struct mlx5e_channel
> *c,
>   err = mlx5_wq_cyc_create(mdev, >wq, rqc_wq, 
> >wqe.wq,
>>wq_ctrl);
>   if (err)
> - return err;
> + goto err_rq_wq_destroy;
>  
>   rq->wqe.wq.db = >wqe.wq.db[MLX5_RCV_DBR];
>  

Re: [PATCH ghak90 V9 06/13] audit: add contid support for signalling the audit daemon

[Richard Guy Briggs]

On 2020-07-05 11:10, Paul Moore wrote:
> On Sat, Jun 27, 2020 at 9:22 AM Richard Guy Briggs  wrote:
> >
> > Add audit container identifier support to the action of signalling the
> > audit daemon.
> >
> > Since this would need to add an element to the audit_sig_info struct,
> > a new record type AUDIT_SIGNAL_INFO2 was created with a new
> > audit_sig_info2 struct.  Corresponding support is required in the
> > userspace code to reflect the new record request and reply type.
> > An older userspace won't break since it won't know to request this
> > record type.
> >
> > Signed-off-by: Richard Guy Briggs 
> > ---
> >  include/linux/audit.h   |  8 
> >  include/uapi/linux/audit.h  |  1 +
> >  kernel/audit.c  | 95 
> > -
> >  security/selinux/nlmsgtab.c |  1 +
> >  4 files changed, 104 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index 5eeba0efffc2..89cf7c66abe6 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -22,6 +22,13 @@ struct audit_sig_info {
> > charctx[];
> >  };
> >
> > +struct audit_sig_info2 {
> > +   uid_t   uid;
> > +   pid_t   pid;
> > +   u32 cid_len;
> > +   chardata[];
> > +};
> > +
> >  struct audit_buffer;
> >  struct audit_context;
> >  struct inode;
> > @@ -105,6 +112,7 @@ struct audit_contobj {
> > u64 id;
> > struct task_struct  *owner;
> > refcount_t  refcount;
> > +   refcount_t  sigflag;
> > struct rcu_head rcu;
> >  };
> 
> It seems like we need some protection in audit_set_contid() so that we
> don't allow reuse of an audit container ID when "refcount == 0 &&
> sigflag != 0", yes?

We have it, see -ESHUTDOWN below.

> > diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
> > index fd98460c983f..a56ad77069b9 100644
> > --- a/include/uapi/linux/audit.h
> > +++ b/include/uapi/linux/audit.h
> > @@ -72,6 +72,7 @@
> >  #define AUDIT_SET_FEATURE  1018/* Turn an audit feature on or off 
> > */
> >  #define AUDIT_GET_FEATURE  1019/* Get which features are enabled */
> >  #define AUDIT_CONTAINER_OP 1020/* Define the container id and info 
> > */
> > +#define AUDIT_SIGNAL_INFO2 1021/* Get info auditd signal sender */
> >
> >  #define AUDIT_FIRST_USER_MSG   1100/* Userspace messages mostly 
> > uninteresting to kernel */
> >  #define AUDIT_USER_AVC 1107/* We filter this differently */
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index a09f8f661234..54dd2cb69402 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -126,6 +126,8 @@ struct auditd_connection {
> >  kuid_t audit_sig_uid = INVALID_UID;
> >  pid_t  audit_sig_pid = -1;
> >  u32audit_sig_sid = 0;
> > +static struct audit_contobj *audit_sig_cid;
> > +static struct task_struct *audit_sig_atsk;
> 
> This looks like a typo, or did you mean "atsk" for some reason?

No, I meant atsk to refer specifically to the audit daemon task and not
any other random one that is doing the signalling.  I can change it is
there is a strong objection.

> >  /* Records can be lost in several ways:
> > 0) [suppressed in audit_alloc]
> > @@ -239,7 +241,33 @@ void _audit_contobj_put(struct audit_contobj *cont)
> >  {
> > if (!cont)
> > return;
> > -   if (refcount_dec_and_test(>refcount)) {
> > +   if (refcount_dec_and_test(>refcount) && 
> > !refcount_read(>sigflag)) {
> > +   put_task_struct(cont->owner);
> > +   list_del_rcu(>list);
> > +   kfree_rcu(cont, rcu);
> > +   }
> > +}
> 
> It seems like it might be a good idea to modify the corresponding
> _get() to WARN on the reuse of audit container objects where refcount
> is zero, similar to the comment I made above.  What do you think?

This will never happen.  See -ESHUTDOWN below.

> > +/* rcu_read_lock must be held by caller unless new */
> > +static struct audit_contobj *_audit_contobj_get_sig(struct task_struct 
> > *tsk)
> > +{
> > +   struct audit_contobj *cont;
> > +
> > +   if (!tsk->audit)
> > +   return NULL;
> > +   cont = tsk->audit->cont;
> > +   if (cont)
> > +   refcount_set(>sigflag, 1);
> > +   return cont;
> > +}
> 
> If you are going to use a refcount and call this a "get" function you
> might as well make it do an increment and not just a set(1).  It a bit
> silly with just one auditd per system, but I suppose it will make more
> sense when we have multiple audit daemons.  In a related comment, you
> probably want to rename "sigflag" to "sigcount" or similar.

I preferred that previously.  I'll go back to that.

> In summary, it's either a reference that supports multiple gets/puts
> or it's a flag with just an on/off; it shouldn't attempt to straddle

Re: [PATCH v2 4/5] perf record: Don't clear event's period if set by a term

[Arnaldo Carvalho de Melo]

Em Tue, Jul 28, 2020 at 01:57:33AM -0700, Ian Rogers escreveu:
> If events in a group explicitly set a frequency or period with leader
> sampling, don't disable the samples on those events.
> 
> Prior to 5.8:
> perf record -e '{cycles/period=12345000/,instructions/period=6789000/}:S'
> would clear the attributes then apply the config terms. In commit
> 5f34278867b7 leader sampling configuration was moved to after applying the
> config terms, in the example, making the instructions' event have its period
> cleared.
> This change makes it so that sampling is only disabled if configuration
> terms aren't present.

Adrian, can you take a look at this one?

- Arnaldo
 
> Fixes: 5f34278867b7 ("perf evlist: Move leader-sampling configuration")
> Signed-off-by: Ian Rogers 
> ---
>  tools/perf/util/record.c | 28 
>  1 file changed, 20 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/perf/util/record.c b/tools/perf/util/record.c
> index a4cc11592f6b..01d1c6c613f7 100644
> --- a/tools/perf/util/record.c
> +++ b/tools/perf/util/record.c
> @@ -2,6 +2,7 @@
>  #include "debug.h"
>  #include "evlist.h"
>  #include "evsel.h"
> +#include "evsel_config.h"
>  #include "parse-events.h"
>  #include 
>  #include 
> @@ -38,6 +39,9 @@ static void evsel__config_leader_sampling(struct evsel 
> *evsel, struct evlist *ev
>   struct perf_event_attr *attr = >core.attr;
>   struct evsel *leader = evsel->leader;
>   struct evsel *read_sampler;
> + struct evsel_config_term *term;
> + struct list_head *config_terms = >config_terms;
> + int term_types, freq_mask;
>  
>   if (!leader->sample_read)
>   return;
> @@ -47,16 +51,24 @@ static void evsel__config_leader_sampling(struct evsel 
> *evsel, struct evlist *ev
>   if (evsel == read_sampler)
>   return;
>  
> + /* Determine the evsel's config term types. */
> + term_types = 0;
> + list_for_each_entry(term, config_terms, list) {
> + term_types |= 1 << term->type;
> + }
>   /*
> -  * Disable sampling for all group members other than the leader in
> -  * case the leader 'leads' the sampling, except when the leader is an
> -  * AUX area event, in which case the 2nd event in the group is the one
> -  * that 'leads' the sampling.
> +  * Disable sampling for all group members except those with explicit
> +  * config terms or the leader. In the case of an AUX area event, the 2nd
> +  * event in the group is the one that 'leads' the sampling.
>*/
> - attr->freq   = 0;
> - attr->sample_freq= 0;
> - attr->sample_period  = 0;
> - attr->write_backward = 0;
> + freq_mask = (1 << EVSEL__CONFIG_TERM_FREQ) | (1 << 
> EVSEL__CONFIG_TERM_PERIOD);
> + if ((term_types & freq_mask) == 0) {
> + attr->freq   = 0;
> + attr->sample_freq= 0;
> + attr->sample_period  = 0;
> + }
> + if ((term_types & (1 << EVSEL__CONFIG_TERM_OVERWRITE)) == 0)
> + attr->write_backward = 0;
>  
>   /*
>* We don't get a sample for slave events, we make them when delivering
> -- 
> 2.28.0.163.g6104cc2f0b6-goog
> 

-- 

- Arnaldo

Re: [PATCH 1/2] PCI: dwc: Add support to handle prefetchable memory separately

[Rob Herring]

On Tue, Jun 02, 2020 at 03:39:39PM +0530, Vidya Sagar wrote:
> Add required structure members to struct pcie_port to handle prefetchable
> memory aperture separately from non-prefetchable memory aperture so that
> any dependency on the order of their appearance in the 'ranges' property
> of the respective PCIe device tree node can be removed.
> 
> Signed-off-by: Vidya Sagar 
> ---
>  .../pci/controller/dwc/pcie-designware-host.c | 26 ---
>  drivers/pci/controller/dwc/pcie-designware.h  |  4 +++
>  2 files changed, 21 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c 
> b/drivers/pci/controller/dwc/pcie-designware-host.c
> index 42fbfe2a1b8f..6f06d6bd9f00 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> @@ -363,13 +363,23 @@ int dw_pcie_host_init(struct pcie_port *pp)
>   pp->io_base = pci_pio_to_address(pp->io->start);
>   break;
>   case IORESOURCE_MEM:
> - pp->mem = win->res;
> - pp->mem->name = "MEM";
> - mem_size = resource_size(pp->mem);
> - if (upper_32_bits(mem_size))
> - dev_warn(dev, "MEM resource size exceeds max 
> for 32 bits\n");
> - pp->mem_size = mem_size;
> - pp->mem_bus_addr = pp->mem->start - win->offset;
> + if (win->res->flags & IORESOURCE_PREFETCH) {
> + pp->prefetch = win->res;
> + pp->prefetch->name = "PREFETCH";
> + pp->prefetch_base = pp->prefetch->start;
> + pp->prefetch_size = resource_size(pp->prefetch);
> + pp->perfetch_bus_addr = pp->prefetch->start -
> + win->offset;
> + } else {
> + pp->mem = win->res;
> + pp->mem->name = "MEM";
> + pp->mem_base = pp->mem->start;
> + mem_size = resource_size(pp->mem);
> + if (upper_32_bits(mem_size))
> + dev_warn(dev, "MEM resource size 
> exceeds max for 32 bits\n");
> + pp->mem_size = mem_size;
> + pp->mem_bus_addr = pp->mem->start - win->offset;
> + }
>   break;
>   case 0:
>   pp->cfg = win->res;
> @@ -394,8 +404,6 @@ int dw_pcie_host_init(struct pcie_port *pp)
>   }
>   }
>  
> - pp->mem_base = pp->mem->start;
> -
>   if (!pp->va_cfg0_base) {
>   pp->va_cfg0_base = devm_pci_remap_cfgspace(dev,
>   pp->cfg0_base, pp->cfg0_size);
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h 
> b/drivers/pci/controller/dwc/pcie-designware.h
> index 656e00f8fbeb..c87c1b2a1177 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -186,9 +186,13 @@ struct pcie_port {
>   u64 mem_base;
>   phys_addr_t mem_bus_addr;
>   u32 mem_size;
> + u64 prefetch_base;
> + phys_addr_t perfetch_bus_addr;
> + u64 prefetch_size;

There's no reason to store these for all eternity as they are used in 
one place and already stored as resources in bridge->windows.

I have a patch series removing most of this that I will post in a few 
days. There's a WIP branch, pci-dw-config-access, in my kernel.org 
tree. Mostly you just need the bridge ptr which is isn't currently 
saved in pcie_port.

Rob

Re: [PATCH v2 2/5] perf record: Prevent override of attr->sample_period for libpfm4 events

[Arnaldo Carvalho de Melo]

Em Tue, Jul 28, 2020 at 01:57:31AM -0700, Ian Rogers escreveu:
> From: Stephane Eranian 
> 
> Before:
> $ perf record -c 1 --pfm-events=cycles:period=7
> 
> Would yield a cycles event with period=1, instead of 7.

I tried the equivalent without libpfm and it works:

  $ perf record -c 1 -e cycles/period=2/ sleep 1
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.024 MB perf.data (23 samples) ]
  $ perf evlist -v
  cycles/period=2/u: size: 120, { sample_period, sample_freq }: 2, 
sample_type: IP|TID|TIME, read_format: ID, disabled: 1, inherit: 1, 
exclude_kernel: 1, exclude_hv: 1, mmap: 1, comm: 1, enable_on_exec: 1, task: 1, 
sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, ksymbol: 1, 
bpf_event: 1
  $
 
> This was due to an ordering issue between libpfm4 parsing
> the event string and perf record initializing the event.
 
> This patch fixes the problem by preventing override for
> events with attr->sample_period != 0 by the time
> perf_evsel__config() is invoked. This seems to have been the
> intent of the author.
> 
> Signed-off-by: Stephane Eranian 
> Reviewed-by: Ian Rogers 
> ---
>  tools/perf/util/evsel.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index 811f538f7d77..8afc24e2ec52 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -976,8 +976,7 @@ void evsel__config(struct evsel *evsel, struct 
> record_opts *opts,
>* We default some events to have a default interval. But keep
>* it a weak assumption overridable by the user.
>*/
> - if (!attr->sample_period || (opts->user_freq != UINT_MAX ||
> -  opts->user_interval != ULLONG_MAX)) {
> + if (!attr->sample_period) {
>   if (opts->freq) {
>   attr->freq  = 1;
>   attr->sample_freq   = opts->freq;
> -- 
> 2.28.0.163.g6104cc2f0b6-goog
> 

-- 

- Arnaldo

[PATCH v2] drivers/virt/fsl_hypervisor: Correcting error handling path

[Souptick Joarder]

First, when memory allocation for sg_list_unaligned failed, there
is no point of calling put_pages() as we haven't pinned any pages.

Second, if get_user_pages_fast() failed we should unpinned num_pinned
pages, no point of checking till num_pages.

This will address both.

Signed-off-by: Souptick Joarder 
Reviewed-by: Dan Carpenter 
Cc: John Hubbard 
---
v2:
Added review tag.

 drivers/virt/fsl_hypervisor.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/virt/fsl_hypervisor.c b/drivers/virt/fsl_hypervisor.c
index 1b0b11b..ea344d7 100644
--- a/drivers/virt/fsl_hypervisor.c
+++ b/drivers/virt/fsl_hypervisor.c
@@ -157,7 +157,7 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user 
*p)
 
unsigned int i;
long ret = 0;
-   int num_pinned; /* return value from get_user_pages() */
+   int num_pinned = 0; /* return value from get_user_pages() */
phys_addr_t remote_paddr; /* The next address in the remote buffer */
uint32_t count; /* The number of bytes left to copy */
 
@@ -293,7 +293,7 @@ static long ioctl_memcpy(struct fsl_hv_ioctl_memcpy __user 
*p)
 
 exit:
if (pages) {
-   for (i = 0; i < num_pages; i++)
+   for (i = 0; i < num_pinned; i++)
if (pages[i])
put_page(pages[i]);
}
-- 
1.9.1

Re: [PATCH v2 1/5] perf record: Set PERF_RECORD_PERIOD if attr->freq is set.

[Arnaldo Carvalho de Melo]

Em Tue, Jul 28, 2020 at 01:57:30AM -0700, Ian Rogers escreveu:
> From: David Sharp 
> 
> evsel__config() would only set PERF_RECORD_PERIOD if it set attr->freq

There is no such thing as 'PERF_RECORD_PERIOD', its PERF_SAMPLE_PERIOD,
also...

> from perf record options. When it is set by libpfm events, it would not
> get set. This changes evsel__config to see if attr->freq is set outside of
> whether or not it changes attr->freq itself.
> 
> Signed-off-by: David Sharp 
> Signed-off-by: Ian Rogers 
> ---
>  tools/perf/util/evsel.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index ef802f6d40c1..811f538f7d77 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -979,13 +979,18 @@ void evsel__config(struct evsel *evsel, struct 
> record_opts *opts,
>   if (!attr->sample_period || (opts->user_freq != UINT_MAX ||
>opts->user_interval != ULLONG_MAX)) {
>   if (opts->freq) {
> - evsel__set_sample_bit(evsel, PERIOD);
>   attr->freq  = 1;
>   attr->sample_freq   = opts->freq;
>   } else {
>   attr->sample_period = opts->default_interval;
>   }
>   }
> + /*
> +  * If attr->freq was set (here or earlier), ask for period
> +  * to be sampled.
> +  */
> + if (attr->freq)
> + evsel__set_sample_bit(evsel, PERIOD);

Why can't the libpfm code set opts?

With this patch we will end up calling evsel__set_sample_bit(evsel,
PERIOD) twice, which isn't a problem but looks strange.

- Arnaldo

>  
>   if (opts->no_samples)
>   attr->sample_freq = 0;
> -- 
> 2.28.0.163.g6104cc2f0b6-goog
> 

-- 

- Arnaldo

Re: [PATCH 1/1] vt_ioctl: prevent VT_RESIZEX font height change from causing potential out-of-bounds access

[George Kennedy]

Hi Greg,

I will re-work this patch based on comments from Dan.

Thank you,
George

On 7/29/2020 8:53 AM, Greg KH wrote:

On Wed, Jul 29, 2020 at 08:39:41AM -0400, George Kennedy wrote:

Add a VT_RESIZEX check to ensure that changing the font height will not
cause a potential out-of-bounds access. The candidate font height contained
in "v_clin", though below the max, could still result in accesses beyond
the allocated font data size.

Signed-off-by: George Kennedy 
Reported-by: syzbot+38a3699c7eaf165b9...@syzkaller.appspotmail.com

Did syzbot also test this that it fixes the reported issue?

What commit does this fix?  Should it go back farther to stable releases
too?

thanks,

greg k-h

Re: [PATCH v4 3/5] irqchip/irq-pruss-intc: Add logic for handling reserved interrupts

[David Lechner]

On 7/28/20 4:18 AM, Grzegorz Jaszczyk wrote:

From: Suman Anna 

The PRUSS INTC has a fixed number of output interrupt lines that are
connected to a number of processors or other PRUSS instances or other
devices (like DMA) on the SoC. The output interrupt lines 2 through 9
are usually connected to the main Arm host processor and are referred
to as host interrupts 0 through 7 from ARM/MPU perspective.

All of these 8 host interrupts are not always exclusively connected
to the Arm interrupt controller. Some SoCs have some interrupt lines
not connected to the Arm interrupt controller at all, while a few others
have the interrupt lines connected to multiple processors in which they
need to be partitioned as per SoC integration needs. For example, AM437x
and 66AK2G SoCs have 2 PRUSS instances each and have the host interrupt 5
connected to the other PRUSS, while AM335x has host interrupt 0 shared
between MPU and TSC_ADC and host interrupts 6 & 7 shared between MPU and
a DMA controller.

Add logic to the PRUSS INTC driver to ignore both these shared and
invalid interrupts.


If a person wanted to use DMA with a PRU what will handle the mapping
of a PRU event to host interrupt 6 or 7 if they are being ignored here?



Signed-off-by: Suman Anna 
Signed-off-by: Grzegorz Jaszczyk 
---
v3->v4:
- Due to changes in DT bindings which converts irqs-reserved
   property from uint8-array to bitmask requested by Rob introduce
   relevant changes in the driver.
- Merge the irqs-reserved and irqs-shared to one property since they
   can be handled by one logic (relevant change was introduced to DT
   binding).
- Update commit message.
v2->v3:
- Extra checks for (intc->irqs[i]) in error/remove path was moved from
   "irqchip/irq-pruss-intc: Add a PRUSS irqchip driver for PRUSS
   interrupts" to this patch
v1->v2:
- https://patchwork.kernel.org/patch/11069757/
---
  drivers/irqchip/irq-pruss-intc.c | 29 -
  1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/irqchip/irq-pruss-intc.c b/drivers/irqchip/irq-pruss-intc.c
index 45b966a..cf9a59b 100644
--- a/drivers/irqchip/irq-pruss-intc.c
+++ b/drivers/irqchip/irq-pruss-intc.c
@@ -474,7 +474,7 @@ static int pruss_intc_probe(struct platform_device *pdev)
struct pruss_intc *intc;
struct pruss_host_irq_data *host_data[MAX_NUM_HOST_IRQS] = { NULL };
int i, irq, ret;
-   u8 max_system_events;
+   u8 max_system_events, invalid_intr = 0;
  
  	data = of_device_get_match_data(dev);

if (!data)
@@ -496,6 +496,16 @@ static int pruss_intc_probe(struct platform_device *pdev)
return PTR_ERR(intc->base);
}
  
+	ret = of_property_read_u8(dev->of_node, "ti,irqs-reserved",

+ _intr);


Why not make the variable name match the property name?


+
+   /*
+* The irqs-reserved is used only for some SoC's therefore not having
+* this property is still valid
+*/
+   if (ret < 0 && ret != -EINVAL)
+   return ret;
+
pruss_intc_init(intc);
  
  	mutex_init(>lock);

@@ -506,6 +516,9 @@ static int pruss_intc_probe(struct platform_device *pdev)
return -ENOMEM;
  
  	for (i = 0; i < MAX_NUM_HOST_IRQS; i++) {

+   if (invalid_intr & BIT(i))
+   continue;
+
irq = platform_get_irq_byname(pdev, irq_names[i]);
if (irq <= 0) {
dev_err(dev, "platform_get_irq_byname failed for %s : 
%d\n",
@@ -533,8 +546,11 @@ static int pruss_intc_probe(struct platform_device *pdev)
return 0;
  
  fail_irq:

-   while (--i >= 0)
-   irq_set_chained_handler_and_data(intc->irqs[i], NULL, NULL);
+   while (--i >= 0) {
+   if (intc->irqs[i])
+   irq_set_chained_handler_and_data(intc->irqs[i], NULL,
+NULL);
+   }
  
  	irq_domain_remove(intc->domain);
  
@@ -548,8 +564,11 @@ static int pruss_intc_remove(struct platform_device *pdev)

unsigned int hwirq;
int i;
  
-	for (i = 0; i < MAX_NUM_HOST_IRQS; i++)

-   irq_set_chained_handler_and_data(intc->irqs[i], NULL, NULL);
+   for (i = 0; i < MAX_NUM_HOST_IRQS; i++) {
+   if (intc->irqs[i])
+   irq_set_chained_handler_and_data(intc->irqs[i], NULL,
+NULL);
+   }
  
  	for (hwirq = 0; hwirq < max_system_events; hwirq++)

irq_dispose_mapping(irq_find_mapping(intc->domain, hwirq));

Re: Inverted mount options completely broken (iversion,relatime)

[Josef Bacik]

On 7/29/20 2:41 PM, Eric Sandeen wrote:

On 7/29/20 11:32 AM, Josef Bacik wrote:

Hello,

Eric reported a problem to me where we were clearing SB_I_VERSION on remount of a btrfs 
file system.  After digging through I discovered it's because we expect the proper flags 
that we want to be passed in via the mount() syscall, and because we didn't have 
"iversion" in our show_options entry the mount binary (form util-linux) wasn't 
setting MS_I_VERSION for the remount, and thus the VFS was clearing SB_I_VERSION from our 
s_flags.

No big deal, I'll fix show_mount.  Except Eric then noticed that mount -o 
noiversion didn't do anything, we still get iversion set.  That's because btrfs 
just defaults to having SB_I_VERSION set.  Furthermore -o noiversion doesn't 
get sent into mount, it's handled by the mount binary itself, and it does this 
by not having MS_I_VERSION set in the mount flags.


This was beaten^Wdiscussed to death in an earlier thread,
[PATCH] fs: i_version mntopt gets visible through /proc/mounts

https://lore.kernel.org/linux-fsdevel/20200616202123.12656-1-msys.miz...@gmail.com/

tl;dr: hch doesn't think [no]iversion should be exposed as an option /at all/
so exposing it in /proc/mounts in show_mnt_opts for mount(8)'s benefit was
nacked.


This happens as well for -o relatime, it's the default and so if you do mount 
-o norelatime it won't do anything, you still get relatime behavior.


I think that's a different issue.


The only time this changes is if you do mount -o remount,norelatime.


Hm, not on xfs:

# mount -o loop,norelatime xfsfile  mnt
# grep loop /proc/mounts
/dev/loop0 /tmp/mnt xfs 
rw,seclabel,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0

# mount -o remount,norelatime mnt
# grep loop /proc/mounts
/dev/loop0 /tmp/mnt xfs 
rw,seclabel,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0



Oops you're right, I'm blind.  Same happens for btrfs, so using -o norelatime 
simply does nothing because it's considered a kernel wide default.




Are there other oddities besides iversion and relatime?


It doesn't look like it, I checked a few others of the MS_INVERT variety, these 
appear to be the only ones.  I really don't want to have this discussion again 
in the future tho when we introduce MS_SOME_NEW_AWESOME.  Thanks,


Josef

Re: [PATCH 4/5] PCI: aardvark: Implement driver 'remove' function and allow to build it as module

[Rob Herring]

On Wed, Jul 15, 2020 at 04:25:56PM +0200, Marek Behún wrote:
> From: Pali Rohár 
> 
> Providing driver's 'remove' function allows kernel to bind and unbind devices
> from aardvark driver. It also allows to build aardvark driver as a module.
> 
> Compiling aardvark as a module simplifies development and debugging of
> this driver as it can be reloaded at runtime without the need to reboot
> to new kernel.
> 
> Signed-off-by: Pali Rohár 
> Reviewed-by: Marek Behún 
> ---
>  drivers/pci/controller/Kconfig|  2 +-
>  drivers/pci/controller/pci-aardvark.c | 25 ++---
>  2 files changed, 23 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/pci/controller/Kconfig b/drivers/pci/controller/Kconfig
> index adddf21fa381..f9da5ff2c517 100644
> --- a/drivers/pci/controller/Kconfig
> +++ b/drivers/pci/controller/Kconfig
> @@ -12,7 +12,7 @@ config PCI_MVEBU
>   select PCI_BRIDGE_EMUL
>  
>  config PCI_AARDVARK
> - bool "Aardvark PCIe controller"
> + tristate "Aardvark PCIe controller"
>   depends on (ARCH_MVEBU && ARM64) || COMPILE_TEST
>   depends on OF
>   depends on PCI_MSI_IRQ_DOMAIN
> diff --git a/drivers/pci/controller/pci-aardvark.c 
> b/drivers/pci/controller/pci-aardvark.c
> index d5f58684d962..0a5aa6d77f5d 100644
> --- a/drivers/pci/controller/pci-aardvark.c
> +++ b/drivers/pci/controller/pci-aardvark.c
> @@ -14,6 +14,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -1114,6 +1115,7 @@ static int advk_pcie_probe(struct platform_device *pdev)
>  
>   pcie = pci_host_bridge_priv(bridge);
>   pcie->pdev = pdev;
> + platform_set_drvdata(pdev, pcie);
>  
>   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>   pcie->base = devm_ioremap_resource(dev, res);
> @@ -1204,18 +1206,35 @@ static int advk_pcie_probe(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> +static int advk_pcie_remove(struct platform_device *pdev)
> +{
> + struct advk_pcie *pcie = platform_get_drvdata(pdev);
> + struct pci_host_bridge *bridge = pci_host_bridge_from_priv(pcie);
> +
> + pci_stop_root_bus(bridge->bus);
> + pci_remove_root_bus(bridge->bus);

Based on pci_host_common_remove() implementation, doesn't this need a 
lock around it (pci_lock_rescan_remove)?

We should probably have a common function (say pci_bridge_remove) to 
implement this. You could use pci_host_common_remove(), but you'd have 
to adjust drvdata.

> +
> + advk_pcie_remove_msi_irq_domain(pcie);
> + advk_pcie_remove_irq_domain(pcie);
> +
> + return 0;
> +}
> +
>  static const struct of_device_id advk_pcie_of_match_table[] = {
>   { .compatible = "marvell,armada-3700-pcie", },
>   {},
>  };
> +MODULE_DEVICE_TABLE(of, advk_pcie_of_match_table);
>  
>  static struct platform_driver advk_pcie_driver = {
>   .driver = {
>   .name = "advk-pcie",
>   .of_match_table = advk_pcie_of_match_table,
> - /* Driver unloading/unbinding currently not supported */
> - .suppress_bind_attrs = true,
>   },
>   .probe = advk_pcie_probe,
> + .remove = advk_pcie_remove,
>  };
> -builtin_platform_driver(advk_pcie_driver);
> +module_platform_driver(advk_pcie_driver);
> +
> +MODULE_DESCRIPTION("Aardvark PCIe controller");
> +MODULE_LICENSE("GPL v2");
> -- 
> 2.26.2
> 

Re: [PATCH RFC] x86/bus_lock: Enable bus lock detection

[Sean Christopherson]

On Wed, Jul 29, 2020 at 11:09:16AM -0700, Yu, Fenghua wrote:
> > > Some CPUs have ability to notify the kernel by an #DB trap after the
> > > instruction acquires a bus lock and is executed. This allows the
> > > kernel to enforce user application throttling or mitigations and also
> > > provides a better environment to debug kernel split lock issues since
> > > the kernel can continue instead of crashing.
> > >
> > > #DB for bus lock detect fixes all issues in #AC for split lock detect:
> > 
> > Fixes "all" issues... and creates some new ones, e.g. there are use cases
> > where preventing the split lock from happening in the first place is 
> > strongly
> > desired.  It's why that train wreck exists.
> 
> Bus Lock Detection doesn't replace Split Lock Detection. If both features
> are enabled, default behavior is warning from bus lock, fatal behavior is
> still from split lock. See the behavior table as follows.
> 
> > 
> > > 1) It's architectural ... just need to look at one CPUID bit to know it
> > >exists
> > > 2) The IA32_DEBUGCTL MSR, which reports bus lock in #DB, is per-thread.
> > >So each process or guest can have different behavior.
> > > 3) It has support for VMM/guests (new VMEXIT codes, etc).
> > >
> > > Use the existing kernel command line option "split_lock_detect=" to
> > > handle #DB for bus lock:
> > 
> > Are SLD and BLD mutually exclusive?  Can we even guarantee that given the
> > track record of SLD?  If not, we'll likely want to allow the user to choose
> > between SDL and BLD via split_lock_detect.
> 
> The two hardware features can be enabled on the same platform.
> But they are mutually exclusive in the kernel because #AC from SLD happens
> before the instruction is executed and #DB happens after the instruction is
> executed.
> 
> Right now, if both of them are enabled, "warn" behavior goes to
> bus lock and "fatal" behavior goes to split lock.
> 
> Do you want the user to override the behaviors by something like this?
> 
> split_lock_detect=warn[,sld]: if given "sld" while both features are enabled,
> warn behavior is from split lock instead of bus lock detection.
> 
> split_lock_detect=fatal[,bld]: if given "bld" while both features are enabled,
> fatal behavior is from bus lock detection.

IMO these should be completely independent features (that happen to share
some code).

BLD in fatal mode doesn't make any sense because it can't be fatal without
a completely different implementation, e.g. the bus lock has already
happened and the application can eat the SIGBUS.  The current SLD code
works because the split lock is prevented entirely, i.e. eating SIGBUS
doesn't allow the application to make forward progress.

Smushing the two into a single option is confusing, e.g. from the table
below it's not at all clear what will happen if sld=fatal, both features
are supported, and the kernel generates a split lock.

Given that both SLD (per-core, not architectural) and BLD (#DB recursion and
inverted DR6 flag) have warts, it would be very nice to enable/disable them
independently.  The lock to non-WB behavior for BLD may also be problematic,
e.g. maybe it turns out that fixing drivers to avoid locks to non-WB isn't
as straightforward as avoiding split locks.

> > >  /*
> > >   * Default to sld_off because most systems do not support split lock
> > > detection
> > > - * split_lock_setup() will switch this to sld_warn on systems that
> > > support
> > > - * split lock detect, unless there is a command line override.
> > > + * sld_state_setup() will switch this to sld_warn on systems that
> > > + support
> > > + * split lock/bus lock detect, unless there is a command line override.
> > >   */
> > >  static enum split_lock_detect_state sld_state __ro_after_init =
> > > sld_off;  static u64 msr_test_ctrl_cache __ro_after_init;
> > > +/* Split lock detection is enabled if it's true. */ static bool sld;
> > > +/* Bus lock detection is enabled if it's true. */ static bool bld;
> > 
> > Why can't these be tracked/reflected in X86_FEATURE_*?
> 
> sld and bld are enabled depending on kernel parameter "split_lock_detect=".
> They are not static and cannot be tracked by static X86_FEATURE_*.

X86_FEATURE_* flags aren't static, the kernel sets/clears them all over the
place.

Re: [PATCH v4 2/5] irqchip/irq-pruss-intc: Add a PRUSS irqchip driver for PRUSS interrupts

[David Lechner]

On 7/28/20 4:18 AM, Grzegorz Jaszczyk wrote:

The Programmable Real-Time Unit Subsystem (PRUSS) contains a local
interrupt controller (INTC) that can handle various system input events
and post interrupts back to the device-level initiators. The INTC can
support upto 64 input events with individual control configuration and
hardware prioritization. These events are mapped onto 10 output interrupt
lines through two levels of many-to-one mapping support. Different
interrupt lines are routed to the individual PRU cores or to the host
CPU, or to other devices on the SoC. Some of these events are sourced
from peripherals or other sub-modules within that PRUSS, while a few
others are sourced from SoC-level peripherals/devices.

The PRUSS INTC platform driver manages this PRUSS interrupt controller
and implements an irqchip driver to provide a Linux standard way for
the PRU client users to enable/disable/ack/re-trigger a PRUSS system
event. The system events to interrupt channels and output interrupts
relies on the mapping configuration provided either through the PRU
firmware blob (for interrupts routed to PRU cores) or via the PRU
application's device tree node (for interrupt routed to the main CPU).
In the first case the mappings will be programmed on PRU remoteproc
driver demand (via irq_create_fwspec_mapping) during the boot of a PRU
core and cleaned up after the PRU core is stopped.

Reference counting is used to allow multiple system events to share a
single channel and to allow multiple channels to share a single host
event.

The PRUSS INTC module is reference counted during the interrupt
setup phase through the irqchip's irq_request_resources() and
irq_release_resources() ops. This restricts the module from being
removed as long as there are active interrupt users.

The driver currently supports and can be built for OMAP architecture
based AM335x, AM437x and AM57xx SoCs; Keystone2 architecture based
66AK2G SoCs and Davinci architecture based OMAP-L13x/AM18x/DA850 SoCs.
All of these SoCs support 64 system events, 10 interrupt channels and
10 output interrupt lines per PRUSS INTC with a few SoC integration
differences.

NOTE:
Each PRU-ICSS's INTC on AM57xx SoCs is preceded by a Crossbar that
enables multiple external events to be routed to a specific number
of input interrupt events. Any non-default external interrupt event
directed towards PRUSS needs this crossbar to be setup properly.

Signed-off-by: Suman Anna 
Signed-off-by: Andrew F. Davis 
Signed-off-by: Roger Quadros 
Signed-off-by: Grzegorz Jaszczyk 
---


It looks like this patch also includes code that I wrote [1] so:

Signed-off-by: David Lechner 


[1]: 
https://lore.kernel.org/lkml/124b03b8-f8e7-682b-8767-13a739329...@lechnology.com/



diff --git a/drivers/irqchip/irq-pruss-intc.c b/drivers/irqchip/irq-pruss-intc.c
new file mode 100644
index 000..45b966a
--- /dev/null
+++ b/drivers/irqchip/irq-pruss-intc.c
@@ -0,0 +1,591 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * PRU-ICSS INTC IRQChip driver for various TI SoCs
+ *
+ * Copyright (C) 2016-2020 Texas Instruments Incorporated - http://www.ti.com/
+ * Andrew F. Davis 
+ * Suman Anna 


Please add:

+ * Copyright (C) 2019 David Lechner 


+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Number of host interrupts reaching the main MPU sub-system. Note that this
+ * is not the same as the total number of host interrupts supported by the 
PRUSS
+ * INTC instance
+ */
+#define MAX_NUM_HOST_IRQS  8
+
+/* minimum starting host interrupt number for MPU */
+#define MIN_PRU_HOST_INT   2


nit: "First" might be a better word choice than "minimum"


+
+/* PRU_ICSS_INTC registers */
+#define PRU_INTC_REVID 0x
+#define PRU_INTC_CR0x0004
+#define PRU_INTC_GER   0x0010
+#define PRU_INTC_GNLR  0x001c
+#define PRU_INTC_SISR  0x0020
+#define PRU_INTC_SICR  0x0024
+#define PRU_INTC_EISR  0x0028
+#define PRU_INTC_EICR  0x002c
+#define PRU_INTC_HIEISR0x0034
+#define PRU_INTC_HIDISR0x0038
+#define PRU_INTC_GPIR  0x0080
+#define PRU_INTC_SRSR(x)   (0x0200 + (x) * 4)
+#define PRU_INTC_SECR(x)   (0x0280 + (x) * 4)
+#define PRU_INTC_ESR(x)(0x0300 + (x) * 4)
+#define PRU_INTC_ECR(x)(0x0380 + (x) * 4)
+#define PRU_INTC_CMR(x)(0x0400 + (x) * 4)
+#define PRU_INTC_HMR(x)(0x0800 + (x) * 4)
+#define PRU_INTC_HIPIR(x)  (0x0900 + (x) * 4)
+#define PRU_INTC_SIPR(x)   (0x0d00 + (x) * 4)
+#define PRU_INTC_SITR(x)   (0x0d80 + (x) * 4)
+#define PRU_INTC_HINLR(x)  (0x1100 + (x) * 4)
+#define PRU_INTC_HIER  0x1500
+
+/* CMR register bit-field macros */
+#define CMR_EVT_MAP_MASK   0xf
+#define CMR_EVT_MAP_BITS   8
+#define CMR_EVT_PER_REG4
+
+/* HMR register bit-field macros */
+#define HMR_CH_MAP_MASK0xf
+#define HMR_CH_MAP_BITS  

Re: [git pull] drm fixes for 5.8-rc8

[Linus Torvalds]

On Tue, Jul 28, 2020 at 9:44 PM Dave Airlie  wrote:
>
> If you feel this is too much I'm happy to respin with the
> core/drm_fb_helper and nouveau fixes. we have one outstanding nouveau
> regression fix, that I'll follow this up with in the next day or so
> once Ben and James get it reviewed.

This looks fine to me, I've pulled it. I'll be looking forward to (not
really ;) another pull for the remaining issue.

Thanks,

   Linus

Re: [PATCH v1 2/2] timer: mt6873: porting Mediatek timer driver to loadable module

[Saravana Kannan]

On Wed, Jul 29, 2020 at 6:02 AM Thomas Gleixner  wrote:
>
> Freddy,
>
> Freddy Hsin  writes:
>
> again, please be more careful with subject lines. git log $FILE will
> give you a hint.
>
> > porting Mediatek timer driver to loadable module
>
> Repeating the sentence in the subject line is not giving any
> information. Also changelogs want to tell the WHY and not the WHAT. This
> also lacks any information why this is actually safe when booting such a
> system w/o this particular driver built in. What is early boot - up to
> module load - using as clocksource and timer?
>
> > diff --git a/drivers/clocksource/mmio.c b/drivers/clocksource/mmio.c
> > index 9de7515..5504569 100644
> > --- a/drivers/clocksource/mmio.c
> > +++ b/drivers/clocksource/mmio.c
> > @@ -21,6 +21,7 @@ u64 clocksource_mmio_readl_up(struct clocksource *c)
> >  {
> >   return (u64)readl_relaxed(to_mmio_clksrc(c)->reg);
> >  }
> > +EXPORT_SYMBOL(clocksource_mmio_readl_up);
>
> Again EXPORT_SYMBOL_GPL() and this wants to be a seperate patch. It has
> absolutely no business with the mediatek timer changes.
>
> >  u64 clocksource_mmio_readl_down(struct clocksource *c)
> >  {
> > @@ -46,7 +47,7 @@ u64 clocksource_mmio_readw_down(struct clocksource *c)
> >   * @bits:Number of valid bits
> >   * @read:One of clocksource_mmio_read*() above
> >   */
> > -int __init clocksource_mmio_init(void __iomem *base, const char *name,
> > +int clocksource_mmio_init(void __iomem *base, const char *name,
> >
> >   unsigned long hz, int rating, unsigned bits,
> >   u64 (*read)(struct clocksource *))
> >  {
> > @@ -68,3 +69,4 @@ int __init clocksource_mmio_init(void __iomem *base, 
> > const char *name,
> >
> >   return clocksource_register_hz(>clksrc, hz);
> >  }
> > +EXPORT_SYMBOL(clocksource_mmio_init);
>
> See above.
>
> > diff --git a/drivers/clocksource/timer-mediatek.c 
> > b/drivers/clocksource/timer-mediatek.c
> > index 9318edc..5c89b6b 100644
> > --- a/drivers/clocksource/timer-mediatek.c
> > +++ b/drivers/clocksource/timer-mediatek.c
> > @@ -13,6 +13,9 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +#include 
> >  #include 
> >  #include 
> >  #include "timer-of.h"
> > @@ -309,5 +312,41 @@ static int __init mtk_gpt_init(struct device_node 
> > *node)
> >
> >   return 0;
> >  }
> > +
> > +#ifdef MODULE
> > +static int mtk_timer_probe(struct platform_device *pdev)
> > +{
> > + int (*timer_init)(struct device_node *node);
> > + struct device_node *np = pdev->dev.of_node;
> > +
> > + timer_init = of_device_get_match_data(>dev);
> > + return timer_init(np);
> > +}
> > +
> > +static const struct of_device_id mtk_timer_match_table[] = {
> > + {
> > + .compatible = "mediatek,mt6577-timer",
> > + .data = mtk_gpt_init,
> > + },
> > + {
> > + .compatible = "mediatek,mt6765-timer",
> > + .data = mtk_syst_init,
> > + },
> > + {}
> > +};
> > +
> > +static struct platform_driver mtk_timer_driver = {
> > + .probe = mtk_timer_probe,
> > + .driver = {
> > + .name = "mtk-timer",
> > + .of_match_table = mtk_timer_match_table,
> > + },
> > +};
> > +MODULE_DESCRIPTION("MEDIATEK Module timer driver");
> > +MODULE_LICENSE("GPL v2");
> > +
> > +module_platform_driver(mtk_timer_driver);
> > +#else
> >  TIMER_OF_DECLARE(mtk_mt6577, "mediatek,mt6577-timer", mtk_gpt_init);
> >  TIMER_OF_DECLARE(mtk_mt6765, "mediatek,mt6765-timer", mtk_syst_init);
> > +#endif
>
> Sorry no. This is not going to happen.
>
> The above probe, match table and platform driver structs plus the module*
> thingies are going to be repeated in every single driver which is going
> to support module build. Tons of boilerplate copied over and over
> again.
>
> We had exactly the same before TIMER_OF_DECLARE() came around, so pretty
> please this want's to be some smart macro which handles all of this
> automatically.

Probably something like what I did for IRQCHIP?
https://lore.kernel.org/lkml/20200718000637.3632841-1-sarava...@google.com/

Also, one point that came up with IRQCHIP is that if these drivers can
be platform drivers, then they should stay that way even when it's
built in. I'm not sure if that has any other special implications for
timer code, but raising it in case you'd prefer that here too.


-Saravana

Re: Inverted mount options completely broken (iversion,relatime)

[Eric Sandeen]

On 7/29/20 11:32 AM, Josef Bacik wrote:
> Hello,
> 
> Eric reported a problem to me where we were clearing SB_I_VERSION on remount 
> of a btrfs file system.  After digging through I discovered it's because we 
> expect the proper flags that we want to be passed in via the mount() syscall, 
> and because we didn't have "iversion" in our show_options entry the mount 
> binary (form util-linux) wasn't setting MS_I_VERSION for the remount, and 
> thus the VFS was clearing SB_I_VERSION from our s_flags.
> 
> No big deal, I'll fix show_mount.  Except Eric then noticed that mount -o 
> noiversion didn't do anything, we still get iversion set.  That's because 
> btrfs just defaults to having SB_I_VERSION set.  Furthermore -o noiversion 
> doesn't get sent into mount, it's handled by the mount binary itself, and it 
> does this by not having MS_I_VERSION set in the mount flags.

This was beaten^Wdiscussed to death in an earlier thread,
[PATCH] fs: i_version mntopt gets visible through /proc/mounts

https://lore.kernel.org/linux-fsdevel/20200616202123.12656-1-msys.miz...@gmail.com/

tl;dr: hch doesn't think [no]iversion should be exposed as an option /at all/
so exposing it in /proc/mounts in show_mnt_opts for mount(8)'s benefit was
nacked.

> This happens as well for -o relatime, it's the default and so if you do mount 
> -o norelatime it won't do anything, you still get relatime behavior.

I think that's a different issue.

> The only time this changes is if you do mount -o remount,norelatime.

Hm, not on xfs:

# mount -o loop,norelatime xfsfile  mnt
# grep loop /proc/mounts
/dev/loop0 /tmp/mnt xfs 
rw,seclabel,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0

# mount -o remount,norelatime mnt
# grep loop /proc/mounts
/dev/loop0 /tmp/mnt xfs 
rw,seclabel,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0

Here, "norelatime" only makes the mount binary omit the MS_RELATIME flag.
The only way to override relatime behavior is mount -o strictatime, AFAICT.

IOWS "norelatime" and "strictatime" are the same (right?); perhaps
mount -o norelatime should set the MS_STRICTATIME flag.

> So my question is, what do we do here?  I know Christoph has the strong 
> opinion that we just don't expose I_VERSION at all, which frankly I'm ok 
> with.  However more what I'm asking is what do we do with these weird 
> inverted flags that we all just kind of ignore on mount?  The current setup 
> is just broken if we want to allow overriding the defaults at mount time.  
> Are we ok with it just being broken?  Are we ok with things like mount -o 
> noiversion not working because the file system has decided that I_VERSION (or 
> relatime) is the default, and we're going to ignore what the user asks for 
> unless we're remounting?  Thanks,

Are there other oddities besides iversion and relatime?

-Eric

Re: [PATCH v1 2/6] mm/page_isolation: don't dump_page(NULL) in set_migratetype_isolate()

[David Hildenbrand]

> Am 29.07.2020 um 20:36 schrieb Mike Kravetz :
> 
> On 7/29/20 11:08 AM, David Hildenbrand wrote:
>> I have no clue what you mean with "reintroducing this abandoning of
>> pageblocks". All this patch is changing is not doing the dump_page() -
>> or am I missing something important?
> 
> My apologies!!!
> 

No worries, thanks for reviewing!!

> I got confused when I saw 'Return -EBUSY' removed from the comment and
> assumed the code would not return an error code.  The code now more
> explicitly does return -EBUSY.  My concern was when I incorrectly thought
> you were removing the error return code.  Sorry for the noise.
> 
> Acked-by: Mike Kravetz 
> -- 
> Mike Kravetz
> 

Re: [PATCH RFC v8 02/11] vhost: use batched get_vq_desc version

[Eugenio Perez Martin]

On Tue, Jul 21, 2020 at 4:55 AM Jason Wang  wrote:
>
>
> On 2020/7/20 下午7:16, Eugenio Pérez wrote:
> > On Mon, Jul 20, 2020 at 11:27 AM Michael S. Tsirkin  wrote:
> >> On Thu, Jul 16, 2020 at 07:16:27PM +0200, Eugenio Perez Martin wrote:
> >>> On Fri, Jul 10, 2020 at 7:58 AM Michael S. Tsirkin  
> >>> wrote:
>  On Fri, Jul 10, 2020 at 07:39:26AM +0200, Eugenio Perez Martin wrote:
> >>> How about playing with the batch size? Make it a mod parameter instead
> >>> of the hard coded 64, and measure for all values 1 to 64 ...
> >> Right, according to the test result, 64 seems to be too aggressive in
> >> the case of TX.
> >>
> > Got it, thanks both!
>  In particular I wonder whether with batch size 1
>  we get same performance as without batching
>  (would indicate 64 is too aggressive)
>  or not (would indicate one of the code changes
>  affects performance in an unexpected way).
> 
>  --
>  MST
> 
> >>> Hi!
> >>>
> >>> Varying batch_size as drivers/vhost/net.c:VHOST_NET_BATCH,
> >> sorry this is not what I meant.
> >>
> >> I mean something like this:
> >>
> >>
> >> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> >> index 0b509be8d7b1..b94680e5721d 100644
> >> --- a/drivers/vhost/net.c
> >> +++ b/drivers/vhost/net.c
> >> @@ -1279,6 +1279,10 @@ static void handle_rx_net(struct vhost_work *work)
> >>  handle_rx(net);
> >>   }
> >>
> >> +MODULE_PARM_DESC(batch_num, "Number of batched descriptors. (offset from 
> >> 64)");
> >> +module_param(batch_num, int, 0644);
> >> +static int batch_num = 0;
> >> +
> >>   static int vhost_net_open(struct inode *inode, struct file *f)
> >>   {
> >>  struct vhost_net *n;
> >> @@ -1333,7 +1337,7 @@ static int vhost_net_open(struct inode *inode, 
> >> struct file *f)
> >>  vhost_net_buf_init(>vqs[i].rxq);
> >>  }
> >>  vhost_dev_init(dev, vqs, VHOST_NET_VQ_MAX,
> >> -  UIO_MAXIOV + VHOST_NET_BATCH,
> >> +  UIO_MAXIOV + VHOST_NET_BATCH + batch_num,
> >> VHOST_NET_PKT_WEIGHT, VHOST_NET_WEIGHT, true,
> >> NULL);
> >>
> >>
> >> then you can try tweaking batching and playing with mod parameter without
> >> recompiling.
> >>
> >>
> >> VHOST_NET_BATCH affects lots of other things.
> >>
> > Ok, got it. Since they were aligned from the start, I thought it was a good 
> > idea to maintain them in-sync.
> >
> >>> and testing
> >>> the pps as previous mail says. This means that we have either only
> >>> vhost_net batching (in base testing, like previously to apply this
> >>> patch) or both batching sizes the same.
> >>>
> >>> I've checked that vhost process (and pktgen) goes 100% cpu also.
> >>>
> >>> For tx: Batching decrements always the performance, in all cases. Not
> >>> sure why bufapi made things better the last time.
> >>>
> >>> Batching makes improvements until 64 bufs, I see increments of pps but 
> >>> like 1%.
> >>>
> >>> For rx: Batching always improves performance. It seems that if we
> >>> batch little, bufapi decreases performance, but beyond 64, bufapi is
> >>> much better. The bufapi version keeps improving until I set a batching
> >>> of 1024. So I guess it is super good to have a bunch of buffers to
> >>> receive.
> >>>
> >>> Since with this test I cannot disable event_idx or things like that,
> >>> what would be the next step for testing?
> >>>
> >>> Thanks!
> >>>
> >>> --
> >>> Results:
> >>> # Buf size: 1,16,32,64,128,256,512
> >>>
> >>> # Tx
> >>> # ===
> >>> # Base
> >>> 2293304.308,3396057.769,3540860.615,3636056.077,3332950.846,3694276.154,3689820
> >>> # Batch
> >>> 2286723.857,3307191.643,3400346.571,3452527.786,3460766.857,3431042.5,3440722.286
> >>> # Batch + Bufapi
> >>> 2257970.769,3151268.385,3260150.538,3379383.846,3424028.846,3433384.308,3385635.231,3406554.538
> >>>
> >>> # Rx
> >>> # ==
> >>> # pktgen results (pps)
> >>> 1223275,1668868,1728794,1769261,1808574,1837252,1846436
> >>> 1456924,1797901,1831234,1868746,1877508,1931598,1936402
> >>> 1368923,1719716,1794373,1865170,1884803,1916021,1975160
> >>>
> >>> # Testpmd pps results
> >>> 1222698.143,1670604,1731040.6,1769218,1811206,1839308.75,1848478.75
> >>> 1450140.5,1799985.75,1834089.75,1871290,1880005.5,1934147.25,1939034
> >>> 1370621,1721858,1796287.75,1866618.5,1885466.5,1918670.75,1976173.5,1988760.75,1978316
> >>>
> >>> pktgen was run again for rx with 1024 and 2048 buf size, giving
> >>> 1988760.75 and 1978316 pps. Testpmd goes the same way.
> >> Don't really understand what does this data mean.
> >> Which number of descs is batched for each run?
> >>
> > Sorry, I should have explained better. I will expand here, but feel free to 
> > skip it since we are going to discard the
> > data anyway. Or to propose a better way to tell them.
> >
> > Is a CSV with the values I've obtained, in pps, from pktgen and testpmd. 
> > This way is easy to plot them.
> >
> > Maybe is easier as tables, if 

Re: [PATCH] net/mlx5e: fix bpf_prog reference count leaks in mlx5e_alloc_rq

[Markus Elfring]

…
> The refcount leak issues take place in two error handling paths.

Can an other wording be a bit nicer for the commit message?


> Fix the issue by …

I suggest to replace this wording by the tag “Fixes”.

Regards,
Markus

Re: [PATCH v1 2/6] mm/page_isolation: don't dump_page(NULL) in set_migratetype_isolate()

[Mike Kravetz]

On 7/29/20 11:08 AM, David Hildenbrand wrote:
> I have no clue what you mean with "reintroducing this abandoning of
> pageblocks". All this patch is changing is not doing the dump_page() -
> or am I missing something important?

My apologies!!!

I got confused when I saw 'Return -EBUSY' removed from the comment and
assumed the code would not return an error code.  The code now more
explicitly does return -EBUSY.  My concern was when I incorrectly thought
you were removing the error return code.  Sorry for the noise.

Acked-by: Mike Kravetz 
-- 
Mike Kravetz

drivers/vfio/pci/vfio_pci_nvlink2.c:100:9: error: implicit declaration of function 'mm_iommu_put'; did you mean

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   6ba1b005ffc388c2aeaddae20da29e4810dea298
commit: ee8642162a9edd40daafd3fb894e3fd3f909e361 drm/nouveau: fix build error 
without CONFIG_IOMMU_API
date:   6 months ago
config: powerpc64-randconfig-r031-20200729 (attached as .config)
compiler: powerpc64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ee8642162a9edd40daafd3fb894e3fd3f909e361
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=powerpc64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   drivers/vfio/pci/vfio_pci_nvlink2.c: In function 'vfio_pci_nvgpu_release':
>> drivers/vfio/pci/vfio_pci_nvlink2.c:100:9: error: implicit declaration of 
>> function 'mm_iommu_put'; did you mean 'mm_iommu_init'? 
>> [-Werror=implicit-function-declaration]
 100 |   ret = mm_iommu_put(data->mm, data->mem);
 | ^~~~
 | mm_iommu_init
   drivers/vfio/pci/vfio_pci_nvlink2.c: In function 'vfio_pci_nvgpu_mmap':
>> drivers/vfio/pci/vfio_pci_nvlink2.c:163:14: error: implicit declaration of 
>> function 'mm_iommu_newdev' [-Werror=implicit-function-declaration]
 163 |  ret = (int) mm_iommu_newdev(data->mm, data->useraddr,
 |  ^~~
   cc1: some warnings being treated as errors

vim +100 drivers/vfio/pci/vfio_pci_nvlink2.c

7f92891778dff62 Alexey Kardashevskiy 2018-12-20   91  
7f92891778dff62 Alexey Kardashevskiy 2018-12-20   92  static void 
vfio_pci_nvgpu_release(struct vfio_pci_device *vdev,
7f92891778dff62 Alexey Kardashevskiy 2018-12-20   93struct 
vfio_pci_region *region)
7f92891778dff62 Alexey Kardashevskiy 2018-12-20   94  {
7f92891778dff62 Alexey Kardashevskiy 2018-12-20   95struct 
vfio_pci_nvgpu_data *data = region->data;
7f92891778dff62 Alexey Kardashevskiy 2018-12-20   96long ret;
7f92891778dff62 Alexey Kardashevskiy 2018-12-20   97  
7f92891778dff62 Alexey Kardashevskiy 2018-12-20   98/* If there were any 
mappings at all... */
7f92891778dff62 Alexey Kardashevskiy 2018-12-20   99if (data->mm) {
7f92891778dff62 Alexey Kardashevskiy 2018-12-20 @100ret = 
mm_iommu_put(data->mm, data->mem);
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  101WARN_ON(ret);
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  102  
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  103
mmdrop(data->mm);
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  104}
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  105  
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  106
vfio_unregister_notifier(>gpdev->dev, VFIO_GROUP_NOTIFY,
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  107
>group_notifier);
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  108  
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  109
pnv_npu2_unmap_lpar_dev(data->gpdev);
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  110  
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  111kfree(data);
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  112  }
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  113  
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  114  static vm_fault_t 
vfio_pci_nvgpu_mmap_fault(struct vm_fault *vmf)
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  115  {
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  116vm_fault_t ret;
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  117struct vm_area_struct 
*vma = vmf->vma;
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  118struct vfio_pci_region 
*region = vma->vm_private_data;
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  119struct 
vfio_pci_nvgpu_data *data = region->data;
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  120unsigned long vmf_off = 
(vmf->address - vma->vm_start) >> PAGE_SHIFT;
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  121unsigned long nv2pg = 
data->gpu_hpa >> PAGE_SHIFT;
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  122unsigned long vm_pgoff 
= vma->vm_pgoff &
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  123((1U << 
(VFIO_PCI_OFFSET_SHIFT - PAGE_SHIFT)) - 1);
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  124unsigned long pfn = 
nv2pg + vm_pgoff + vmf_off;
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  125  
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  126ret = 
vmf_insert_pfn(vma, vmf->address, pfn);
7f92891778dff62 Alexey Kardashevskiy 2018-12-20  127
trace_vfio_pci_nvgpu_mmap_fault(data->gpdev, pfn << PAGE_SHIFT,
7f92891778dff62 Alexey Kardashevs

Re: [PATCH -next] drm: xlnx: Fix typo in parameter description

[Hyun Kwon]

Hi Wei,

Thanks for the patch.

On Tue, Jul 28, 2020 at 03:33:49PM -0700, Laurent Pinchart wrote:
> Hi Wei,
> 
> Thank you for the patch.
> 
> On Sat, Jul 25, 2020 at 06:34:29AM +, Wei Yongjun wrote:
> > Fix typo in parameter description.
> > 
> > Fixes: d76271d22694 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP 
> > DisplayPort Subsystem")
> > Reported-by: Hulk Robot 
> > Signed-off-by: Wei Yongjun 
> 
> Reviewed-by: Laurent Pinchart 
> 

Reviewed-by: Hyun Kwon 

I'll commit this to drm-misc-next-fixes soon.

Thanks,
-hyun

> > ---
> >  drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c 
> > b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > index 821f7a71e182..3d53638ab15e 100644
> > --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > @@ -44,7 +44,7 @@ MODULE_PARM_DESC(aux_timeout_ms, "DP aux timeout value in 
> > msec (default: 50)");
> >   */
> >  static uint zynqmp_dp_power_on_delay_ms = 4;
> >  module_param_named(power_on_delay_ms, zynqmp_dp_power_on_delay_ms, uint, 
> > 0444);
> > -MODULE_PARM_DESC(aux_timeout_ms, "DP power on delay in msec (default: 4)");
> > +MODULE_PARM_DESC(power_on_delay_ms, "DP power on delay in msec (default: 
> > 4)");
> >  
> >  /* Link configuration registers */
> >  #define ZYNQMP_DP_LINK_BW_SET  0x0
> 
> -- 
> Regards,
> 
> Laurent Pinchart

Inverted mount options completely broken (iversion,relatime)

[Josef Bacik]

Hello,

Eric reported a problem to me where we were clearing SB_I_VERSION on remount of 
a btrfs file system.  After digging through I discovered it's because we expect 
the proper flags that we want to be passed in via the mount() syscall, and 
because we didn't have "iversion" in our show_options entry the mount binary 
(form util-linux) wasn't setting MS_I_VERSION for the remount, and thus the VFS 
was clearing SB_I_VERSION from our s_flags.


No big deal, I'll fix show_mount.  Except Eric then noticed that mount -o 
noiversion didn't do anything, we still get iversion set.  That's because btrfs 
just defaults to having SB_I_VERSION set.  Furthermore -o noiversion doesn't get 
sent into mount, it's handled by the mount binary itself, and it does this by 
not having MS_I_VERSION set in the mount flags.


This happens as well for -o relatime, it's the default and so if you do mount -o 
norelatime it won't do anything, you still get relatime behavior.  The only time 
this changes is if you do mount -o remount,norelatime.


So my question is, what do we do here?  I know Christoph has the strong opinion 
that we just don't expose I_VERSION at all, which frankly I'm ok with.  However 
more what I'm asking is what do we do with these weird inverted flags that we 
all just kind of ignore on mount?  The current setup is just broken if we want 
to allow overriding the defaults at mount time.  Are we ok with it just being 
broken?  Are we ok with things like mount -o noiversion not working because the 
file system has decided that I_VERSION (or relatime) is the default, and we're 
going to ignore what the user asks for unless we're remounting?  Thanks,


Josef

[PATCH v6 3/4] dt-bindings: power: Add BQ28z610 compatible

[Dan Murphy]

Add the Texas Instruments bq28z610 battery monitor to the bq27xxx
binding.

Acked-by: Rob Herring 
Signed-off-by: Dan Murphy 
---
 Documentation/devicetree/bindings/power/supply/bq27xxx.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml 
b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml
index 0aa33590ac24..82f682705f44 100644
--- a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml
+++ b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml
@@ -50,6 +50,7 @@ properties:
   - ti,bq27441
   - ti,bq27621
   - ti,bq27z561
+  - ti,bq28z610
 
   reg:
 maxItems: 1
-- 
2.28.0

[PATCH v6 2/4] power: supply: bq27xxx_battery: Add the BQ27Z561 Battery monitor

[Dan Murphy]

Add the Texas Instruments BQ27Z561 battery monitor.  The register address
map is laid out the same as compared to other devices within the file.
The battery status register has differing bits to determine if the
battery is full, discharging or dead.

Signed-off-by: Dan Murphy 
---
 drivers/power/supply/bq27xxx_battery.c | 68 +-
 drivers/power/supply/bq27xxx_battery_i2c.c |  2 +
 include/linux/power/bq27xxx_battery.h  |  1 +
 3 files changed, 70 insertions(+), 1 deletion(-)

diff --git a/drivers/power/supply/bq27xxx_battery.c 
b/drivers/power/supply/bq27xxx_battery.c
index acaafed037be..a05b9a2d112d 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -43,6 +43,7 @@
  * https://www.ti.com/product/bq27411-g1
  * https://www.ti.com/product/bq27441-g1
  * https://www.ti.com/product/bq27621-g1
+ * https://www.ti.com/product/bq27z561
  */
 
 #include 
@@ -79,6 +80,11 @@
 #define BQ27000_FLAG_FCBIT(5)
 #define BQ27000_FLAG_CHGS  BIT(7) /* Charge state flag */
 
+/* BQ27Z561 has different layout for Flags register */
+#define BQ27Z561_FLAG_FDC  BIT(4) /* Battery fully discharged */
+#define BQ27Z561_FLAG_FC   BIT(5) /* Battery fully charged */
+#define BQ27Z561_FLAG_DIS_CH   BIT(6) /* Battery is discharging */
+
 /* control register params */
 #define BQ27XXX_SEALED 0x20
 #define BQ27XXX_SET_CFGUPDATE  0x13
@@ -431,12 +437,32 @@ static u8
[BQ27XXX_REG_DCAP] = 0x3c,
[BQ27XXX_REG_AP] = 0x18,
BQ27XXX_DM_REG_ROWS,
-   };
+   },
 #define bq27411_regs bq27421_regs
 #define bq27425_regs bq27421_regs
 #define bq27426_regs bq27421_regs
 #define bq27441_regs bq27421_regs
 #define bq27621_regs bq27421_regs
+   bq27z561_regs[BQ27XXX_REG_MAX] = {
+   [BQ27XXX_REG_CTRL] = 0x00,
+   [BQ27XXX_REG_TEMP] = 0x06,
+   [BQ27XXX_REG_INT_TEMP] = INVALID_REG_ADDR,
+   [BQ27XXX_REG_VOLT] = 0x08,
+   [BQ27XXX_REG_AI] = 0x14,
+   [BQ27XXX_REG_FLAGS] = 0x0a,
+   [BQ27XXX_REG_TTE] = 0x16,
+   [BQ27XXX_REG_TTF] = 0x18,
+   [BQ27XXX_REG_TTES] = INVALID_REG_ADDR,
+   [BQ27XXX_REG_TTECP] = INVALID_REG_ADDR,
+   [BQ27XXX_REG_NAC] = INVALID_REG_ADDR,
+   [BQ27XXX_REG_FCC] = 0x12,
+   [BQ27XXX_REG_CYCT] = 0x2a,
+   [BQ27XXX_REG_AE] = 0x22,
+   [BQ27XXX_REG_SOC] = 0x2c,
+   [BQ27XXX_REG_DCAP] = 0x3c,
+   [BQ27XXX_REG_AP] = 0x22,
+   BQ27XXX_DM_REG_ROWS,
+   };
 
 static enum power_supply_property bq27000_props[] = {
POWER_SUPPLY_PROP_STATUS,
@@ -672,6 +698,25 @@ static enum power_supply_property bq27421_props[] = {
 #define bq27441_props bq27421_props
 #define bq27621_props bq27421_props
 
+static enum power_supply_property bq27z561_props[] = {
+   POWER_SUPPLY_PROP_STATUS,
+   POWER_SUPPLY_PROP_PRESENT,
+   POWER_SUPPLY_PROP_VOLTAGE_NOW,
+   POWER_SUPPLY_PROP_CURRENT_NOW,
+   POWER_SUPPLY_PROP_CAPACITY,
+   POWER_SUPPLY_PROP_CAPACITY_LEVEL,
+   POWER_SUPPLY_PROP_TEMP,
+   POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
+   POWER_SUPPLY_PROP_TIME_TO_FULL_NOW,
+   POWER_SUPPLY_PROP_TECHNOLOGY,
+   POWER_SUPPLY_PROP_CHARGE_FULL,
+   POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
+   POWER_SUPPLY_PROP_CYCLE_COUNT,
+   POWER_SUPPLY_PROP_POWER_AVG,
+   POWER_SUPPLY_PROP_HEALTH,
+   POWER_SUPPLY_PROP_MANUFACTURER,
+};
+
 struct bq27xxx_dm_reg {
u8 subclass_id;
u8 offset;
@@ -767,11 +812,14 @@ static struct bq27xxx_dm_reg bq27621_dm_regs[] = {
 #define bq27621_dm_regs 0
 #endif
 
+#define bq27z561_dm_regs 0
+
 #define BQ27XXX_O_ZERO 0x0001
 #define BQ27XXX_O_OTDC 0x0002 /* has OTC/OTD overtemperature flags */
 #define BQ27XXX_O_UTOT  0x0004 /* has OT overtemperature flag */
 #define BQ27XXX_O_CFGUP0x0008
 #define BQ27XXX_O_RAM  0x0010
+#define BQ27Z561_O_BITS0x0020
 
 #define BQ27XXX_DATA(ref, key, opt) {  \
.opts = (opt),  \
@@ -816,6 +864,7 @@ static struct {
[BQ27426]   = BQ27XXX_DATA(bq27426,   0x80008000, BQ27XXX_O_UTOT | 
BQ27XXX_O_CFGUP | BQ27XXX_O_RAM),
[BQ27441]   = BQ27XXX_DATA(bq27441,   0x80008000, BQ27XXX_O_UTOT | 
BQ27XXX_O_CFGUP | BQ27XXX_O_RAM),
[BQ27621]   = BQ27XXX_DATA(bq27621,   0x80008000, BQ27XXX_O_UTOT | 
BQ27XXX_O_CFGUP | BQ27XXX_O_RAM),
+   [BQ27Z561]  = BQ27XXX_DATA(bq27z561,  0 , BQ27Z561_O_BITS),
 };
 
 static DEFINE_MUTEX(bq27xxx_list_lock);
@@ -1551,6 +1600,8 @@ static bool bq27xxx_battery_dead(struct 
bq27xxx_device_info *di, u16 flags)
 {
if (di->opts & BQ27XXX_O_ZERO)
return flags & (BQ27000_FLAG_EDV1 | BQ27000_FLAG_EDVF);
+   else if (di->opts & BQ27Z561_O_BITS)
+   return flags & 

Re: [PATCH][next] drm: xln: fix spelling mistake "failes" -> "failed"

[Hyun Kwon]

Hi Colin,

Thanks for the patch.

On Tue, Jul 28, 2020 at 03:37:39PM -0700, Laurent Pinchart wrote:
> Hi Colin,
> 
> Thank you for the patch.
> 
> On Fri, Jul 24, 2020 at 12:12:58PM +0100, Colin King wrote:
> > From: Colin Ian King 
> > 
> > There is a spelling mistake in a dev_dbg messages. Fix it.
> 
> There is a spelling mistake in the commit message, s/xln/xlnx/ ;-)
> 
> > Signed-off-by: Colin Ian King 
> 
> Reviewed-by: Laurent Pinchart 
> 

Reviewed-by: Hyun Kwon 

I'll fix the commit message and commit this change to drm-misc-next-fixes soon.

Thanks,
-hyun

> > ---
> >  drivers/gpu/drm/xlnx/zynqmp_dp.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/xlnx/zynqmp_dp.c 
> > b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > index 821f7a71e182..0e1c818746eb 100644
> > --- a/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > +++ b/drivers/gpu/drm/xlnx/zynqmp_dp.c
> > @@ -1308,7 +1308,7 @@ zynqmp_dp_connector_detect(struct drm_connector 
> > *connector, bool force)
> > ret = drm_dp_dpcd_read(>aux, 0x0, dp->dpcd,
> >sizeof(dp->dpcd));
> > if (ret < 0) {
> > -   dev_dbg(dp->dev, "DPCD read failes");
> > +   dev_dbg(dp->dev, "DPCD read failed");
> > goto disconnected;
> > }
> >  
> 
> -- 
> Regards,
> 
> Laurent Pinchart

[PATCH v6 4/4] power: supply: bq27xxx_battery: Add the BQ28z610 Battery monitor

[Dan Murphy]

Add the Texas Instruments BQ28z610 battery monitor.
The register address map is laid out the same as compared to other
devices within the file.

The battery status register bits are similar to the bq27z561 but they
are different compared to other fuel gauge devices within this file.

Signed-off-by: Dan Murphy 
---
 drivers/power/supply/bq27xxx_battery.c | 42 ++
 drivers/power/supply/bq27xxx_battery_i2c.c |  2 ++
 include/linux/power/bq27xxx_battery.h  |  1 +
 3 files changed, 45 insertions(+)

diff --git a/drivers/power/supply/bq27xxx_battery.c 
b/drivers/power/supply/bq27xxx_battery.c
index a05b9a2d112d..a123f6e21f08 100644
--- a/drivers/power/supply/bq27xxx_battery.c
+++ b/drivers/power/supply/bq27xxx_battery.c
@@ -44,6 +44,7 @@
  * https://www.ti.com/product/bq27441-g1
  * https://www.ti.com/product/bq27621-g1
  * https://www.ti.com/product/bq27z561
+ * https://www.ti.com/product/bq28z610
  */
 
 #include 
@@ -462,6 +463,26 @@ static u8
[BQ27XXX_REG_DCAP] = 0x3c,
[BQ27XXX_REG_AP] = 0x22,
BQ27XXX_DM_REG_ROWS,
+   },
+   bq28z610_regs[BQ27XXX_REG_MAX] = {
+   [BQ27XXX_REG_CTRL] = 0x00,
+   [BQ27XXX_REG_TEMP] = 0x06,
+   [BQ27XXX_REG_INT_TEMP] = INVALID_REG_ADDR,
+   [BQ27XXX_REG_VOLT] = 0x08,
+   [BQ27XXX_REG_AI] = 0x14,
+   [BQ27XXX_REG_FLAGS] = 0x0a,
+   [BQ27XXX_REG_TTE] = 0x16,
+   [BQ27XXX_REG_TTF] = 0x18,
+   [BQ27XXX_REG_TTES] = INVALID_REG_ADDR,
+   [BQ27XXX_REG_TTECP] = INVALID_REG_ADDR,
+   [BQ27XXX_REG_NAC] = INVALID_REG_ADDR,
+   [BQ27XXX_REG_FCC] = 0x12,
+   [BQ27XXX_REG_CYCT] = 0x2a,
+   [BQ27XXX_REG_AE] = 0x22,
+   [BQ27XXX_REG_SOC] = 0x2c,
+   [BQ27XXX_REG_DCAP] = 0x3c,
+   [BQ27XXX_REG_AP] = 0x22,
+   BQ27XXX_DM_REG_ROWS,
};
 
 static enum power_supply_property bq27000_props[] = {
@@ -717,6 +738,25 @@ static enum power_supply_property bq27z561_props[] = {
POWER_SUPPLY_PROP_MANUFACTURER,
 };
 
+static enum power_supply_property bq28z610_props[] = {
+   POWER_SUPPLY_PROP_STATUS,
+   POWER_SUPPLY_PROP_PRESENT,
+   POWER_SUPPLY_PROP_VOLTAGE_NOW,
+   POWER_SUPPLY_PROP_CURRENT_NOW,
+   POWER_SUPPLY_PROP_CAPACITY,
+   POWER_SUPPLY_PROP_CAPACITY_LEVEL,
+   POWER_SUPPLY_PROP_TEMP,
+   POWER_SUPPLY_PROP_TIME_TO_EMPTY_NOW,
+   POWER_SUPPLY_PROP_TIME_TO_FULL_NOW,
+   POWER_SUPPLY_PROP_TECHNOLOGY,
+   POWER_SUPPLY_PROP_CHARGE_FULL,
+   POWER_SUPPLY_PROP_CHARGE_FULL_DESIGN,
+   POWER_SUPPLY_PROP_CYCLE_COUNT,
+   POWER_SUPPLY_PROP_POWER_AVG,
+   POWER_SUPPLY_PROP_HEALTH,
+   POWER_SUPPLY_PROP_MANUFACTURER,
+};
+
 struct bq27xxx_dm_reg {
u8 subclass_id;
u8 offset;
@@ -813,6 +853,7 @@ static struct bq27xxx_dm_reg bq27621_dm_regs[] = {
 #endif
 
 #define bq27z561_dm_regs 0
+#define bq28z610_dm_regs 0
 
 #define BQ27XXX_O_ZERO 0x0001
 #define BQ27XXX_O_OTDC 0x0002 /* has OTC/OTD overtemperature flags */
@@ -865,6 +906,7 @@ static struct {
[BQ27441]   = BQ27XXX_DATA(bq27441,   0x80008000, BQ27XXX_O_UTOT | 
BQ27XXX_O_CFGUP | BQ27XXX_O_RAM),
[BQ27621]   = BQ27XXX_DATA(bq27621,   0x80008000, BQ27XXX_O_UTOT | 
BQ27XXX_O_CFGUP | BQ27XXX_O_RAM),
[BQ27Z561]  = BQ27XXX_DATA(bq27z561,  0 , BQ27Z561_O_BITS),
+   [BQ28Z610]  = BQ27XXX_DATA(bq28z610,  0 , BQ27Z561_O_BITS),
 };
 
 static DEFINE_MUTEX(bq27xxx_list_lock);
diff --git a/drivers/power/supply/bq27xxx_battery_i2c.c 
b/drivers/power/supply/bq27xxx_battery_i2c.c
index 15f4e75786ab..ab02456d69e5 100644
--- a/drivers/power/supply/bq27xxx_battery_i2c.c
+++ b/drivers/power/supply/bq27xxx_battery_i2c.c
@@ -254,6 +254,7 @@ static const struct i2c_device_id bq27xxx_i2c_id_table[] = {
{ "bq27441", BQ27441 },
{ "bq27621", BQ27621 },
{ "bq27z561", BQ27Z561 },
+   { "bq28z610", BQ28Z610 },
{},
 };
 MODULE_DEVICE_TABLE(i2c, bq27xxx_i2c_id_table);
@@ -288,6 +289,7 @@ static const struct of_device_id 
bq27xxx_battery_i2c_of_match_table[] = {
{ .compatible = "ti,bq27441" },
{ .compatible = "ti,bq27621" },
{ .compatible = "ti,bq27z561" },
+   { .compatible = "ti,bq28z610" },
{},
 };
 MODULE_DEVICE_TABLE(of, bq27xxx_battery_i2c_of_match_table);
diff --git a/include/linux/power/bq27xxx_battery.h 
b/include/linux/power/bq27xxx_battery.h
index 1f6ea5d5063d..987d9652aa4e 100644
--- a/include/linux/power/bq27xxx_battery.h
+++ b/include/linux/power/bq27xxx_battery.h
@@ -31,6 +31,7 @@ enum bq27xxx_chip {
BQ27441,
BQ27621,
BQ27Z561,
+   BQ28Z610,
 };
 
 struct bq27xxx_device_info;
-- 
2.28.0

[PATCH v6 1/4] dt-bindings: power: Add BQ27Z561 compatible

[Dan Murphy]

Add the Texas Instruments bq27z561 battery monitor to the bq27xxx
binding.

Acked-by: Rob Herring 
Signed-off-by: Dan Murphy 
---
 Documentation/devicetree/bindings/power/supply/bq27xxx.yaml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml 
b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml
index 03d1020a2e47..0aa33590ac24 100644
--- a/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml
+++ b/Documentation/devicetree/bindings/power/supply/bq27xxx.yaml
@@ -49,6 +49,7 @@ properties:
   - ti,bq27426
   - ti,bq27441
   - ti,bq27621
+  - ti,bq27z561
 
   reg:
 maxItems: 1
-- 
2.28.0

Re: Kernel panic - not syncing: IO-APIC + timer doesn't work!

[Tom Lendacky]

On 7/29/20 4:50 AM, Thomas Gleixner wrote:
> Scott,
> 
> Scott Branden  writes:
>> On 2020-07-28 1:22 a.m., Thomas Gleixner wrote:
>>> Scott Branden  writes:
 Bios now updated to latest.  Same kernel panic issue.  Log below.

 I think it is related to power cycling quickly.
 Should APIC work if PC power cycled in a few seconds or is that the
 problem?
>>> Yes, emphasis on should. Just to clarify, if you reboot it works and
>>> cold start works as well if power was off long enough?
>>>
>> So far I have only been able to reproduce the issue by cold start with power 
>> off for only a few seconds
>> before re-powering the system.  It has not failed via reboot yet that I 
>> remember.
>> Will have to keep my eye on whether using reboot is an issue or not.
>> And also keeping power off longer when doing a cold start.
> 
> Weird.
> 
>> Please find attached the failed console log with ignore_loglevel.
> 
> Aside of the differences caused by the BIOS update there is nothing
> related to the APIC/IO-APIC setup which is different between the working
> and failing boot.
> 
> TBH, I have no idea what's going wrong there. Maybe Tom has one.

I asked around and was told this is most likely the motherboard has not
decayed its DC rails. So it's quite possible that keeping it powered off
for a longer period of time before powering back on may help.

Thanks,
Tom

> 
> Thanks,
> 
> tglx
> 

Re: [PATCH] scsi: sd: add runtime pm to open / release

[James Bottomley]

On Wed, 2020-07-29 at 14:25 -0400, Alan Stern wrote:
> On Wed, Jul 29, 2020 at 06:43:48PM +0200, Martin Kepplinger wrote:
[...]
> > > > --- a/drivers/scsi/scsi_error.c
> > > > +++ b/drivers/scsi/scsi_error.c
> > > > @@ -554,16 +554,8 @@ int scsi_check_sense(struct scsi_cmnd
> > > > *scmd)
> > > >  * so that we can deal with it there.
> > > >  */
> > > > if (scmd->device->expecting_cc_ua) {
> > > > -   /*
> > > > -* Because some device does not queue
> > > > unit
> > > > -* attentions correctly, we carefully
> > > > check
> > > > -* additional sense code and qualifier
> > > > so as
> > > > -* not to squash media change unit
> > > > attention.
> > > > -*/
> > > > -   if (sshdr.asc != 0x28 || sshdr.ascq !=
> > > > 0x00)
> > > > {
> > > > -   scmd->device->expecting_cc_ua =
> > > > 0;
> > > > -   return NEEDS_RETRY;
> > > > -   }
> > > > +   scmd->device->expecting_cc_ua = 0;
> > > > +   return NEEDS_RETRY;
> > > 
> > > Well, yes, but you can't do this because it would lose us media
> > > change events in the non-suspend/resume case which we really
> > > don't want.  That's why I was suggesting a new flag.
> > > 
> > > James
> > 
> > also if I set expecting_cc_ua in resume() only, like I did?
> 
> That wouldn't make any difference.  The information sent by your
> card reader has sshdr.asc == 0x28 and sshdr.ascq == 0x00 (you can see
> it in the log).  So because of the code here in scsi_check_sense(),
> which you can't change, the Unit Attention sent by the card reader
> would not be  retried even if you do set the flag in resume().

But if we had a new flag, like expecting_media_change, you could set
that in resume and we could condition the above test in the code on it
and reset it and do a retry if it gets set.  I'm not saying we have to
do it this way, but it sounds like we have to do something in the
kernel, so I think the flag will become necessary but there might be a
bit of policy based dance around how it gets set in the kernel (to
avoid losing accurate media change events).

James

Re: Should perf version match kernel version?

[Arnaldo Carvalho de Melo]

Em Wed, Jul 29, 2020 at 08:57:04PM +0300, Vitaly Chikunov escreveu:
> On Wed, Jul 29, 2020 at 01:27:32PM -0300, Arnaldo Carvalho de Melo wrote:
> > On July 29, 2020 1:02:20 PM GMT-03:00, pet...@infradead.org wrote:
> > >On Wed, Jul 29, 2020 at 06:56:47PM +0300, Vitaly Chikunov wrote:
> > >> It seems that most distros try to have perf version to match with
> > >> running kernel version. Is is requirement? Would it be better to have
> > >> single perf from kernel mainline to work with any (older) kernel
> > >> version?

> > >> We have different kernel versions in ALT Linux (stable for 4.19, 5.4,
> > >> and 5.7) and I want to understand if we should have three perfs or
> > >> single package will be enough.

> > >We strive to have it all compatible, older perf should work on newer
> > >kernel and newer perf should work on older kernel.

> > >How well it's all tested is another.

> > >Personally I often use a very old perf.

> > Yeah, never was a requirement, if you find some problem using a new perf on 
> > an old kernel or the other way around, please report.
> 
> That's great to know. Thanks for the answers!

Having said that, from time to time there are new features such as, say
LBR callgraph stitching, there are kernel and tooling components, so its
important to try and have the latest perf, but yeah, as you said, one
perf package is enough, just keep it uptodate :-)

For other features such as the metric work with 'perf stat', its purely
userspace, and sometimes its purely kernel space, no lockstep.

- Arnaldo

Re: [PATCH v5 2/4] power: supply: bq27xxx_battery: Add the BQ27z561 Battery monitor

[Dan Murphy]

Sebastian

On 7/29/20 11:56 AM, Sebastian Reichel wrote:

Hi,

On Wed, Jul 29, 2020 at 10:55:54AM -0500, Dan Murphy wrote:

+<<< HEAD

Need to remove this artifact from a rebase.

Not sure how this got here as it does not appear in my source.

You don't see it in your source, since you removed it in patch 4.


OK I have v6 ready but I noticed a lot of checkpatch issues.

total: 20 errors, 8 warnings, 1923 lines checked

So I will submit v6 and fix the style issues in a follow up patch

Dan



-- Sebastian

Re: [PATCH] KVM: x86: Deflect unknown MSR accesses to user space

[Jim Mattson]

On Wed, Jul 29, 2020 at 2:06 AM Alexander Graf  wrote:
>
>
>
> On 28.07.20 19:13, Jim Mattson wrote:

> > This sounds similar to Peter Hornyack's RFC from 5 years ago:
> > https://www.mail-archive.com/kvm@vger.kernel.org/msg124448.html.
>
> Yeah, looks very similar. Do you know the history why it never got
> merged? I couldn't spot a non-RFC version of this on the ML.

I believe Peter got frustrated with all of the pushback he was
getting, and he moved on to other things. While Google still uses that
code, Aaron's new approach should give us equivalent functionality
without having to comment out the MSRs that kvm previously didn't know
about, and which we still want redirected to userspace.

> > It seems unlikely that userspace is going to know what to do with a
> > large number of MSRs. I suspect that a small enumerated list will
> > suffice. In fact, +Aaron Lewis is working on upstreaming a local
> > Google patch set that does just that.
>
> I tend to disagree on that sentiment. One of the motivations behind this
> patch is to populate invalid MSR accesses into user space, to move logic
> like "ignore_msrs"[1] into user space. This is not very useful for the
> cloud use case, but it does come in handy when you want to have VMs that
> can handle unimplemented MSRs in parallel to ones that do not.
>
> So whatever we implement, I would ideally want a mechanism at the end of
> the day that allows me to "trap the rest" into user space.

I do think "the rest" should be explicitly specified, so that
userspace doesn't get surprises when kvm evolves. Maybe this can be
done using the allow-list you refer to later, along with a specified
action for disallowed MSRs: (1) raise #GP, (2) ignore, or (3) exit to
userspace. This actually seems orthogonal to what Aaron is working on,
which is to request that specific MSR accesses exit to userspace. But,
at least the plumbing for {RD,WR}MSR completion when coming back from
userspace can be leveraged by both.

Re: [PATCH] scsi: sd: add runtime pm to open / release

[Alan Stern]

On Wed, Jul 29, 2020 at 06:43:48PM +0200, Martin Kepplinger wrote:
> 
> 
> Am 29. Juli 2020 17:44:42 MESZ schrieb James Bottomley 
> :
> >On Wed, 2020-07-29 at 17:40 +0200, Martin Kepplinger wrote:
> >> On 29.07.20 16:53, James Bottomley wrote:
> >> > On Wed, 2020-07-29 at 07:46 -0700, James Bottomley wrote:
> >> > > On Wed, 2020-07-29 at 10:32 -0400, Alan Stern wrote:
> >[...]
> >> > > > This error report comes from the SCSI layer, not the block
> >> > > > layer.
> >> > > 
> >> > > That sense code means "NOT READY TO READY CHANGE, MEDIUM MAY HAVE
> >> > > CHANGED" so it sounds like it something we should be
> >> > > ignoring.  Usually this signals a problem, like you changed the
> >> > > medium manually (ejected the CD).  But in this case you can tell
> >> > > us to expect this by setting
> >> > > 
> >> > > sdev->expecting_cc_ua
> >> > > 
> >> > > And we'll retry.  I think you need to set this on all resumed
> >> > > devices.
> >> > 
> >> > Actually, it's not quite that easy, we filter out this ASC/ASCQ
> >> > combination from the check because we should never ignore medium
> >> > might have changed events on running devices.  We could ignore it
> >> > if we had a flag to say the power has been yanked (perhaps an
> >> > additional sdev flag you set on resume) but we would still miss the
> >> > case where you really had powered off the drive and then changed
> >> > the media ... if you can regard this as the user's problem, then we
> >> > might have a solution.
> >> > 
> >> > James
> >> >  
> >> 
> >> oh I see what you mean now, thanks for the ellaboration.
> >> 
> >> if I do the following change, things all look normal and runtime pm
> >> works. I'm not 100% sure if just setting expecting_cc_ua in resume()
> >> is "correct" but that looks like it is what you're talking about:
> >> 
> >> (note that this is of course with the one block layer diff applied
> >> that Alan posted a few emails back)
> >> 
> >> 
> >> --- a/drivers/scsi/scsi_error.c
> >> +++ b/drivers/scsi/scsi_error.c
> >> @@ -554,16 +554,8 @@ int scsi_check_sense(struct scsi_cmnd *scmd)
> >>  * so that we can deal with it there.
> >>  */
> >> if (scmd->device->expecting_cc_ua) {
> >> -   /*
> >> -* Because some device does not queue unit
> >> -* attentions correctly, we carefully check
> >> -* additional sense code and qualifier so as
> >> -* not to squash media change unit attention.
> >> -*/
> >> -   if (sshdr.asc != 0x28 || sshdr.ascq != 0x00)
> >> {
> >> -   scmd->device->expecting_cc_ua = 0;
> >> -   return NEEDS_RETRY;
> >> -   }
> >> +   scmd->device->expecting_cc_ua = 0;
> >> +   return NEEDS_RETRY;
> >
> >Well, yes, but you can't do this because it would lose us media change
> >events in the non-suspend/resume case which we really don't want. 
> >That's why I was suggesting a new flag.
> >
> >James
> 
> also if I set expecting_cc_ua in resume() only, like I did?

That wouldn't make any difference.  The information sent by your card 
reader has sshdr.asc == 0x28 and sshdr.ascq == 0x00 (you can see it in 
the log).  So because of the code here in scsi_check_sense(), which you 
can't change, the Unit Attention sent by the card reader would not be 
retried even if you do set the flag in resume().

Alan Stern

include/linux/spinlock.h:383:9: sparse: sparse: context imbalance in 'ip_set_test' - unexpected unlock

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   6ba1b005ffc388c2aeaddae20da29e4810dea298
commit: f66ee0410b1c3481ee75e5db9b34547b4d582465 netfilter: ipset: Fix "INFO: 
rcu detected stall in hash_xxx" reports
date:   5 months ago
config: m68k-randconfig-s031-20200729 (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
# apt-get install sparse
# sparse version: v0.6.2-97-gee4aea9a-dirty
git checkout f66ee0410b1c3481ee75e5db9b34547b4d582465
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross C=1 
CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=m68k 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 


sparse warnings: (new ones prefixed by >>)

   net/netfilter/ipset/ip_set_core.c: note: in included file (through 
include/linux/seqlock.h, include/linux/time.h, include/linux/stat.h, ...):
>> include/linux/spinlock.h:383:9: sparse: sparse: context imbalance in 
>> 'ip_set_test' - unexpected unlock
>> include/linux/spinlock.h:383:9: sparse: sparse: context imbalance in 
>> 'ip_set_add' - unexpected unlock
>> include/linux/spinlock.h:383:9: sparse: sparse: context imbalance in 
>> 'ip_set_del' - unexpected unlock
>> include/linux/spinlock.h:383:9: sparse: sparse: context imbalance in 
>> 'ip_set_flush_set' - unexpected unlock
>> include/linux/spinlock.h:383:9: sparse: sparse: context imbalance in 
>> 'call_ad' - unexpected unlock

vim +/ip_set_test +383 include/linux/spinlock.h

c2f21ce2e31286 Thomas Gleixner 2009-12-02  380  
3490565b633c70 Denys Vlasenko  2015-07-13  381  static __always_inline void 
spin_unlock_bh(spinlock_t *lock)
c2f21ce2e31286 Thomas Gleixner 2009-12-02  382  {
c2f21ce2e31286 Thomas Gleixner 2009-12-02 @383  
raw_spin_unlock_bh(>rlock);
c2f21ce2e31286 Thomas Gleixner 2009-12-02  384  }
c2f21ce2e31286 Thomas Gleixner 2009-12-02  385  

:: The code at line 383 was first introduced by commit
:: c2f21ce2e31286a0a32f8da0a7856e9ca1122ef3 locking: Implement new 
raw_spinlock

:: TO: Thomas Gleixner 
:: CC: Thomas Gleixner 

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

KASAN: use-after-free Write in __alloc_skb (3)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:68845a55 Merge branch 'akpm' into master (patches from And..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10f85f7890
kernel config:  https://syzkaller.appspot.com/x/.config?x=f87a5e4232fdb267
dashboard link: https://syzkaller.appspot.com/bug?extid=7569bc4cd6fad9f1e551
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=1517668c90
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=1028056490

Bisection is inconclusive: the issue happens on the oldest tested release.

bisection log:  https://syzkaller.appspot.com/x/bisect.txt?x=13dc473c90
final oops: https://syzkaller.appspot.com/x/report.txt?x=103c473c90
console output: https://syzkaller.appspot.com/x/log.txt?x=17dc473c90

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+7569bc4cd6fad9f1e...@syzkaller.appspotmail.com

==
BUG: KASAN: use-after-free in memset include/linux/string.h:391 [inline]
BUG: KASAN: use-after-free in __alloc_skb+0x2f6/0x550 net/core/skbuff.c:239
Write of size 32 at addr 8881a7463f40 by task swapper/1/0

CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.8.0-rc6-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x18f/0x20d lib/dump_stack.c:118
 print_address_description.constprop.0.cold+0xae/0x436 mm/kasan/report.c:383
 __kasan_report mm/kasan/report.c:513 [inline]
 kasan_report.cold+0x1f/0x37 mm/kasan/report.c:530
 check_memory_region_inline mm/kasan/generic.c:186 [inline]
 check_memory_region+0x13d/0x180 mm/kasan/generic.c:192
 memset+0x20/0x40 mm/kasan/common.c:84
 memset include/linux/string.h:391 [inline]
 __alloc_skb+0x2f6/0x550 net/core/skbuff.c:239
 alloc_skb include/linux/skbuff.h:1083 [inline]
 alloc_skb_with_frags+0x92/0x570 net/core/skbuff.c:5770
 sock_alloc_send_pskb+0x72a/0x880 net/core/sock.c:2356
 mld_newpack+0x1e0/0x770 net/ipv6/mcast.c:1606
 add_grhead+0x265/0x330 net/ipv6/mcast.c:1710
 add_grec+0xe2c/0x1090 net/ipv6/mcast.c:1841
 mld_send_cr net/ipv6/mcast.c:1967 [inline]
 mld_ifc_timer_expire+0x596/0xf10 net/ipv6/mcast.c:2474
 call_timer_fn+0x1ac/0x760 kernel/time/timer.c:1415
 expire_timers kernel/time/timer.c:1460 [inline]
 __run_timers.part.0+0x54c/0xa20 kernel/time/timer.c:1784
 __run_timers kernel/time/timer.c:1756 [inline]
 run_timer_softirq+0xae/0x1a0 kernel/time/timer.c:1797
 __do_softirq+0x34c/0xa60 kernel/softirq.c:292
 asm_call_on_stack+0xf/0x20 arch/x86/entry/entry_64.S:711
 
 __run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline]
 run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline]
 do_softirq_own_stack+0x111/0x170 arch/x86/kernel/irq_64.c:77
 invoke_softirq kernel/softirq.c:387 [inline]
 __irq_exit_rcu kernel/softirq.c:417 [inline]
 irq_exit_rcu+0x229/0x270 kernel/softirq.c:429
 sysvec_apic_timer_interrupt+0x54/0x120 arch/x86/kernel/apic/apic.c:1091
 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:585
RIP: 0010:native_safe_halt+0xe/0x10 arch/x86/include/asm/irqflags.h:61
Code: ff 4c 89 ef e8 33 c9 ca f9 e9 8e fe ff ff 48 89 df e8 26 c9 ca f9 eb 8a 
cc cc cc cc e9 07 00 00 00 0f 00 2d 74 5f 60 00 fb f4  90 e9 07 00 00 00 0f 
00 2d 64 5f 60 00 f4 c3 cc cc 55 53 e8 29
RSP: 0018:c9d3fc88 EFLAGS: 0293
RAX:  RBX:  RCX: 
RDX: 8880a9636340 RSI: 87e85c48 RDI: 87e85c1e
RBP: 8880a68e7864 R08:  R09: 
R10: 0001 R11:  R12: 8880a68e7864
R13: 1920001a7f9b R14: 8880a68e7865 R15: 0001
 arch_safe_halt arch/x86/include/asm/paravirt.h:150 [inline]
 acpi_safe_halt+0x8d/0x110 drivers/acpi/processor_idle.c:111
 acpi_idle_do_entry+0x15c/0x1b0 drivers/acpi/processor_idle.c:525
 acpi_idle_enter+0x3f9/0xab0 drivers/acpi/processor_idle.c:651
 cpuidle_enter_state+0xff/0x960 drivers/cpuidle/cpuidle.c:235
 cpuidle_enter+0x4a/0xa0 drivers/cpuidle/cpuidle.c:346
 call_cpuidle kernel/sched/idle.c:126 [inline]
 cpuidle_idle_call kernel/sched/idle.c:214 [inline]
 do_idle+0x431/0x6d0 kernel/sched/idle.c:276
 cpu_startup_entry+0x14/0x20 kernel/sched/idle.c:372
 start_secondary+0x2b3/0x370 arch/x86/kernel/smpboot.c:268
 secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:243

The buggy address belongs to the page:
page:ea00069d18c0 refcount:0 mapcount:0 mapping: index:0x0
flags: 0x57ffe00()
raw: 057ffe00 ea00069d18c8 ea00069d18c8 
raw:    
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 8881a7463e00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Re: [PATCH RESEND 1/2] scsi: megaraid: Remove pci-dma-compat wrapper APIs.

[Suraj Upadhyay]

On Tue, Jul 28, 2020 at 11:40:12PM -0400, Martin K. Petersen wrote:
> 
> Hello Suraj!
> 
> > The legacy API wrappers in include/linux/pci-dma-compat.h
> > should go away as it creates unnecessary midlayering
> > for include/linux/dma-mapping.h APIs, instead use dma-mapping.h
> > APIs directly.
> 
> Instead of all these individual patches, please submit a combined patch
> series for the changes under SCSI.
> 
> Each patch should fix a single driver. Please don't mix changes to
> completely different drivers such as hpsa and dc395x in a single
> commit. And please don't split semantically identical changes to the
> same driver into multiple commits (megaraid [2/2]).
> 
> Thank you!
> 
Hii Martin,
Thanks for your response.
I sent a patch series for the above changes.

Thanks,

Suraj Upadhyay
> -- 
> Martin K. PetersenOracle Linux Engineering

Re: [PATCH] scsi: sd: add runtime pm to open / release

[Douglas Gilbert]

On 2020-07-29 10:32 a.m., Alan Stern wrote:

On Wed, Jul 29, 2020 at 04:12:22PM +0200, Martin Kepplinger wrote:

On 28.07.20 22:02, Alan Stern wrote:

On Tue, Jul 28, 2020 at 09:02:44AM +0200, Martin Kepplinger wrote:

Hi Alan,

Any API cleanup is of course welcome. I just wanted to remind you that
the underlying problem: broken block device runtime pm. Your initial
proposed fix "almost" did it and mounting works but during file access,
it still just looks like a runtime_resume is missing somewhere.


Well, I have tested that proposed fix several times, and on my system
it's working perfectly.  When I stop accessing a drive it autosuspends,
and when I access it again it gets resumed and works -- as you would
expect.


that's weird. when I mount, everything looks good, "sda1". But as soon
as I cd to the mountpoint and do "ls" (on another SD card "ls" works but
actual file reading leads to the exact same errors), I get:

[   77.474632] sd 0:0:0:0: [sda] tag#0 UNKNOWN(0x2003) Result:
hostbyte=0x00 driverbyte=0x08 cmd_age=0s
[   77.474647] sd 0:0:0:0: [sda] tag#0 Sense Key : 0x6 [current]
[   77.474655] sd 0:0:0:0: [sda] tag#0 ASC=0x28 ASCQ=0x0
[   77.474667] sd 0:0:0:0: [sda] tag#0 CDB: opcode=0x28 28 00 00 00 60
40 00 00 01 00


This error report comes from the SCSI layer, not the block layer.


SCSI's first 11 byte command! I'm guessing the first byte is being
repeated and it's actually:
28 00 00 00 60 40 00 00 01 00  [READ(10)]

That should be fixed. It should be something like: "...CDB in hex: 28 00 ...".

Doug Gilbert


[   77.474678] blk_update_request: I/O error, dev sda, sector 24640 op
0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[   77.485836] sd 0:0:0:0: [sda] tag#0 device offline or changed
[   77.491628] blk_update_request: I/O error, dev sda, sector 24641 op
0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[   77.502275] sd 0:0:0:0: [sda] tag#0 device offline or changed
[   77.508051] blk_update_request: I/O error, dev sda, sector 24642 op
0x0:(READ) flags 0x80700 phys_seg 1 prio class 0
[   77.518651] sd 0:0:0:0: [sda] tag#0 device offline or changed
(...)
[   77.947653] sd 0:0:0:0: [sda] tag#0 device offline or changed
[   77.953434] FAT-fs (sda1): Directory bread(block 16448) failed
[   77.959333] sd 0:0:0:0: [sda] tag#0 device offline or changed
[   77.965118] FAT-fs (sda1): Directory bread(block 16449) failed
[   77.971014] sd 0:0:0:0: [sda] tag#0 device offline or changed
[   77.976802] FAT-fs (sda1): Directory bread(block 16450) failed
[   77.982698] sd 0:0:0:0: [sda] tag#0 device offline or changed
(...)
[   78.384929] FAT-fs (sda1): Filesystem has been set read-only
[  103.070973] sd 0:0:0:0: [sda] tag#0 device offline or changed
[  103.076751] print_req_error: 118 callbacks suppressed
[  103.076760] blk_update_request: I/O error, dev sda, sector 9748 op
0x1:(WRITE) flags 0x10 phys_seg 1 prio class 0
[  103.087428] Buffer I/O error on dev sda1, logical block 1556, lost
async page write
[  103.095309] sd 0:0:0:0: [sda] tag#0 device offline or changed
[  103.101123] blk_update_request: I/O error, dev sda, sector 17162 op
0x1:(WRITE) flags 0x10 phys_seg 1 prio class 0
[  103.111883] Buffer I/O error on dev sda1, logical block 8970, lost
async page write


I can't tell why you're getting that error.  In one of my tests the
device returned the same kind of error status (Sense Key = 6, ASC =
0x28) but the operation was then retried successfully.  Perhaps the
problem lies in the device you are testing.


As we need to have that working at some point, I might look into it, but
someone who has experience in the block layer can surely do it more
efficiently.


I suspect that any problems you still face are caused by something else.



I then formatted sda1 to ext2 (on the runtime suspend system testing
your patch) and that seems to have worked!

Again accessing the mountpoint then yield the very same "device offline
or changed" errors.

What kind of device are you testing? You should be easily able to
reproduce this using an "sd" device.


I tested two devices: a SanDisk Cruzer USB flash drive and a
g-mass-storage gadget running under dummy-hcd.  They each showed up as
/dev/sdb on my system.

I haven't tried testing with an SD card.  If you have any specific
sequence of commands you would like me to run, let me know.


The problems must lie in the different other drivers we use I guess.


Or the devices.  Have you tried testing with a USB flash drive?

Alan Stern

[PATCH 7/7] scsi: megaraid: Remove pci-dma-compat wrapper APIs

[Suraj Upadhyay]

The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.

The patch has been generated with the coccinelle script below.
And has been hand modified to replace each GFP_ with a correct
flag depending upon the context.
Compile tested.


- PCI_DMA_BIDIRECTIONAL
+ DMA_BIDIRECTIONAL


- PCI_DMA_TODEVICE
+ DMA_TO_DEVICE


- PCI_DMA_FROMDEVICE
+ DMA_FROM_DEVICE


- PCI_DMA_NONE
+ DMA_NONE

@@ expression E1, E2, E3; @@
- pci_alloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)

@@ expression E1, E2, E3; @@
- pci_zalloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)

@@ expression E1, E2, E3, E4; @@
- pci_free_consistent(E1, E2, E3, E4)
+ dma_free_coherent(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_map_single(E1, E2, E3, E4)
+ dma_map_single(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_single(E1, E2, E3, E4)
+ dma_unmap_single(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4, E5; @@
- pci_map_page(E1, E2, E3, E4, E5)
+ dma_map_page(>dev, E2, E3, E4, E5)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_page(E1, E2, E3, E4)
+ dma_unmap_page(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_map_sg(E1, E2, E3, E4)
+ dma_map_sg(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_sg(E1, E2, E3, E4)
+ dma_unmap_sg(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_cpu(E1, E2, E3, E4)
+ dma_sync_single_for_cpu(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_device(E1, E2, E3, E4)
+ dma_sync_single_for_device(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_cpu(E1, E2, E3, E4)
+ dma_sync_sg_for_cpu(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_device(E1, E2, E3, E4)
+ dma_sync_sg_for_device(>dev, E2, E3, E4)

@@ expression E1, E2; @@
- pci_dma_mapping_error(E1, E2)
+ dma_mapping_error(>dev, E2)

@@ expression E1, E2; @@
- pci_set_consistent_dma_mask(E1, E2)
+ dma_set_coherent_mask(>dev, E2)

@@ expression E1, E2; @@
- pci_set_dma_mask(E1, E2)
+ dma_set_mask(>dev, E2)

Signed-off-by: Suraj Upadhyay 
---
 drivers/scsi/megaraid.c | 192 +---
 1 file changed, 102 insertions(+), 90 deletions(-)

diff --git a/drivers/scsi/megaraid.c b/drivers/scsi/megaraid.c
index 0484ee52ae80..e24c87a41eeb 100644
--- a/drivers/scsi/megaraid.c
+++ b/drivers/scsi/megaraid.c
@@ -133,8 +133,10 @@ mega_setup_mailbox(adapter_t *adapter)
 {
unsigned long   align;
 
-   adapter->una_mbox64 = pci_alloc_consistent(adapter->dev,
-   sizeof(mbox64_t), >una_mbox64_dma);
+   adapter->una_mbox64 = dma_alloc_coherent(>dev->dev,
+sizeof(mbox64_t),
+>una_mbox64_dma,
+GFP_KERNEL);
 
if( !adapter->una_mbox64 ) return -1;

@@ -222,8 +224,9 @@ mega_query_adapter(adapter_t *adapter)
mraid_inquiry   *inq;
dma_addr_t  dma_handle;
 
-   ext_inq = pci_alloc_consistent(adapter->dev,
-   sizeof(mraid_ext_inquiry), _handle);
+   ext_inq = dma_alloc_coherent(>dev->dev,
+sizeof(mraid_ext_inquiry),
+_handle, GFP_KERNEL);
 
if( ext_inq == NULL ) return -1;
 
@@ -243,8 +246,9 @@ mega_query_adapter(adapter_t *adapter)
mega_8_to_40ld(inq, inquiry3,
(mega_product_info *)>product_info);
 
-   pci_free_consistent(adapter->dev, sizeof(mraid_ext_inquiry),
-   ext_inq, dma_handle);
+   dma_free_coherent(>dev->dev,
+ sizeof(mraid_ext_inquiry), ext_inq,
+ dma_handle);
 
} else {/*adapter supports 40ld */
adapter->flag |= BOARD_40LD;
@@ -253,9 +257,10 @@ mega_query_adapter(adapter_t *adapter)
 * get product_info, which is static information and will be
 * unchanged
 */
-   prod_info_dma_handle = pci_map_single(adapter->dev, (void *)
-   >product_info,
-   sizeof(mega_product_info), PCI_DMA_FROMDEVICE);
+   prod_info_dma_handle = dma_map_single(>dev->dev,
+ (void 
*)>product_info,
+ sizeof(mega_product_info),
+ DMA_FROM_DEVICE);
 
mbox->m_out.xferaddr = prod_info_dma_handle;
 
@@ -267,8 +272,8 @@ 

{standard input}:2272: Error: inappropriate arguments for opcode 'mpydu'

[kernel test robot]

Hi Nicolas,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   6ba1b005ffc388c2aeaddae20da29e4810dea298
commit: 602828c1aade576ac5f3fbd59b4eb014c5fc2414 __div64_const32(): improve the 
generic C version
date:   11 months ago
config: arc-randconfig-r014-20200729 (attached as .config)
compiler: arc-elf-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 602828c1aade576ac5f3fbd59b4eb014c5fc2414
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=arc 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   {standard input}: Assembler messages:
>> {standard input}:2272: Error: inappropriate arguments for opcode 'mpydu'

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

[PATCH 6/7] scsi: qla2xxx: Remove pci-dma-compat wrapper APIs.

[Suraj Upadhyay]

The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.

The patch has been generated with the coccinelle script below.
Compile tested.


- PCI_DMA_BIDIRECTIONAL
+ DMA_BIDIRECTIONAL


- PCI_DMA_TODEVICE
+ DMA_TO_DEVICE


- PCI_DMA_FROMDEVICE
+ DMA_FROM_DEVICE


- PCI_DMA_NONE
+ DMA_NONE

@@ expression E1, E2, E3; @@
- pci_alloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)

@@ expression E1, E2, E3; @@
- pci_zalloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)

@@ expression E1, E2, E3, E4; @@
- pci_free_consistent(E1, E2, E3, E4)
+ dma_free_coherent(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_map_single(E1, E2, E3, E4)
+ dma_map_single(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_single(E1, E2, E3, E4)
+ dma_unmap_single(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4, E5; @@
- pci_map_page(E1, E2, E3, E4, E5)
+ dma_map_page(>dev, E2, E3, E4, E5)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_page(E1, E2, E3, E4)
+ dma_unmap_page(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_map_sg(E1, E2, E3, E4)
+ dma_map_sg(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_sg(E1, E2, E3, E4)
+ dma_unmap_sg(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_cpu(E1, E2, E3, E4)
+ dma_sync_single_for_cpu(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_device(E1, E2, E3, E4)
+ dma_sync_single_for_device(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_cpu(E1, E2, E3, E4)
+ dma_sync_sg_for_cpu(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_device(E1, E2, E3, E4)
+ dma_sync_sg_for_device(>dev, E2, E3, E4)

@@ expression E1, E2; @@
- pci_dma_mapping_error(E1, E2)
+ dma_mapping_error(>dev, E2)

@@ expression E1, E2; @@
- pci_set_consistent_dma_mask(E1, E2)
+ dma_set_coherent_mask(>dev, E2)

@@ expression E1, E2; @@
- pci_set_dma_mask(E1, E2)
+ dma_set_mask(>dev, E2)

Signed-off-by: Suraj Upadhyay 
---
 drivers/scsi/qla2xxx/qla_os.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index 9b59f032a569..8b4e3da1de5a 100644
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -1885,7 +1885,7 @@ qla2x00_config_dma_addressing(struct qla_hw_data *ha)
if (!dma_set_mask(>pdev->dev, DMA_BIT_MASK(64))) {
/* Any upper-dword bits set? */
if (MSD(dma_get_required_mask(>pdev->dev)) &&
-   !pci_set_consistent_dma_mask(ha->pdev, DMA_BIT_MASK(64))) {
+   !dma_set_coherent_mask(>pdev->dev, DMA_BIT_MASK(64))) {
/* Ok, a 64bit DMA mask is applicable. */
ha->flags.enable_64bit_addressing = 1;
ha->isp_ops->calc_req_entries = qla2x00_calc_iocbs_64;
@@ -1895,7 +1895,7 @@ qla2x00_config_dma_addressing(struct qla_hw_data *ha)
}
 
dma_set_mask(>pdev->dev, DMA_BIT_MASK(32));
-   pci_set_consistent_dma_mask(ha->pdev, DMA_BIT_MASK(32));
+   dma_set_coherent_mask(>pdev->dev, DMA_BIT_MASK(32));
 }
 
 static void
-- 
2.17.1



signature.asc
Description: PGP signature

Re: linux-next: build failure after merge of the net-next tree

[Brian Vazquez]

Hi Stephen, thanks for reaching out and reporting the issue. I have
just sent the fix for review in net-next:
http://patchwork.ozlabs.org/project/netdev/patch/20200729181018.3221288-1-bria...@google.com/

cheers,
Brian

On Wed, Jul 29, 2020 at 4:27 AM Stephen Rothwell  wrote:
>
> Hi all,
>
> After merging the net-next tree, today's linux-next build (i386 defconfig)
> failed like this:
>
> x86_64-linux-gnu-ld: net/core/fib_rules.o: in function `fib_rules_lookup':
> fib_rules.c:(.text+0x5c6): undefined reference to `fib6_rule_match'
> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x5d8): undefined reference to 
> `fib6_rule_match'
> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x64d): undefined reference to 
> `fib6_rule_action'
> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x662): undefined reference to 
> `fib6_rule_action'
> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x67a): undefined reference to 
> `fib6_rule_suppress'
> x86_64-linux-gnu-ld: fib_rules.c:(.text+0x68d): undefined reference to 
> `fib6_rule_suppress'
>
> Caused by commit
>
>   b9aaec8f0be5 ("fib: use indirect call wrappers in the most common 
> fib_rules_ops")
>
> # CONFIG_IPV6_MULTIPLE_TABLES is not set
>
> I have reverted that commit for today.
>
> --
> Cheers,
> Stephen Rothwell

Re: [PATCH 2/6] arch: x86: Wrap TIF_IA32 checks

[Gabriel Krisman Bertazi]

Andy Lutomirski  writes:

> On Tue, Jul 28, 2020 at 9:46 PM Gabriel Krisman Bertazi
>  wrote:
>>
>> Andy Lutomirski  writes:
>>
>> > On Tue, Jul 28, 2020 at 1:22 PM Gabriel Krisman Bertazi
>> >  wrote:
>> >>
>> >> In preparation to remove TIF_IA32, add wrapper that check the process
>> >> has IA32 ABI without using the flag directly.
>> >
>> > Thank you for doing this, but let's please do it right.  There is,
>> > fundamentally, no such thing as a "process with IA32 ABI".
>>
>> Hi Andy,
>>
>> Thanks a lot for your review.
>>
>> As you can see, I'm learning my way here. Can you clarify "there is no
>> such a thing as a 'process with IA32 ABI'"?  I'm not sure if I confused
>> the terminology or if (more worrisome for me) I got the concepts wrong.
>>
>> My understanding is that TIF_IA32 marks a thread that is running under
>> the 32-bit compat mode, which would be running a 32-bit process (as in
>> compiled with -m32, for instance), while TIF_X32 marks a process running
>> under the X32 ABI.  Each process would have only one of these
>> "personalities". This is what I meant by a process with IA32 ABI (which
>> is wrong in any case).  Is there more to it, or is the problem the
>> terminology I used?
>
> There's more to it.

Thanks again for the explanation!

>> I don't have any comments on the other things you mentioned, except that
>> I need to go through them and better understand your suggestions.  Would
>> you prefer me to rework this patch series with what you suggested or is
>> this something you want to take over and do yourself?  Both ways are
>> fine by me.
>
> Please rework it :)  I have seriously limited bandwidth right now.

Will do.

-- 
Gabriel Krisman Bertazi

[PATCH 5/7] scsi: hpsa: Remove pci-dma-compat wrapper APIs.

[Suraj Upadhyay]

The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.

The patch has been generated with the coccinelle script below.
Compile tested.


- PCI_DMA_BIDIRECTIONAL
+ DMA_BIDIRECTIONAL


- PCI_DMA_TODEVICE
+ DMA_TO_DEVICE


- PCI_DMA_FROMDEVICE
+ DMA_FROM_DEVICE


- PCI_DMA_NONE
+ DMA_NONE

@@ expression E1, E2, E3; @@
- pci_alloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)

@@ expression E1, E2, E3; @@
- pci_zalloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)

@@ expression E1, E2, E3, E4; @@
- pci_free_consistent(E1, E2, E3, E4)
+ dma_free_coherent(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_map_single(E1, E2, E3, E4)
+ dma_map_single(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_single(E1, E2, E3, E4)
+ dma_unmap_single(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4, E5; @@
- pci_map_page(E1, E2, E3, E4, E5)
+ dma_map_page(>dev, E2, E3, E4, E5)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_page(E1, E2, E3, E4)
+ dma_unmap_page(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_map_sg(E1, E2, E3, E4)
+ dma_map_sg(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_sg(E1, E2, E3, E4)
+ dma_unmap_sg(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_cpu(E1, E2, E3, E4)
+ dma_sync_single_for_cpu(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_device(E1, E2, E3, E4)
+ dma_sync_single_for_device(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_cpu(E1, E2, E3, E4)
+ dma_sync_sg_for_cpu(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_device(E1, E2, E3, E4)
+ dma_sync_sg_for_device(>dev, E2, E3, E4)

@@ expression E1, E2; @@
- pci_dma_mapping_error(E1, E2)
+ dma_mapping_error(>dev, E2)

@@ expression E1, E2; @@
- pci_set_consistent_dma_mask(E1, E2)
+ dma_set_coherent_mask(>dev, E2)

@@ expression E1, E2; @@
- pci_set_dma_mask(E1, E2)
+ dma_set_mask(>dev, E2)

Signed-off-by: Suraj Upadhyay 
---
 drivers/scsi/hpsa.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/hpsa.c b/drivers/scsi/hpsa.c
index 90c36d75bf92..6be850de6f62 100644
--- a/drivers/scsi/hpsa.c
+++ b/drivers/scsi/hpsa.c
@@ -9328,10 +9328,10 @@ static int hpsa_enter_performant_mode(struct ctlr_info 
*h, u32 trans_support)
 static void hpsa_free_ioaccel1_cmd_and_bft(struct ctlr_info *h)
 {
if (h->ioaccel_cmd_pool) {
-   pci_free_consistent(h->pdev,
-   h->nr_cmds * sizeof(*h->ioaccel_cmd_pool),
-   h->ioaccel_cmd_pool,
-   h->ioaccel_cmd_pool_dhandle);
+   dma_free_coherent(>pdev->dev,
+ h->nr_cmds * sizeof(*h->ioaccel_cmd_pool),
+ h->ioaccel_cmd_pool,
+ h->ioaccel_cmd_pool_dhandle);
h->ioaccel_cmd_pool = NULL;
h->ioaccel_cmd_pool_dhandle = 0;
}
@@ -9381,10 +9381,10 @@ static void hpsa_free_ioaccel2_cmd_and_bft(struct 
ctlr_info *h)
hpsa_free_ioaccel2_sg_chain_blocks(h);
 
if (h->ioaccel2_cmd_pool) {
-   pci_free_consistent(h->pdev,
-   h->nr_cmds * sizeof(*h->ioaccel2_cmd_pool),
-   h->ioaccel2_cmd_pool,
-   h->ioaccel2_cmd_pool_dhandle);
+   dma_free_coherent(>pdev->dev,
+ h->nr_cmds * sizeof(*h->ioaccel2_cmd_pool),
+ h->ioaccel2_cmd_pool,
+ h->ioaccel2_cmd_pool_dhandle);
h->ioaccel2_cmd_pool = NULL;
h->ioaccel2_cmd_pool_dhandle = 0;
}
-- 
2.17.1



signature.asc
Description: PGP signature

Re: [PATCH v4 4/5] arm64: dts: sdm845: Add OPP tables and power-domains for venus

[Doug Anderson]

Hi,

On Tue, Jul 28, 2020 at 1:11 PM Lina Iyer  wrote:
>
> On Tue, Jul 28 2020 at 13:51 -0600, Stephen Boyd wrote:
> >Quoting Lina Iyer (2020-07-28 09:52:12)
> >> On Mon, Jul 27 2020 at 18:45 -0600, Stephen Boyd wrote:
> >> >Quoting Lina Iyer (2020-07-24 09:28:25)
> >> >> On Fri, Jul 24 2020 at 03:03 -0600, Rajendra Nayak wrote:
> >> >> >Hi Maulik/Lina,
> >> >> >
> >> >> >On 7/23/2020 11:36 PM, Stanimir Varbanov wrote:
> >> >> >>Hi Rajendra,
> >> >> >>
> >> >> >>After applying 2,3 and 4/5 patches on linaro-integration v5.8-rc2 I 
> >> >> >>see
> >> >> >>below messages on db845:
> >> >> >>
> >> >> >>qcom-venus aa0.video-codec: dev_pm_opp_set_rate: failed to find
> >> >> >>current OPP for freq 53397 (-34)
> >> >> >>
> >> >> >>^^^ This one is new.
> >> >> >>
> >> >> >>qcom_rpmh TCS Busy, retrying RPMH message send: addr=0x3
> >> >> >>
> >> >> >>^^^ and this message is annoying, can we make it pr_debug in rpmh?
> >> >> >
> >> >> How annoyingly often do you see this message?
> >> >> Usually, this is an indication of bad system state either on remote
> >> >> processors in the SoC or in Linux itself. On a smooth sailing build you
> >> >> should not see this 'warning'.
> >> >>
> >> >> >Would you be fine with moving this message to a pr_debug? Its currently
> >> >> >a pr_info_ratelimited()
> >> >> I would rather not, moving this out of sight will mask a lot serious
> >> >> issues that otherwise bring attention to the developers.
> >> >>
> >> >
> >> >I removed this warning message in my patch posted to the list[1]. If
> >> >it's a serious problem then I suppose a timeout is more appropriate, on
> >> >the order of several seconds or so and then a pr_warn() and bail out of
> >> >the async call with an error.
> >> >
> >> The warning used to capture issues that happen within a second and it
> >> helps capture system related issues. Timing out after many seconds
> >> overlooks the system issues that generally tend to resolve itself, but
> >> nevertheless need to be investigated.
> >>
> >
> >Is it correct to read "system related issues" as performance problems
> >where the thread is spinning forever trying to send a message and it
> >can't? So the problem is mostly that it's an unbounded amount of time
> >before the message is sent to rpmh and this printk helps identify those
> >situations where that is happening?
> >
> Yes, but mostly a short period of time like when other processors are in
> the middle of a restart or resource states changes have taken unusual
> amounts of time. The system will generally recover from this without
> crashing in this case. User action is investigation of the situation
> leading to these messages.

While I do agree that seeing the "TCS Busy, retrying RPMH message
send" message printed a lot was usually a sign that something was
wrong in the system (possibly someone was spamming RPMh when they
shouldn't be), it still feels like we need to remove it.
Specifically, the prints would also sometimes come up in normal usage
and always sounded a bit scary.  These types of prints always confuse
people and lead to log pollution where it's super hard to figure out
which of the various things in a log are "expected" and which ones are
relevant to whatever issue you're debugging.

Presumably we could either change that from a "info" level to "dbg"
level.  ...or we could find some other thing to check for that's a
better signal of problems.


> >Otherwise as you say above it's a bad system state where the rpmh
> >processor has gotten into a bad state like a crash? Can we recover from
> >that? Or is the only recovery a reboot of the system? Does the rpmh
> >processor reboot the system if it crashes?
> We cannot recover from such a state. The remote processor will reboot if
> it detects a failure at it's end. If the system entered a bad state, it
> is possible that RPMH requests start timing out in Linux and remote
> processor may not detect it. Hence, the timeout in rpmh_write() API. The
> advised course of action is a restart as there is no way to recover from
> this state.
>
> --Lina
>
>

[PATCH 4/7] scsi: mpt3sas: Remove pci-dma-compat wrapper APIs.

[Suraj Upadhyay]

The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.

The patch has been generated with the coccinelle script below.
Compile tested.


- PCI_DMA_BIDIRECTIONAL
+ DMA_BIDIRECTIONAL


- PCI_DMA_TODEVICE
+ DMA_TO_DEVICE


- PCI_DMA_FROMDEVICE
+ DMA_FROM_DEVICE


- PCI_DMA_NONE
+ DMA_NONE

@@ expression E1, E2, E3; @@
- pci_alloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)

@@ expression E1, E2, E3; @@
- pci_zalloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)

@@ expression E1, E2, E3, E4; @@
- pci_free_consistent(E1, E2, E3, E4)
+ dma_free_coherent(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_map_single(E1, E2, E3, E4)
+ dma_map_single(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_single(E1, E2, E3, E4)
+ dma_unmap_single(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4, E5; @@
- pci_map_page(E1, E2, E3, E4, E5)
+ dma_map_page(>dev, E2, E3, E4, E5)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_page(E1, E2, E3, E4)
+ dma_unmap_page(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_map_sg(E1, E2, E3, E4)
+ dma_map_sg(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_sg(E1, E2, E3, E4)
+ dma_unmap_sg(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_cpu(E1, E2, E3, E4)
+ dma_sync_single_for_cpu(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_device(E1, E2, E3, E4)
+ dma_sync_single_for_device(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_cpu(E1, E2, E3, E4)
+ dma_sync_sg_for_cpu(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_device(E1, E2, E3, E4)
+ dma_sync_sg_for_device(>dev, E2, E3, E4)

@@ expression E1, E2; @@
- pci_dma_mapping_error(E1, E2)
+ dma_mapping_error(>dev, E2)

@@ expression E1, E2; @@
- pci_set_consistent_dma_mask(E1, E2)
+ dma_set_coherent_mask(>dev, E2)

@@ expression E1, E2; @@
- pci_set_dma_mask(E1, E2)
+ dma_set_mask(>dev, E2)

Signed-off-by: Suraj Upadhyay 
---
 drivers/scsi/mpt3sas/mpt3sas_ctl.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c 
b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
index 43260306668c..94698ad1cad7 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c
@@ -3384,12 +3384,10 @@ host_trace_buffer_enable_store(struct device *cdev,
&&
(ioc->diag_buffer_status[MPI2_DIAG_BUF_TYPE_TRACE] &
MPT3_DIAG_BUFFER_IS_APP_OWNED)) {
-   pci_free_consistent(ioc->pdev,
-   ioc->diag_buffer_sz[
-   MPI2_DIAG_BUF_TYPE_TRACE],
-   ioc->diag_buffer[MPI2_DIAG_BUF_TYPE_TRACE],
-   ioc->diag_buffer_dma[
-   MPI2_DIAG_BUF_TYPE_TRACE]);
+   dma_free_coherent(>pdev->dev,
+ 
ioc->diag_buffer_sz[MPI2_DIAG_BUF_TYPE_TRACE],
+ 
ioc->diag_buffer[MPI2_DIAG_BUF_TYPE_TRACE],
+ 
ioc->diag_buffer_dma[MPI2_DIAG_BUF_TYPE_TRACE]);
ioc->diag_buffer[MPI2_DIAG_BUF_TYPE_TRACE] =
NULL;
}
-- 
2.17.1



signature.asc
Description: PGP signature

Re: [PATCH v3 12/19] firmware_loader: Use security_post_load_data()

[Mimi Zohar]

On Wed, 2020-07-29 at 12:29 -0400, Mimi Zohar wrote:
> On Tue, 2020-07-28 at 12:43 -0700, Kees Cook wrote:
> > On Mon, Jul 27, 2020 at 06:57:45AM -0400, Mimi Zohar wrote:
> > > On Fri, 2020-07-24 at 14:36 -0700, Kees Cook wrote:
> > > > Now that security_post_load_data() is wired up, use it instead
> > > > of the NULL file argument style of security_post_read_file(),
> > > > and update the security_kernel_load_data() call to indicate that a
> > > > security_kernel_post_load_data() call is expected.
> > > > 
> > > > Wire up the IMA check to match earlier logic. Perhaps a generalized
> > > > change to ima_post_load_data() might look something like this:
> > > > 
> > > > return process_buffer_measurement(buf, size,
> > > >   kernel_load_data_id_str(load_id),
> > > >   read_idmap[load_id] ?: FILE_CHECK,
> > > >   0, NULL);
> > > > 
> > > > Signed-off-by: Kees Cook 
> > > 
> > > process_measurement() measures, verifies a file signature -  both
> > > signatures stored as an xattr and as an appended buffer signature -
> > > and augments audit records with the file hash. (Support for measuring,
> > > augmenting audit records, and/or verifying fs-verity signatures has
> > > yet to be added.)
> > > 
> > > As explained in my response to 11/19, the file descriptor provides the
> > > file pathname associated with the buffer data.  In addition, IMA
> > > policy rules may be defined in terms of other file descriptor info -
> > > uid, euid, uuid, etc.
> > > 
> > > Recently support was added for measuring the kexec boot command line,
> > > certificates being loaded onto a keyring, and blacklisted file hashes
> > > (limited to appended signatures).  None of these buffers are signed.
> > >  process_buffer_measurement() was added for this reason and as a
> > > result is limited to just measuring the buffer data.
> > > 
> > > Whether process_measurement() or process_buffer_measurement() should
> > > be modified, needs to be determined.  In either case to support the
> > > init_module syscall, would at minimum require the associated file
> > > pathname.
> > 
> > Right -- I don't intend to make changes to the init_module() syscall
> > since it's deprecated, so this hook is more of a "fuller LSM coverage
> > for old syscalls" addition.
> > 
> > IMA can happily continue to ignore it, which is what I have here, but I
> > thought I'd at least show what it *might* look like. Perhaps BPF LSM is
> > a better example.
> > 
> > Does anything need to change for this patch?
> 
> I wasn't aware that init_syscall was deprecated.  From your original comments,
> it sounded like you wanted a new LSM for verifying kernel module signatures,
> as
> they're currently supported via init_module().
> 
> I was mistaken.  Without a file descriptor, security_post_load_data() will
> measure the firmware, as Scott confirmed, but won't be able to verify the
> signature, whether he signed it using evmctl or not,

Actually, the partial firmware read should be calling
security_kernel_read_file().  The sysfs firmware fallback is calling
security_kernel_load_data().  Which firmware is calling
security_kernel_post_load_data()?

thanks,

Mimi

[PATCH net-next] fib: fix fib_rules_ops indirect calls wrappers

[Brian Vazquez]

This patch fixes:
commit b9aaec8f0be5 ("fib: use indirect call wrappers in the most common
fib_rules_ops") which didn't consider the case when
CONFIG_IPV6_MULTIPLE_TABLES is not set.

Reported-by: Stephen Rothwell 
Fixes: b9aaec8f0be5 ("fib: use indirect call wrappers in the most common 
fib_rules_ops")
Signed-off-by: Brian Vazquez 
---
 net/core/fib_rules.c | 33 -
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index e7a8f87b0bb2b..fce645f6b9b10 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -16,6 +16,13 @@
 #include 
 #include 
 
+#ifdef CONFIG_IPV6_MULTIPLE_TABLES
+#define INDIRECT_CALL_MT(f, f2, f1, ...) \
+   INDIRECT_CALL_INET(f, f2, f1, __VA_ARGS__)
+#else
+#define INDIRECT_CALL_MT(f, f2, f1, ...) INDIRECT_CALL_1(f, f1, __VA_ARGS__)
+#endif
+
 static const struct fib_kuid_range fib_kuid_range_unset = {
KUIDT_INIT(0),
KUIDT_INIT(~0),
@@ -268,10 +275,10 @@ static int fib_rule_match(struct fib_rule *rule, struct 
fib_rules_ops *ops,
uid_gt(fl->flowi_uid, rule->uid_range.end))
goto out;
 
-   ret = INDIRECT_CALL_INET(ops->match,
-fib6_rule_match,
-fib4_rule_match,
-rule, fl, flags);
+   ret = INDIRECT_CALL_MT(ops->match,
+  fib6_rule_match,
+  fib4_rule_match,
+  rule, fl, flags);
 out:
return (rule->flags & FIB_RULE_INVERT) ? !ret : ret;
 }
@@ -302,15 +309,15 @@ int fib_rules_lookup(struct fib_rules_ops *ops, struct 
flowi *fl,
} else if (rule->action == FR_ACT_NOP)
continue;
else
-   err = INDIRECT_CALL_INET(ops->action,
-fib6_rule_action,
-fib4_rule_action,
-rule, fl, flags, arg);
-
-   if (!err && ops->suppress && INDIRECT_CALL_INET(ops->suppress,
-   
fib6_rule_suppress,
-   
fib4_rule_suppress,
-   rule, arg))
+   err = INDIRECT_CALL_MT(ops->action,
+  fib6_rule_action,
+  fib4_rule_action,
+  rule, fl, flags, arg);
+
+   if (!err && ops->suppress && INDIRECT_CALL_MT(ops->suppress,
+ 
fib6_rule_suppress,
+ 
fib4_rule_suppress,
+ rule, arg))
continue;
 
if (err != -EAGAIN) {
-- 
2.28.0.rc0.142.g3c755180ce-goog

RE: [PATCH RFC] x86/bus_lock: Enable bus lock detection

[Yu, Fenghua]

Hi, Sean,

> > A bus lock [1] is acquired either through split locked access to
> > writeback (WB) memory or by using locks to uncacheable (UC) memory
> > (e.g. direct device
> 
> Does SLD not detect the lock to UC memory?

The statement might not be accurate. Split Lock Detection doesn't detect bus
lock to non-WB memory (including UC memory).

> 
> > assignment). This is typically >1000 cycles slower than an atomic
> > operation within a cache line. It also disrupts performance on other cores.
> >
> > Although split lock can be detected by #AC trap, the trap is triggered
> > before the instruction acquires bus lock. This makes it difficult to
> > mitigate bus lock (e.g. throttle the user application).
> 
> Mitigate _in a non-fatal way_.  The #AC makes it very easy to mitigate split
> locks, it just has the side effect of SIGBUGS or killing the KVM guest.

Adding "in a non-fatal way" is more better. Will fix it.

> 
> > Some CPUs have ability to notify the kernel by an #DB trap after the
> > instruction acquires a bus lock and is executed. This allows the
> > kernel to enforce user application throttling or mitigations and also
> > provides a better environment to debug kernel split lock issues since
> > the kernel can continue instead of crashing.
> >
> > #DB for bus lock detect fixes all issues in #AC for split lock detect:
> 
> Fixes "all" issues... and creates some new ones, e.g. there are use cases
> where preventing the split lock from happening in the first place is strongly
> desired.  It's why that train wreck exists.

Bus Lock Detection doesn't replace Split Lock Detection. If both features
are enabled, default behavior is warning from bus lock, fatal behavior is
still from split lock. See the behavior table as follows.

> 
> > 1) It's architectural ... just need to look at one CPUID bit to know it
> >exists
> > 2) The IA32_DEBUGCTL MSR, which reports bus lock in #DB, is per-thread.
> >So each process or guest can have different behavior.
> > 3) It has support for VMM/guests (new VMEXIT codes, etc).
> >
> > Use the existing kernel command line option "split_lock_detect=" to
> > handle #DB for bus lock:
> 
> Are SLD and BLD mutually exclusive?  Can we even guarantee that given the
> track record of SLD?  If not, we'll likely want to allow the user to choose
> between SDL and BLD via split_lock_detect.

The two hardware features can be enabled on the same platform.
But they are mutually exclusive in the kernel because #AC from SLD happens
before the instruction is executed and #DB happens after the instruction is
executed.

Right now, if both of them are enabled, "warn" behavior goes to
bus lock and "fatal" behavior goes to split lock.

Do you want the user to override the behaviors by something like this?

split_lock_detect=warn[,sld]: if given "sld" while both features are enabled,
warn behavior is from split lock instead of bus lock detection.

split_lock_detect=fatal[,bld]: if given "bld" while both features are enabled,
fatal behavior is from bus lock detection.

> 
> > split_lock_detect=
> > #AC for split lock  #DB for bus lock
> >
> > off Do nothing  Do nothing
> >
> > warnKernel OOPs Kernel warns rate 
> > limited
> > Warn once per task and  and continues to run.
> > disable future checking Warn once per task and
> > and continue to run.
> > When both features are
> > supported, warn in #DB
> >
> > fatal   Kernel OOPs Kernel warn rate limited
> 
> Unless the lock to UC #DB is new behavior, why would we revert to allowing
> split locks in the kernel?

SLD cannot detect lock to non-WB memory (including UC). BLD can detect
both bus locks from both split lock and lock to non-WB.

> 
> > Send SIGBUS to user Send SIGBUS to user
> > When both features are
> > supported, fatal in #AC.
> >
> > ratelimit:N Do nothing  Kernel warns rate limited
> 
> This should be more than "Do nothing" for #AC, e.g. fall back to warn or at
> least print a loud error.

Ok. Will fall back to warn.

> 
> > and continue to run.
> > Limit bus lock rate to
> > N per second in the
> > current non root user.
> >
> > On systems that support #DB for bus lock detection the default is "warn".
> >
> > [1] Chapter 8
> > https://software.intel.com/sites/default/files/managed/c5/15/architect
> > ure-instruction-set-extensions-programming-reference.pdf
> >
> > Signed-off-by: Fenghua Yu 
> > Reviewed-by: Tony Luck 
> > ---
> >  .../admin-guide/kernel-parameters.txt |  48 +-
> >  

[PATCH 3/7] scsi: dc395x: Remove pci-dma-compat wrapper APIs.

[Suraj Upadhyay]

The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering for
include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.

The patch has been generated with the coccinelle script below.
Compile tested.


- PCI_DMA_BIDIRECTIONAL
+ DMA_BIDIRECTIONAL


- PCI_DMA_TODEVICE
+ DMA_TO_DEVICE


- PCI_DMA_FROMDEVICE
+ DMA_FROM_DEVICE


- PCI_DMA_NONE
+ DMA_NONE

@@ expression E1, E2, E3; @@
- pci_alloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)

@@ expression E1, E2, E3; @@
- pci_zalloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)

@@ expression E1, E2, E3, E4; @@
- pci_free_consistent(E1, E2, E3, E4)
+ dma_free_coherent(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_map_single(E1, E2, E3, E4)
+ dma_map_single(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_single(E1, E2, E3, E4)
+ dma_unmap_single(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4, E5; @@
- pci_map_page(E1, E2, E3, E4, E5)
+ dma_map_page(>dev, E2, E3, E4, E5)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_page(E1, E2, E3, E4)
+ dma_unmap_page(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_map_sg(E1, E2, E3, E4)
+ dma_map_sg(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_sg(E1, E2, E3, E4)
+ dma_unmap_sg(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_cpu(E1, E2, E3, E4)
+ dma_sync_single_for_cpu(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_device(E1, E2, E3, E4)
+ dma_sync_single_for_device(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_cpu(E1, E2, E3, E4)
+ dma_sync_sg_for_cpu(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_device(E1, E2, E3, E4)
+ dma_sync_sg_for_device(>dev, E2, E3, E4)

@@ expression E1, E2; @@
- pci_dma_mapping_error(E1, E2)
+ dma_mapping_error(>dev, E2)

@@ expression E1, E2; @@
- pci_set_consistent_dma_mask(E1, E2)
+ dma_set_coherent_mask(>dev, E2)

@@ expression E1, E2; @@
- pci_set_dma_mask(E1, E2)
+ dma_set_mask(>dev, E2)

Signed-off-by: Suraj Upadhyay 
---
 drivers/scsi/dc395x.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/dc395x.c b/drivers/scsi/dc395x.c
index 37c6cc374079..58d4acdb0447 100644
--- a/drivers/scsi/dc395x.c
+++ b/drivers/scsi/dc395x.c
@@ -902,7 +902,7 @@ static void build_srb(struct scsi_cmnd *cmd, struct 
DeviceCtlBlk *dcb,
nseg = scsi_dma_map(cmd);
BUG_ON(nseg < 0);
 
-   if (dir == PCI_DMA_NONE || !nseg) {
+   if (dir == DMA_NONE || !nseg) {
dprintkdbg(DBG_0,
"build_srb: [0] len=%d buf=%p use_sg=%d !MAP=%08x\n",
   cmd->bufflen, scsi_sglist(cmd), scsi_sg_count(cmd),
@@ -3135,7 +3135,7 @@ static void pci_unmap_srb(struct AdapterCtlBlk *acb, 
struct ScsiReqBlk *srb)
struct scsi_cmnd *cmd = srb->cmd;
enum dma_data_direction dir = cmd->sc_data_direction;
 
-   if (scsi_sg_count(cmd) && dir != PCI_DMA_NONE) {
+   if (scsi_sg_count(cmd) && dir != DMA_NONE) {
/* unmap DC395x SG list */
dprintkdbg(DBG_SG, "pci_unmap_srb: list=%08x(%05x)\n",
srb->sg_bus_addr, SEGMENTX_LEN);
@@ -,7 +,7 @@ static void srb_done(struct AdapterCtlBlk *acb, struct 
DeviceCtlBlk *dcb,
 
if (!ckc_only && (cmd->result & RES_DID) == 0
&& cmd->cmnd[2] == 0 && scsi_bufflen(cmd) >= 8
-   && dir != PCI_DMA_NONE && ptr && (ptr->Vers & 0x07) >= 2)
+   && dir != DMA_NONE && ptr && (ptr->Vers & 0x07) >= 2)
dcb->inquiry7 = ptr->Flags;
 
/*if( srb->cmd->cmnd[0] == INQUIRY && */
-- 
2.17.1



signature.asc
Description: PGP signature

Re: [PATCH v1 2/6] mm/page_isolation: don't dump_page(NULL) in set_migratetype_isolate()

[David Hildenbrand]

On 29.07.20 19:31, Mike Kravetz wrote:
> On 6/30/20 7:26 AM, David Hildenbrand wrote:
>> Right now, if we have two isolations racing, we might trigger the
>> WARN_ON_ONCE() and to dump_page(NULL), dereferencing NULL. Let's just
>> return directly.
> 
> Just curious, what call path has the WARN_ON_ONCE()/dump_page(NULL)?

See below, two set_migratetype_isolate() caller racing.

> 
>>
>> In the future, we might want to report -EAGAIN to the caller instead, as
>> this could indicate a temporary isolation failure only.
>>
>> Cc: Andrew Morton 
>> Cc: Michal Hocko 
>> Cc: Michael S. Tsirkin 
>> Signed-off-by: David Hildenbrand 
> 
> Hi David,
> 
> That 'return -EAGAIN' was added as a sort of synchronization mechanism.
> See commit message for 2c7452a075d4d.  Before adding the 'return -EAGAIN',
> I could create races which would abandon isolated pageblocks.  Repeating
> those races over and over would result in a good chunk of system memory
> being isolated and unusable.

It's actually -EBUSY, it should maybe later be changed to -EAGAIN (see
comment), so caller can decide to retry immediately. Other discussion.

> 
> Admittedly, these races are rare and I had to work really hard to produce
> them.  I'll try to find my testing mechanism.  My concern is reintroducing
> this abandoning of pageblocks.  I have not looked further in your series
> to see if this potentially addressed later.  If not, then we should not
> remove the return code.
> 

Memory offlining could race with alloc_contig_range(), e.g., called when
allocating gigantic pages, or when virtio-mem tries to unplug memory.
The latter two could also race.

We are getting more alloc_contig_range() users, which is why these races
will become more relevant.

I have no clue what you mean with "reintroducing this abandoning of
pageblocks". All this patch is changing is not doing the dump_page() -
or am I missing something important?


-- 
Thanks,

David / dhildenb

[tip:locking/core 9/30] arch/mips/include/asm/smp.h:28:19: error: static declaration of 'raw_smp_processor_id' follows non-static declaration

[kernel test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core
head:   b5e6a027bd327daa679ca55182a920659e2cbb90
commit: 859247d39fb008ea812e8f0c398a58a20c12899e [9/30] seqlock: lockdep assert 
non-preemptibility on seqcount_t write
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 859247d39fb008ea812e8f0c398a58a20c12899e
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=mips 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All errors (new ones prefixed by >>):

   In file included from arch/mips/include/asm/bug.h:42,
from include/linux/bug.h:5,
from include/linux/thread_info.h:12,
from include/asm-generic/preempt.h:5,
from ./arch/mips/include/generated/asm/preempt.h:1,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:51,
from include/linux/seqlock.h:15,
from include/linux/time.h:6,
from include/linux/compat.h:10,
from arch/mips/kernel/asm-offsets.c:12:
   include/linux/seqlock.h: In function 'write_seqcount_begin_nested':
   include/asm-generic/percpu.h:31:40: error: implicit declaration of function 
'raw_smp_processor_id' [-Werror=implicit-function-declaration]
  31 | #define __my_cpu_offset per_cpu_offset(raw_smp_processor_id())
 |^~~~
   include/asm-generic/bug.h:144:27: note: in definition of macro 'WARN_ON_ONCE'
 144 |  int __ret_warn_once = !!(condition);   \
 |   ^
   include/linux/compiler.h:380:2: note: in expansion of macro 
'__compiletime_assert'
 380 |  __compiletime_assert(condition, msg, prefix, suffix)
 |  ^~~~
   include/linux/compiler.h:392:2: note: in expansion of macro 
'_compiletime_assert'
 392 |  _compiletime_assert(condition, msg, __compiletime_assert_, 
__COUNTER__)
 |  ^~~
   include/linux/compiler.h:405:2: note: in expansion of macro 
'compiletime_assert'
 405 |  compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long 
long), \
 |  ^~
   include/linux/compiler.h:405:21: note: in expansion of macro '__native_word'
 405 |  compiletime_assert(__native_word(t) || sizeof(t) == sizeof(long 
long), \
 | ^
   include/linux/compiler.h:291:2: note: in expansion of macro 
'compiletime_assert_rwonce_type'
 291 |  compiletime_assert_rwonce_type(x);\
 |  ^~
   include/asm-generic/percpu.h:119:10: note: in expansion of macro 'READ_ONCE'
 119 |  __ret = READ_ONCE(*raw_cpu_ptr(&(pcp)));   \
 |  ^
   include/linux/percpu-defs.h:231:2: note: in expansion of macro 'RELOC_HIDE'
 231 |  RELOC_HIDE((typeof(*(__p)) __kernel __force *)(__p), (__offset))
 |  ^~
   include/asm-generic/percpu.h:44:31: note: in expansion of macro 
'SHIFT_PERCPU_PTR'
  44 | #define arch_raw_cpu_ptr(ptr) SHIFT_PERCPU_PTR(ptr, __my_cpu_offset)
 |   ^~~~
   include/asm-generic/percpu.h:31:25: note: in expansion of macro 
'per_cpu_offset'
  31 | #define __my_cpu_offset per_cpu_offset(raw_smp_processor_id())
 | ^~
   include/asm-generic/percpu.h:44:53: note: in expansion of macro 
'__my_cpu_offset'
  44 | #define arch_raw_cpu_ptr(ptr) SHIFT_PERCPU_PTR(ptr, __my_cpu_offset)
 | ^~~
   include/linux/percpu-defs.h:242:2: note: in expansion of macro 
'arch_raw_cpu_ptr'
 242 |  arch_raw_cpu_ptr(ptr);  \
 |  ^~~~
   include/asm-generic/percpu.h:119:21: note: in expansion of macro 
'raw_cpu_ptr'
 119 |  __ret = READ_ONCE(*raw_cpu_ptr(&(pcp)));   \
 | ^~~
   include/asm-generic/percpu.h:138:11: note: in expansion of macro 
'__this_cpu_generic_read_nopreempt'
 138 |   __ret = __this_cpu_generic_read_nopreempt(pcp);  \
 |   ^
   include/asm-generic/percpu.h:320:31: note: in expansion of macro 
'this_cpu_generic_read'
 320 | #define this_cpu_read_1(pcp)  this_cpu_generic_read(pcp)
 |   ^
   include/linux/percpu-defs.h:321:23: note: in expansion of macro 
'this_cpu_read_1'
 321 |  case 1: pscr_ret__ = stem##1(variable); break;   \
 |   ^~~~
   

[PATCH v4 17/17] test_firmware: Test partial read support

[Kees Cook]

From: Scott Branden 

Add additional hooks to test_firmware to pass in support
for partial file read using request_firmware_into_buf():

buf_size: size of buffer to request firmware into
partial: indicates that a partial file request is being made
file_offset: to indicate offset into file to request

Also update firmware selftests to use the new partial read test API.

Signed-off-by: Scott Branden 
Co-developed-by: Kees Cook 
Signed-off-by: Kees Cook 
---
 lib/test_firmware.c   | 154 --
 .../selftests/firmware/fw_filesystem.sh   |  91 +++
 2 files changed, 233 insertions(+), 12 deletions(-)

diff --git a/lib/test_firmware.c b/lib/test_firmware.c
index 62af792e151c..387acb94eeea 100644
--- a/lib/test_firmware.c
+++ b/lib/test_firmware.c
@@ -50,6 +50,9 @@ struct test_batched_req {
  * @name: the name of the firmware file to look for
  * @into_buf: when the into_buf is used if this is true
  * request_firmware_into_buf() will be used instead.
+ * @buf_size: size of buf to allocate when into_buf is true
+ * @file_offset: file offset to request when calling request_firmware_into_buf
+ * @partial: partial read opt when calling request_firmware_into_buf
  * @sync_direct: when the sync trigger is used if this is true
  * request_firmware_direct() will be used instead.
  * @send_uevent: whether or not to send a uevent for async requests
@@ -89,6 +92,9 @@ struct test_batched_req {
 struct test_config {
char *name;
bool into_buf;
+   size_t buf_size;
+   size_t file_offset;
+   bool partial;
bool sync_direct;
bool send_uevent;
u8 num_requests;
@@ -183,6 +189,9 @@ static int __test_firmware_config_init(void)
test_fw_config->num_requests = TEST_FIRMWARE_NUM_REQS;
test_fw_config->send_uevent = true;
test_fw_config->into_buf = false;
+   test_fw_config->buf_size = TEST_FIRMWARE_BUF_SIZE;
+   test_fw_config->file_offset = 0;
+   test_fw_config->partial = false;
test_fw_config->sync_direct = false;
test_fw_config->req_firmware = request_firmware;
test_fw_config->test_result = 0;
@@ -236,28 +245,35 @@ static ssize_t config_show(struct device *dev,
dev_name(dev));
 
if (test_fw_config->name)
-   len += scnprintf(buf+len, PAGE_SIZE - len,
+   len += scnprintf(buf + len, PAGE_SIZE - len,
"name:\t%s\n",
test_fw_config->name);
else
-   len += scnprintf(buf+len, PAGE_SIZE - len,
+   len += scnprintf(buf + len, PAGE_SIZE - len,
"name:\tEMTPY\n");
 
-   len += scnprintf(buf+len, PAGE_SIZE - len,
+   len += scnprintf(buf + len, PAGE_SIZE - len,
"num_requests:\t%u\n", test_fw_config->num_requests);
 
-   len += scnprintf(buf+len, PAGE_SIZE - len,
+   len += scnprintf(buf + len, PAGE_SIZE - len,
"send_uevent:\t\t%s\n",
test_fw_config->send_uevent ?
"FW_ACTION_HOTPLUG" :
"FW_ACTION_NOHOTPLUG");
-   len += scnprintf(buf+len, PAGE_SIZE - len,
+   len += scnprintf(buf + len, PAGE_SIZE - len,
"into_buf:\t\t%s\n",
test_fw_config->into_buf ? "true" : "false");
-   len += scnprintf(buf+len, PAGE_SIZE - len,
+   len += scnprintf(buf + len, PAGE_SIZE - len,
+   "buf_size:\t%zu\n", test_fw_config->buf_size);
+   len += scnprintf(buf + len, PAGE_SIZE - len,
+   "file_offset:\t%zu\n", test_fw_config->file_offset);
+   len += scnprintf(buf + len, PAGE_SIZE - len,
+   "partial:\t\t%s\n",
+   test_fw_config->partial ? "true" : "false");
+   len += scnprintf(buf + len, PAGE_SIZE - len,
"sync_direct:\t\t%s\n",
test_fw_config->sync_direct ? "true" : "false");
-   len += scnprintf(buf+len, PAGE_SIZE - len,
+   len += scnprintf(buf + len, PAGE_SIZE - len,
"read_fw_idx:\t%u\n", test_fw_config->read_fw_idx);
 
mutex_unlock(_fw_mutex);
@@ -315,6 +331,30 @@ static ssize_t test_dev_config_show_bool(char *buf, bool 
val)
return snprintf(buf, PAGE_SIZE, "%d\n", val);
 }
 
+static int test_dev_config_update_size_t(const char *buf,
+size_t size,
+size_t *cfg)
+{
+   int ret;
+   long new;
+
+   ret = kstrtol(buf, 10, );
+   if (ret)
+   return ret;
+
+   mutex_lock(_fw_mutex);
+   *(size_t *)cfg = new;
+   mutex_unlock(_fw_mutex);
+
+   /* Always return full write size even if we didn't consume all */
+   return size;
+}
+
+static ssize_t test_dev_config_show_size_t(char *buf, size_t 

[PATCH 2/7] scsi: aic7xxx: Remove pci-dma-compat wrapper APIs.

[Suraj Upadhyay]

The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering
for include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.

The patch has been generated with the coccinelle script below.
And has been hand modified to replace each GFP_ with the correct
flag depending upon the context.
Compile-tested.


- PCI_DMA_BIDIRECTIONAL
+ DMA_BIDIRECTIONAL


- PCI_DMA_TODEVICE
+ DMA_TO_DEVICE


- PCI_DMA_FROMDEVICE
+ DMA_FROM_DEVICE


- PCI_DMA_NONE
+ DMA_NONE

@@ expression E1, E2, E3; @@
- pci_alloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)

@@ expression E1, E2, E3; @@
- pci_zalloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)

@@ expression E1, E2, E3, E4; @@
- pci_free_consistent(E1, E2, E3, E4)
+ dma_free_coherent(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_map_single(E1, E2, E3, E4)
+ dma_map_single(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_single(E1, E2, E3, E4)
+ dma_unmap_single(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4, E5; @@
- pci_map_page(E1, E2, E3, E4, E5)
+ dma_map_page(>dev, E2, E3, E4, E5)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_page(E1, E2, E3, E4)
+ dma_unmap_page(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_map_sg(E1, E2, E3, E4)
+ dma_map_sg(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_sg(E1, E2, E3, E4)
+ dma_unmap_sg(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_cpu(E1, E2, E3, E4)
+ dma_sync_single_for_cpu(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_device(E1, E2, E3, E4)
+ dma_sync_single_for_device(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_cpu(E1, E2, E3, E4)
+ dma_sync_sg_for_cpu(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_device(E1, E2, E3, E4)
+ dma_sync_sg_for_device(>dev, E2, E3, E4)

@@ expression E1, E2; @@
- pci_dma_mapping_error(E1, E2)
+ dma_mapping_error(>dev, E2)

@@ expression E1, E2; @@
- pci_set_consistent_dma_mask(E1, E2)
+ dma_set_coherent_mask(>dev, E2)

@@ expression E1, E2; @@
- pci_set_dma_mask(E1, E2)
+ dma_set_mask(>dev, E2)

Signed-off-by: Suraj Upadhyay 
---
 drivers/scsi/aic7xxx/aic79xx_osm.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/scsi/aic7xxx/aic79xx_osm.c 
b/drivers/scsi/aic7xxx/aic79xx_osm.c
index d019e3f2bb9b..7599eec08bf2 100644
--- a/drivers/scsi/aic7xxx/aic79xx_osm.c
+++ b/drivers/scsi/aic7xxx/aic79xx_osm.c
@@ -952,8 +952,8 @@ int
 ahd_dmamem_alloc(struct ahd_softc *ahd, bus_dma_tag_t dmat, void** vaddr,
 int flags, bus_dmamap_t *mapp)
 {
-   *vaddr = pci_alloc_consistent(ahd->dev_softc,
- dmat->maxsize, mapp);
+   *vaddr = dma_alloc_coherent(>dev_softc->dev, dmat->maxsize, mapp,
+   GFP_ATOMIC);
if (*vaddr == NULL)
return (ENOMEM);
return(0);
@@ -963,8 +963,7 @@ void
 ahd_dmamem_free(struct ahd_softc *ahd, bus_dma_tag_t dmat,
void* vaddr, bus_dmamap_t map)
 {
-   pci_free_consistent(ahd->dev_softc, dmat->maxsize,
-   vaddr, map);
+   dma_free_coherent(>dev_softc->dev, dmat->maxsize, vaddr, map);
 }
 
 int
-- 
2.17.1



signature.asc
Description: PGP signature

Re: [PATCH v2 1/2] usb: xhci: define IDs for various ASMedia host controllers

[Sergei Shtylyov]

Hello!

On 7/28/20 7:24 AM, Forest Crossman wrote:

> Not all ASMedia host controllers have a device ID that matches its part
> number. #define some of these IDs to make it clearer at a glance which
> chips require what quirks.
> 
> Signed-off-by: Forest Crossman 
> ---
>  drivers/usb/host/xhci-pci.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index 9234c82e70e4..baa5af88ca67 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
[...]
> @@ -260,13 +262,13 @@ static void xhci_pci_quirks(struct device *dev, struct 
> xhci_hcd *xhci)
>   xhci->quirks |= XHCI_LPM_SUPPORT;
>  
>   if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA &&
> - pdev->device == 0x1042)
> + pdev->device == PCI_DEVICE_ID_ASMEDIA_1042_XHCI)

   You shouldn't have un-indented it, blends with the branch below.
   The 80-column line length limit is history now. :-)

>   xhci->quirks |= XHCI_BROKEN_STREAMS;
>   if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA &&
> - pdev->device == 0x1142)
> + pdev->device == PCI_DEVICE_ID_ASMEDIA_1042A_XHCI)
>   xhci->quirks |= XHCI_TRUST_TX_LENGTH;
>   if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA &&
> - pdev->device == 0x2142)
> + pdev->device == PCI_DEVICE_ID_ASMEDIA_2142_XHCI)
>   xhci->quirks |= XHCI_NO_64BIT_SUPPORT;
>  
>   if (pdev->vendor == PCI_VENDOR_ID_ASMEDIA &&

MBR, Sergei

[PATCH 1/7] scsi: aacraid: Remove pci-dma-compat wrapper APIs

[Suraj Upadhyay]

The legacy API wrappers in include/linux/pci-dma-compat.h
should go away as it creates unnecessary midlayering for
include/linux/dma-mapping.h APIs.
Instead use dma-mapping.h APIs directly.

The patch has been generated with the coccinelle script below.
Compile-tested.


- PCI_DMA_BIDIRECTIONAL
+ DMA_BIDIRECTIONAL


- PCI_DMA_TODEVICE
+ DMA_TO_DEVICE


- PCI_DMA_FROMDEVICE
+ DMA_FROM_DEVICE


- PCI_DMA_NONE
+ DMA_NONE

@@ expression E1, E2, E3; @@
- pci_alloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)

@@ expression E1, E2, E3; @@
- pci_zalloc_consistent(E1, E2, E3)
+ dma_alloc_coherent(>dev, E2, E3, GFP_)

@@ expression E1, E2, E3, E4; @@
- pci_free_consistent(E1, E2, E3, E4)
+ dma_free_coherent(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_map_single(E1, E2, E3, E4)
+ dma_map_single(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_single(E1, E2, E3, E4)
+ dma_unmap_single(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4, E5; @@
- pci_map_page(E1, E2, E3, E4, E5)
+ dma_map_page(>dev, E2, E3, E4, E5)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_page(E1, E2, E3, E4)
+ dma_unmap_page(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_map_sg(E1, E2, E3, E4)
+ dma_map_sg(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_unmap_sg(E1, E2, E3, E4)
+ dma_unmap_sg(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_cpu(E1, E2, E3, E4)
+ dma_sync_single_for_cpu(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_single_for_device(E1, E2, E3, E4)
+ dma_sync_single_for_device(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_cpu(E1, E2, E3, E4)
+ dma_sync_sg_for_cpu(>dev, E2, E3, E4)

@@ expression E1, E2, E3, E4; @@
- pci_dma_sync_sg_for_device(E1, E2, E3, E4)
+ dma_sync_sg_for_device(>dev, E2, E3, E4)

@@ expression E1, E2; @@
- pci_dma_mapping_error(E1, E2)
+ dma_mapping_error(>dev, E2)

@@ expression E1, E2; @@
- pci_set_consistent_dma_mask(E1, E2)
+ dma_set_coherent_mask(>dev, E2)

@@ expression E1, E2; @@
- pci_set_dma_mask(E1, E2)
+ dma_set_mask(>dev, E2)

Signed-off-by: Suraj Upadhyay 
---
 drivers/scsi/aacraid/aachba.c   |  4 ++--
 drivers/scsi/aacraid/commctrl.c | 20 +++-
 drivers/scsi/aacraid/commsup.c  |  8 
 drivers/scsi/aacraid/linit.c|  4 ++--
 4 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/drivers/scsi/aacraid/aachba.c b/drivers/scsi/aacraid/aachba.c
index 769af4ca9ca9..959b3ae8a99e 100644
--- a/drivers/scsi/aacraid/aachba.c
+++ b/drivers/scsi/aacraid/aachba.c
@@ -2229,10 +2229,10 @@ int aac_get_adapter_info(struct aac_dev* dev)
}
 
if (dev->dac_support) {
-   if (!pci_set_dma_mask(dev->pdev, DMA_BIT_MASK(64))) {
+   if (!dma_set_mask(>pdev->dev, DMA_BIT_MASK(64))) {
if (!dev->in_reset)
dev_info(>pdev->dev, "64 Bit DAC 
enabled\n");
-   } else if (!pci_set_dma_mask(dev->pdev, DMA_BIT_MASK(32))) {
+   } else if (!dma_set_mask(>pdev->dev, DMA_BIT_MASK(32))) {
dev_info(>pdev->dev, "DMA mask set failed, 64 Bit 
DAC disabled\n");
dev->dac_support = 0;
} else {
diff --git a/drivers/scsi/aacraid/commctrl.c b/drivers/scsi/aacraid/commctrl.c
index 59e82a832042..e3e157a74988 100644
--- a/drivers/scsi/aacraid/commctrl.c
+++ b/drivers/scsi/aacraid/commctrl.c
@@ -670,8 +670,8 @@ static int aac_send_raw_srb(struct aac_dev* dev, void 
__user * arg)
goto cleanup;
}
}
-   addr = pci_map_single(dev->pdev, p, sg_count[i],
-   data_dir);
+   addr = dma_map_single(>pdev->dev, p, sg_count[i],
+ data_dir);
hbacmd->sge[i].addr_hi = cpu_to_le32((u32)(addr>>32));
hbacmd->sge[i].addr_lo = cpu_to_le32(
(u32)(addr & 0x));
@@ -732,8 +732,8 @@ static int aac_send_raw_srb(struct aac_dev* dev, void 
__user * arg)
goto cleanup;
}
}
-   addr = pci_map_single(dev->pdev, p,
-   sg_count[i], data_dir);
+   addr = dma_map_single(>pdev->dev, p,
+ sg_count[i], data_dir);
 
psg->sg[i].addr[0] = cpu_to_le32(addr & 
0x);
psg->sg[i].addr[1] = cpu_to_le32(addr>>32);
@@ -788,8 +788,8 @@ static int aac_send_raw_srb(struct aac_dev* dev, void 
__user * arg)
goto 

Re: [PATCH v17 00/21] per memcg lru lock

[Hugh Dickins]

On Wed, 29 Jul 2020, Alex Shi wrote:
> 
> Is there any comments or suggestion for this patchset?
> Any hints will be very appreciated.

Alex: it is now v5.8-rc7, obviously too late for this patchset to make
v5.9, so I'm currently concentrated on checking some patches headed for
v5.9 (and some bugfix patches of my own that I don't get time to send):
I'll get back to responding on lru_lock in a week or two's time.

Hugh

[PATCH 0/7] scsi: Remove pci-dma-compat wrapper APIs.

[Suraj Upadhyay]

Hii Maintainers,
This patchset replaces the pci-dma-compat wrappers with their
dma-mapping counterparts. Thus, removing possible midlayering and
unnecessary legacy code and API.

Most of the task is fairly trivially scriptable and done with
coccinelle. But the handling of pci_z/alloc_consistent needed
some hand modification in replacing the flag GFP_ATOMIC with
a proper flag depending upon the context.

I would be glad to receive any feedbacks.

Thanks,

Suraj Upadhyay.

Suraj Upadhyay (7):
  scsi: aacraid: Remove pci-dma-compat wrapper APIs
  scsi: aic7xxx: Remove pci-dma-compat wrapper APIs.
  scsi: dc395x: Remove pci-dma-compat wrapper APIs.
  scsi: mpt3sas: Remove pci-dma-compat wrapper APIs.
  scsi: hpsa: Remove pci-dma-compat wrapper APIs.
  scsi: qla2xxx: Remove pci-dma-compat wrapper APIs.
  scsi: megaraid: Remove pci-dma-compat wrapper APIs

 drivers/scsi/aacraid/aachba.c  |   4 +-
 drivers/scsi/aacraid/commctrl.c|  20 +--
 drivers/scsi/aacraid/commsup.c |   8 +-
 drivers/scsi/aacraid/linit.c   |   4 +-
 drivers/scsi/aic7xxx/aic79xx_osm.c |   7 +-
 drivers/scsi/dc395x.c  |   6 +-
 drivers/scsi/hpsa.c|  16 +--
 drivers/scsi/megaraid.c| 192 +++--
 drivers/scsi/mpt3sas/mpt3sas_ctl.c |  10 +-
 drivers/scsi/qla2xxx/qla_os.c  |   4 +-
 10 files changed, 141 insertions(+), 130 deletions(-)

-- 
2.17.1



signature.asc
Description: PGP signature

[PATCH] erofs: fold in used-once helper erofs_workgroup_unfreeze_final()

[Gao Xiang]

It's expected that erofs_workgroup_unfreeze_final() won't
be used in other places. Let's fold it to simplify the code.

Signed-off-by: Gao Xiang 
---
 fs/erofs/utils.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/fs/erofs/utils.c b/fs/erofs/utils.c
index 52d0be10f1aa..14485a621862 100644
--- a/fs/erofs/utils.c
+++ b/fs/erofs/utils.c
@@ -127,12 +127,6 @@ int erofs_workgroup_put(struct erofs_workgroup *grp)
return count;
 }
 
-static void erofs_workgroup_unfreeze_final(struct erofs_workgroup *grp)
-{
-   erofs_workgroup_unfreeze(grp, 0);
-   __erofs_workgroup_free(grp);
-}
-
 static bool erofs_try_to_release_workgroup(struct erofs_sb_info *sbi,
   struct erofs_workgroup *grp)
 {
@@ -162,11 +156,9 @@ static bool erofs_try_to_release_workgroup(struct 
erofs_sb_info *sbi,
 */
DBG_BUGON(xa_erase(>managed_pslots, grp->index) != grp);
 
-   /*
-* If managed cache is on, last refcount should indicate
-* the related workstation.
-*/
-   erofs_workgroup_unfreeze_final(grp);
+   /* last refcount should be connected with its managed pslot.  */
+   erofs_workgroup_unfreeze(grp, 0);
+   __erofs_workgroup_free(grp);
return true;
 }
 
-- 
2.18.1

Re: [RFC PATCH 01/14] coresight: etm4x: Skip save/restore before device registration

[Mathieu Poirier]

Hi Suzuki,

I have starte to review this - comments will be scattered over a few days.

On Wed, Jul 22, 2020 at 06:20:27PM +0100, Suzuki K Poulose wrote:
> Skip cpu save/restore before the coresight device is registered.
> 
> Cc: Mathieu Poirier 
> Cc: Mike Leach 
> Signed-off-by: Suzuki K Poulose 
> ---
>  drivers/hwtracing/coresight/coresight-etm4x.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c 
> b/drivers/hwtracing/coresight/coresight-etm4x.c
> index 6d7d2169bfb2..cb83fb77ded6 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> @@ -1135,7 +1135,13 @@ static int etm4_cpu_save(struct etmv4_drvdata *drvdata)
>  {
>   int i, ret = 0;
>   struct etmv4_save_state *state;
> - struct device *etm_dev = >csdev->dev;
> + struct coresight_device *csdev = drvdata->csdev;
> + struct device *etm_dev;
> +
> + if (WARN_ON(!csdev))
> + return -ENODEV;
> +
> + etm_dev = >dev;
>  
>   /*
>* As recommended by 3.4.1 ("The procedure when powering down the PE")
> @@ -1261,6 +1267,10 @@ static void etm4_cpu_restore(struct etmv4_drvdata 
> *drvdata)
>  {
>   int i;
>   struct etmv4_save_state *state = drvdata->save_state;
> + struct coresight_device *csdev = drvdata->csdev;
> +
> + if (WARN_ON(!csdev))
> + return;

Restore and save operations are only called from etm4_cpu_pm_notify() where the
check for a valid drvdata->csdev is already done.

>  
>   CS_UNLOCK(drvdata->base);
>  
> @@ -1368,6 +1378,10 @@ static int etm4_cpu_pm_notify(struct notifier_block 
> *nb, unsigned long cmd,
>  
>   drvdata = etmdrvdata[cpu];
>  
> + /* If we have not registered the device there is nothing to do */
> + if (!drvdata->csdev)
> + return NOTIFY_OK;

Can you describe the scenario you've seen this happening in?  Probably best to
add it to the changelog. 

> +
>   if (!drvdata->save_state)
>   return NOTIFY_OK;
>  
> -- 
> 2.24.1
> 

Re: [PATCH V2] dmaengine: bcm-sba-raid: add missing put_device() call in sba_probe()

[Markus Elfring]

> if of_find_device_by_node() succeed, sba_probe() doesn't have a
> corresponding put_device(). …

Wording adjustment:
  If a of_find_device_by_node() call succeeded, sba_probe() did not
  contain a corresponding put_device() call. …

Regards,
Markus

[PATCH v4 03/17] fs/kernel_read_file: Remove FIRMWARE_EFI_EMBEDDED enum

[Kees Cook]

The "FIRMWARE_EFI_EMBEDDED" enum is a "where", not a "what". It
should not be distinguished separately from just "FIRMWARE", as this
confuses the LSMs about what is being loaded. Additionally, there was
no actual validation of the firmware contents happening.

Fixes: e4c2c0ff00ec ("firmware: Add new platform fallback mechanism and 
firmware_request_platform()")
Cc: sta...@vger.kernel.org
Acked-by: Scott Branden 
Reviewed-by: Luis Chamberlain 
Signed-off-by: Kees Cook 
---
To aid in backporting, this change is made before moving
kernel_read_file() to separate header/source files.
---
 drivers/base/firmware_loader/fallback_platform.c | 2 +-
 include/linux/fs.h   | 3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/base/firmware_loader/fallback_platform.c 
b/drivers/base/firmware_loader/fallback_platform.c
index 685edb7dd05a..6958ab1a8059 100644
--- a/drivers/base/firmware_loader/fallback_platform.c
+++ b/drivers/base/firmware_loader/fallback_platform.c
@@ -17,7 +17,7 @@ int firmware_fallback_platform(struct fw_priv *fw_priv, u32 
opt_flags)
if (!(opt_flags & FW_OPT_FALLBACK_PLATFORM))
return -ENOENT;
 
-   rc = security_kernel_load_data(LOADING_FIRMWARE_EFI_EMBEDDED);
+   rc = security_kernel_load_data(LOADING_FIRMWARE);
if (rc)
return rc;
 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index f34d47ba49de..0d4f7aacf286 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2993,11 +2993,10 @@ static inline void i_readcount_inc(struct inode *inode)
 #endif
 extern int do_pipe_flags(int *, int);
 
-/* This is a list of *what* is being read, not *how*. */
+/* This is a list of *what* is being read, not *how* nor *where*. */
 #define __kernel_read_file_id(id) \
id(UNKNOWN, unknown)\
id(FIRMWARE, firmware)  \
-   id(FIRMWARE_EFI_EMBEDDED, firmware) \
id(MODULE, kernel-module)   \
id(KEXEC_IMAGE, kexec-image)\
id(KEXEC_INITRAMFS, kexec-initramfs)\
-- 
2.25.1

[PATCH v4 12/17] LSM: Add "contents" flag to kernel_read_file hook

[Kees Cook]

As with the kernel_load_data LSM hook, add a "contents" flag to the
kernel_read_file LSM hook that indicates whether the LSM can expect
a matching call to the kernel_post_read_file LSM hook with the full
contents of the file. With the coming addition of partial file read
support for kernel_read_file*() API, the LSM will no longer be able
to always see the entire contents of a file during the read calls.

For cases where the LSM must read examine the complete file contents,
it will need to do so on its own every time the kernel_read_file
hook is called with contents=false (or reject such cases). Adjust all
existing LSMs to retain existing behavior.

Signed-off-by: Kees Cook 
---
 fs/kernel_read_file.c |  2 +-
 include/linux/ima.h   |  6 --
 include/linux/lsm_hook_defs.h |  2 +-
 include/linux/lsm_hooks.h |  3 +++
 include/linux/security.h  |  6 --
 security/integrity/ima/ima_main.c | 10 +-
 security/loadpin/loadpin.c| 14 --
 security/security.c   |  7 ---
 security/selinux/hooks.c  |  5 +++--
 9 files changed, 41 insertions(+), 14 deletions(-)

diff --git a/fs/kernel_read_file.c b/fs/kernel_read_file.c
index 2e29c38eb4df..d73bc3fa710a 100644
--- a/fs/kernel_read_file.c
+++ b/fs/kernel_read_file.c
@@ -39,7 +39,7 @@ int kernel_read_file(struct file *file, void **buf,
if (ret)
return ret;
 
-   ret = security_kernel_read_file(file, id);
+   ret = security_kernel_read_file(file, id, true);
if (ret)
goto out;
 
diff --git a/include/linux/ima.h b/include/linux/ima.h
index 502e36ad7804..259023039dc9 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -23,7 +23,8 @@ extern int ima_file_mprotect(struct vm_area_struct *vma, 
unsigned long prot);
 extern int ima_load_data(enum kernel_load_data_id id, bool contents);
 extern int ima_post_load_data(char *buf, loff_t size,
  enum kernel_load_data_id id);
-extern int ima_read_file(struct file *file, enum kernel_read_file_id id);
+extern int ima_read_file(struct file *file, enum kernel_read_file_id id,
+bool contents);
 extern int ima_post_read_file(struct file *file, void *buf, loff_t size,
  enum kernel_read_file_id id);
 extern void ima_post_path_mknod(struct dentry *dentry);
@@ -91,7 +92,8 @@ static inline int ima_post_load_data(char *buf, loff_t size,
return 0;
 }
 
-static inline int ima_read_file(struct file *file, enum kernel_read_file_id id)
+static inline int ima_read_file(struct file *file, enum kernel_read_file_id id,
+   bool contents)
 {
return 0;
 }
diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h
index 7ed5d31ac9cc..f953aa938eaf 100644
--- a/include/linux/lsm_hook_defs.h
+++ b/include/linux/lsm_hook_defs.h
@@ -188,7 +188,7 @@ LSM_HOOK(int, 0, kernel_load_data, enum kernel_load_data_id 
id, bool contents)
 LSM_HOOK(int, 0, kernel_post_load_data, char *buf, loff_t size,
 enum kernel_read_file_id id)
 LSM_HOOK(int, 0, kernel_read_file, struct file *file,
-enum kernel_read_file_id id)
+enum kernel_read_file_id id, bool contents)
 LSM_HOOK(int, 0, kernel_post_read_file, struct file *file, char *buf,
 loff_t size, enum kernel_read_file_id id)
 LSM_HOOK(int, 0, task_fix_setuid, struct cred *new, const struct cred *old,
diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h
index 812d626195fc..b66433b5aa15 100644
--- a/include/linux/lsm_hooks.h
+++ b/include/linux/lsm_hooks.h
@@ -650,6 +650,7 @@
  * @file contains the file structure pointing to the file being read
  * by the kernel.
  * @id kernel read file identifier
+ * @contents if a subsequent @kernel_post_read_file will be called.
  * Return 0 if permission is granted.
  * @kernel_post_read_file:
  * Read a file specified by userspace.
@@ -658,6 +659,8 @@
  * @buf pointer to buffer containing the file contents.
  * @size length of the file contents.
  * @id kernel read file identifier
+ * This must be paired with a prior @kernel_read_file call that had
+ * @contents set to true.
  * Return 0 if permission is granted.
  * @task_fix_setuid:
  * Update the module's state after setting one or more of the user
diff --git a/include/linux/security.h b/include/linux/security.h
index e748974c707b..a5d66b89cd6c 100644
--- a/include/linux/security.h
+++ b/include/linux/security.h
@@ -390,7 +390,8 @@ int security_kernel_module_request(char *kmod_name);
 int security_kernel_load_data(enum kernel_load_data_id id, bool contents);
 int security_kernel_post_load_data(char *buf, loff_t size,
   enum kernel_load_data_id id);
-int security_kernel_read_file(struct file *file, enum kernel_read_file_id id);
+int security_kernel_read_file(struct file *file, enum kernel_read_file_id id,
+   

Hello, Please

[Mr. Scott Donald]

-- 
Dear Friend,

I'm Mr. Scott Donald a Successful businessMan dealing with
Exportation, I got your mail contact through search to let you know my
intension and my Ugly Situation Am a dying Man here in Los Angeles
California Hospital Bed in (USA), I Lost my Wife and my only Daughter
for Covid-19 and I also have a problem in my Health and I can die
anytime I Know,

I have a project that I am about to hand over to you. and I already
instructed the Bankia S.A. Madrid, Spain(BSA) to transfer my fund sum
of £3,7M GBP. Equivalent to €4,077,033.91 EUR, to you as to enable you
to give 50% of this fund to Charitable Home in your State and take 50%
don't think otherwise and why would anybody send someone you barely
know to help you deliver a message, help me do this for the happiness
of my soul and for God to mercy me and my Family and give Us a good
place.

please, do as I said there was someone from your State that I deeply
love so very very much and I miss her so badly I have no means to
reach any Charitable Home there. that is why I go for a personal
search of the Country and State and I got your mail contact through
search to let you know my Bitterness and please, help me is getting
Dark I ask my Doctor to help me keep you notice failure for me to
reach you in person Your urgent Response, here is my Doctor Whats-app
Number for urgent notice +13019692737

Hope To Hear From You. I'm sending this email to you for the second
time yet no response from you.

My Regards.

Mr. Scott Donald
CEO

[PATCH v4 05/17] fs/kernel_read_file: Split into separate source file

[Kees Cook]

These routines are used in places outside of exec(2), so in preparation
for refactoring them, move them into a separate source file,
fs/kernel_read_file.c.

Acked-by: Scott Branden 
Reviewed-by: Mimi Zohar 
Reviewed-by: Luis Chamberlain 
Signed-off-by: Kees Cook 
---
 fs/Makefile   |   3 +-
 fs/exec.c | 132 
 fs/kernel_read_file.c | 138 ++
 3 files changed, 140 insertions(+), 133 deletions(-)
 create mode 100644 fs/kernel_read_file.c

diff --git a/fs/Makefile b/fs/Makefile
index 2ce5112b02c8..a05fc247b2a7 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -13,7 +13,8 @@ obj-y :=  open.o read_write.o file_table.o super.o \
seq_file.o xattr.o libfs.o fs-writeback.o \
pnode.o splice.o sync.o utimes.o d_path.o \
stack.o fs_struct.o statfs.o fs_pin.o nsfs.o \
-   fs_types.o fs_context.o fs_parser.o fsopen.o
+   fs_types.o fs_context.o fs_parser.o fsopen.o \
+   kernel_read_file.o
 
 ifeq ($(CONFIG_BLOCK),y)
 obj-y +=   buffer.o block_dev.o direct-io.o mpage.o
diff --git a/fs/exec.c b/fs/exec.c
index 07a7fe9ac5be..d619b79aab30 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -923,138 +923,6 @@ struct file *open_exec(const char *name)
 }
 EXPORT_SYMBOL(open_exec);
 
-int kernel_read_file(struct file *file, void **buf, loff_t *size,
-loff_t max_size, enum kernel_read_file_id id)
-{
-   loff_t i_size, pos;
-   ssize_t bytes = 0;
-   void *allocated = NULL;
-   int ret;
-
-   if (!S_ISREG(file_inode(file)->i_mode) || max_size < 0)
-   return -EINVAL;
-
-   ret = deny_write_access(file);
-   if (ret)
-   return ret;
-
-   ret = security_kernel_read_file(file, id);
-   if (ret)
-   goto out;
-
-   i_size = i_size_read(file_inode(file));
-   if (i_size <= 0) {
-   ret = -EINVAL;
-   goto out;
-   }
-   if (i_size > SIZE_MAX || (max_size > 0 && i_size > max_size)) {
-   ret = -EFBIG;
-   goto out;
-   }
-
-   if (!*buf)
-   *buf = allocated = vmalloc(i_size);
-   if (!*buf) {
-   ret = -ENOMEM;
-   goto out;
-   }
-
-   pos = 0;
-   while (pos < i_size) {
-   bytes = kernel_read(file, *buf + pos, i_size - pos, );
-   if (bytes < 0) {
-   ret = bytes;
-   goto out_free;
-   }
-
-   if (bytes == 0)
-   break;
-   }
-
-   if (pos != i_size) {
-   ret = -EIO;
-   goto out_free;
-   }
-
-   ret = security_kernel_post_read_file(file, *buf, i_size, id);
-   if (!ret)
-   *size = pos;
-
-out_free:
-   if (ret < 0) {
-   if (allocated) {
-   vfree(*buf);
-   *buf = NULL;
-   }
-   }
-
-out:
-   allow_write_access(file);
-   return ret;
-}
-EXPORT_SYMBOL_GPL(kernel_read_file);
-
-int kernel_read_file_from_path(const char *path, void **buf, loff_t *size,
-  loff_t max_size, enum kernel_read_file_id id)
-{
-   struct file *file;
-   int ret;
-
-   if (!path || !*path)
-   return -EINVAL;
-
-   file = filp_open(path, O_RDONLY, 0);
-   if (IS_ERR(file))
-   return PTR_ERR(file);
-
-   ret = kernel_read_file(file, buf, size, max_size, id);
-   fput(file);
-   return ret;
-}
-EXPORT_SYMBOL_GPL(kernel_read_file_from_path);
-
-int kernel_read_file_from_path_initns(const char *path, void **buf,
- loff_t *size, loff_t max_size,
- enum kernel_read_file_id id)
-{
-   struct file *file;
-   struct path root;
-   int ret;
-
-   if (!path || !*path)
-   return -EINVAL;
-
-   task_lock(_task);
-   get_fs_root(init_task.fs, );
-   task_unlock(_task);
-
-   file = file_open_root(root.dentry, root.mnt, path, O_RDONLY, 0);
-   path_put();
-   if (IS_ERR(file))
-   return PTR_ERR(file);
-
-   ret = kernel_read_file(file, buf, size, max_size, id);
-   fput(file);
-   return ret;
-}
-EXPORT_SYMBOL_GPL(kernel_read_file_from_path_initns);
-
-int kernel_read_file_from_fd(int fd, void **buf, loff_t *size, loff_t max_size,
-enum kernel_read_file_id id)
-{
-   struct fd f = fdget(fd);
-   int ret = -EBADF;
-
-   if (!f.file)
-   goto out;
-
-   ret = kernel_read_file(f.file, buf, size, max_size, id);
-out:
-   fdput(f);
-   return ret;
-}
-EXPORT_SYMBOL_GPL(kernel_read_file_from_fd);
-
 #if defined(CONFIG_HAVE_AOUT) || defined(CONFIG_BINFMT_FLAT) || \
 defined(CONFIG_BINFMT_ELF_FDPIC)
 ssize_t read_code(struct file *file, unsigned long 

[PATCH v4 00/17] Introduce partial kernel_read_file() support

[Kees Cook]

v4:
- add more reviews (mimi, luis)
- adjusted comment (mimi)
- fixed build error when not building firmware tests (0day, sfr)
- fixed needless .xz read (tiwai)
- rebased to driver-core-next
v3: https://lore.kernel.org/lkml/20200724213640.389191-1-keesc...@chromium.org/
v2: lost to the ether
v1: https://lore.kernel.org/lkml/20200717174309.1164575-1-keesc...@chromium.org/

Hi,

Here's my tree for adding partial read support in kernel_read_file(),
which fixes a number of issues along the way. It's got Scott's firmware
and IMA patches ported and everything tests cleanly for me (even with
CONFIG_IMA_APPRAISE=y), and now appears to pass 0day. :)

The intention is for this to go via Greg's tree since Scott's driver
code will depend on it.

Thanks,

-Kees

Kees Cook (13):
  test_firmware: Test platform fw loading on non-EFI systems
  fs/kernel_read_file: Remove FIRMWARE_PREALLOC_BUFFER enum
  fs/kernel_read_file: Remove FIRMWARE_EFI_EMBEDDED enum
  fs/kernel_read_file: Split into separate source file
  fs/kernel_read_file: Remove redundant size argument
  fs/kernel_read_file: Switch buffer size arg to size_t
  fs/kernel_read_file: Add file_size output argument
  LSM: Introduce kernel_post_load_data() hook
  firmware_loader: Use security_post_load_data()
  module: Call security_kernel_post_load_data()
  LSM: Add "contents" flag to kernel_read_file hook
  fs/kernel_file_read: Add "offset" arg for partial reads
  firmware: Store opt_flags in fw_priv

Scott Branden (4):
  fs/kernel_read_file: Split into separate include file
  IMA: Add support for file reads without contents
  firmware: Add request_partial_firmware_into_buf()
  test_firmware: Test partial read support

 drivers/base/firmware_loader/fallback.c   |  19 +-
 drivers/base/firmware_loader/fallback.h   |   5 +-
 .../base/firmware_loader/fallback_platform.c  |  11 +-
 drivers/base/firmware_loader/firmware.h   |   7 +-
 drivers/base/firmware_loader/main.c   | 135 ++---
 drivers/firmware/efi/embedded-firmware.c  |  21 +-
 drivers/firmware/efi/embedded-firmware.h  |  21 ++
 fs/Makefile   |   3 +-
 fs/exec.c | 132 +---
 fs/kernel_read_file.c | 189 ++
 include/linux/efi_embedded_fw.h   |  13 --
 include/linux/firmware.h  |  12 ++
 include/linux/fs.h|  39 
 include/linux/ima.h   |  19 +-
 include/linux/kernel_read_file.h  |  55 +
 include/linux/lsm_hook_defs.h |   6 +-
 include/linux/lsm_hooks.h |  12 ++
 include/linux/security.h  |  19 +-
 kernel/kexec.c|   2 +-
 kernel/kexec_file.c   |  19 +-
 kernel/module.c   |  24 ++-
 lib/test_firmware.c   | 159 +--
 security/integrity/digsig.c   |   8 +-
 security/integrity/ima/ima_fs.c   |  10 +-
 security/integrity/ima/ima_main.c |  70 +--
 security/integrity/ima/ima_policy.c   |   1 +
 security/loadpin/loadpin.c|  17 +-
 security/security.c   |  26 ++-
 security/selinux/hooks.c  |   8 +-
 .../selftests/firmware/fw_filesystem.sh   |  91 +
 30 files changed, 839 insertions(+), 314 deletions(-)
 create mode 100644 drivers/firmware/efi/embedded-firmware.h
 create mode 100644 fs/kernel_read_file.c
 create mode 100644 include/linux/kernel_read_file.h

-- 
2.25.1

[PATCH v4 04/17] fs/kernel_read_file: Split into separate include file

[Kees Cook]

From: Scott Branden 

Move kernel_read_file* out of linux/fs.h to its own linux/kernel_read_file.h
include file. That header gets pulled in just about everywhere
and doesn't really need functions not related to the general fs interface.

Suggested-by: Christoph Hellwig 
Signed-off-by: Scott Branden 
Reviewed-by: Christoph Hellwig 
Acked-by: Greg Kroah-Hartman 
Link: 
https://lore.kernel.org/r/20200706232309.12010-2-scott.bran...@broadcom.com
Reviewed-by: Mimi Zohar 
Reviewed-by: Luis Chamberlain 
Signed-off-by: Kees Cook 
---
 drivers/base/firmware_loader/main.c |  1 +
 fs/exec.c   |  1 +
 include/linux/fs.h  | 38 -
 include/linux/ima.h |  1 +
 include/linux/kernel_read_file.h| 51 +
 include/linux/security.h|  1 +
 kernel/kexec_file.c |  1 +
 kernel/module.c |  1 +
 security/integrity/digsig.c |  1 +
 security/integrity/ima/ima_fs.c |  1 +
 security/integrity/ima/ima_main.c   |  1 +
 security/integrity/ima/ima_policy.c |  1 +
 security/loadpin/loadpin.c  |  1 +
 security/security.c |  1 +
 security/selinux/hooks.c|  1 +
 15 files changed, 64 insertions(+), 38 deletions(-)
 create mode 100644 include/linux/kernel_read_file.h

diff --git a/drivers/base/firmware_loader/main.c 
b/drivers/base/firmware_loader/main.c
index fe68ae278201..7fd677281806 100644
--- a/drivers/base/firmware_loader/main.c
+++ b/drivers/base/firmware_loader/main.c
@@ -12,6 +12,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
diff --git a/fs/exec.c b/fs/exec.c
index 2bf549757ce7..07a7fe9ac5be 100644
--- a/fs/exec.c
+++ b/fs/exec.c
@@ -23,6 +23,7 @@
  * formats.
  */
 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 0d4f7aacf286..76283ff04d37 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2993,44 +2993,6 @@ static inline void i_readcount_inc(struct inode *inode)
 #endif
 extern int do_pipe_flags(int *, int);
 
-/* This is a list of *what* is being read, not *how* nor *where*. */
-#define __kernel_read_file_id(id) \
-   id(UNKNOWN, unknown)\
-   id(FIRMWARE, firmware)  \
-   id(MODULE, kernel-module)   \
-   id(KEXEC_IMAGE, kexec-image)\
-   id(KEXEC_INITRAMFS, kexec-initramfs)\
-   id(POLICY, security-policy) \
-   id(X509_CERTIFICATE, x509-certificate)  \
-   id(MAX_ID, )
-
-#define __fid_enumify(ENUM, dummy) READING_ ## ENUM,
-#define __fid_stringify(dummy, str) #str,
-
-enum kernel_read_file_id {
-   __kernel_read_file_id(__fid_enumify)
-};
-
-static const char * const kernel_read_file_str[] = {
-   __kernel_read_file_id(__fid_stringify)
-};
-
-static inline const char *kernel_read_file_id_str(enum kernel_read_file_id id)
-{
-   if ((unsigned)id >= READING_MAX_ID)
-   return kernel_read_file_str[READING_UNKNOWN];
-
-   return kernel_read_file_str[id];
-}
-
-extern int kernel_read_file(struct file *, void **, loff_t *, loff_t,
-   enum kernel_read_file_id);
-extern int kernel_read_file_from_path(const char *, void **, loff_t *, loff_t,
- enum kernel_read_file_id);
-extern int kernel_read_file_from_path_initns(const char *, void **, loff_t *, 
loff_t,
-enum kernel_read_file_id);
-extern int kernel_read_file_from_fd(int, void **, loff_t *, loff_t,
-   enum kernel_read_file_id);
 extern ssize_t kernel_read(struct file *, void *, size_t, loff_t *);
 ssize_t __kernel_read(struct file *file, void *buf, size_t count, loff_t *pos);
 extern ssize_t kernel_write(struct file *, const void *, size_t, loff_t *);
diff --git a/include/linux/ima.h b/include/linux/ima.h
index 9164e1534ec9..148636bfcc8f 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -7,6 +7,7 @@
 #ifndef _LINUX_IMA_H
 #define _LINUX_IMA_H
 
+#include 
 #include 
 #include 
 #include 
diff --git a/include/linux/kernel_read_file.h b/include/linux/kernel_read_file.h
new file mode 100644
index ..78cf3d7dc835
--- /dev/null
+++ b/include/linux/kernel_read_file.h
@@ -0,0 +1,51 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_KERNEL_READ_FILE_H
+#define _LINUX_KERNEL_READ_FILE_H
+
+#include 
+#include 
+
+/* This is a list of *what* is being read, not *how* nor *where*. */
+#define __kernel_read_file_id(id) \
+   id(UNKNOWN, unknown)\
+   id(FIRMWARE, firmware)  \
+   id(MODULE, kernel-module)   \
+   id(KEXEC_IMAGE, kexec-image)\
+   id(KEXEC_INITRAMFS, kexec-initramfs)\
+   id(POLICY, security-policy) \
+   id(X509_CERTIFICATE, x509-certificate)  \
+   id(MAX_ID, )
+
+#define __fid_enumify(ENUM, dummy) READING_ ## ENUM,