Re: [PATCH] pinctrl: actions: Add the platform dependency to drivers

[Linus Walleij]

On Thu, Jan 21, 2021 at 7:26 AM Manivannan Sadhasivam
 wrote:

> The Actions Semi pinctrl drivers are a mix of both ARM32 and ARM64
> platforms. So let's add the correct platform dependency to avoid them
> being selected on the other.
>
> Signed-off-by: Manivannan Sadhasivam 

Are you not opting out of build tests when you do this?

What about:

depends on ARM64 || COMPILE_TEST
(etc)
?

Yours,
Linus Walleij

Yours,
Linus Walleij

Re: [PATCH v5 3/6] kasan: Add report for async mode

[Catalin Marinas]

On Thu, Jan 21, 2021 at 04:39:40PM +, Vincenzo Frascino wrote:
> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
> index bb862d1f0e15..b0a1d9dfa85c 100644
> --- a/include/linux/kasan.h
> +++ b/include/linux/kasan.h
> @@ -351,6 +351,8 @@ static inline void *kasan_reset_tag(const void *addr)
>  bool kasan_report(unsigned long addr, size_t size,
>   bool is_write, unsigned long ip);
>  
> +void kasan_report_async(void);
> +
>  #else /* CONFIG_KASAN_SW_TAGS || CONFIG_KASAN_HW_TAGS */
>  
>  static inline void *kasan_reset_tag(const void *addr)
> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
> index 234f35a84f19..2fd6845a95e9 100644
> --- a/mm/kasan/report.c
> +++ b/mm/kasan/report.c
> @@ -358,6 +358,17 @@ void kasan_report_invalid_free(void *object, unsigned 
> long ip)
>   end_report(&flags);
>  }
>  
> +void kasan_report_async(void)
> +{
> + unsigned long flags;
> +
> + start_report(&flags);
> + pr_err("BUG: KASAN: invalid-access\n");
> + pr_err("Asynchronous mode enabled: no access details available\n");
> + dump_stack();
> + end_report(&flags);
> +}

I think the kernel test robot complains that with KASAN_SW_TAGS and
HW_TAGS disabled, the kasan_report_async() prototype is no longer
visible but you still have the non-static function definition here. So
either move kasan_report_async() out of this #ifdef or add the #ifdef
around the function definition.

It looks like the original kasan_report() prototype is declared in two
places (second one in mm/kasan/kasan.h). I'd remove the latter and try
to have a consistent approach for kasan_report() and
kasan_report_async().

-- 
Catalin

Re: [PATCH v2] PCI: Re-enable downstream port LTR if it was previously enabled

[Bjorn Helgaas]

On Fri, Jan 22, 2021 at 03:03:11PM +0800, Mingchuang Qiao wrote:
> On Thu, 2021-01-21 at 16:31 -0600, Bjorn Helgaas wrote:
> > [+cc Alex and Mingchuang et al from
> > https://lore.kernel.org/r/20210112072739.31624-1-mingchuang.q...@mediatek.com]
> > 
> > On Tue, Jan 19, 2021 at 04:14:10PM +0300, Mika Westerberg wrote:
> > > PCIe r5.0, sec 7.5.3.16 says that the downstream ports must reset the
> > > LTR enable bit if the link goes down (port goes DL_Down status). Now, if
> > > we had LTR previously enabled and the PCIe endpoint gets hot-removed and
> > > then hot-added back the ->ltr_path of the downstream port is still set
> > > but the port now does not have the LTR enable bit set anymore.
> > > 
> > > For this reason check if the bridge upstream had LTR enabled previously
> > > and re-enable it before enabling LTR for the endpoint.
> > > 
> > > Reported-by: Utkarsh H Patel 
> > > Signed-off-by: Mika Westerberg 
> > 
> > I think this and Mingchuang's patch, which is essentially identical,
> > are right and solves the problem for hot-remove/hot-add.  In that
> > scenario we call pci_configure_ltr() on the hot-added device, and
> > with this patch, we'll re-enable LTR on the bridge leading to the new
> > device before enabling LTR on the new device itself.
> > 
> > But don't we have a similar problem if we simply do a Fundamental
> > Reset on a device?  I think the reset path will restore the device's
> > state, including PCI_EXP_DEVCTL2, but it doesn't do anything with the
> > upstream bridge, does it?
> 
> Yes. I think the same problem exists under such scenario, and that’s the
> issue my patch intends to resolve.
> I also prepared a v2 patch for review(update the patch description).
> Shall I submit the v2 patch for review?

How does your patch solve this for the reset path?  I don't think we
call pci_configure_ltr() when we reset a device.

> > So if a bridge and a device below it both have LTR enabled, can't we
> > have the following:
> > 
> >   - bridge LTR enabled
> >   - device LTR enabled
> >   - reset device, e.g., via Secondary Bus Reset
> >   - link goes down, bridge disables LTR
> >   - link comes back up, LTR disabled in both bridge and device
> >   - restore device state, including LTR enable
> >   - device sends LTR message
> >   - bridge reports Unsupported Request
> > 
> > > ---
> > > Previous version can be found here:
> > > 
> > >   
> > > https://lore.kernel.org/linux-pci/20210114134724.79511-1-mika.westerb...@linux.intel.com/
> > > 
> > > Changes from the previous version:
> > > 
> > >   * Corrected typos in the commit message
> > >   * No need to call pcie_downstream_port()
> > > 
> > >  drivers/pci/probe.c | 17 -
> > >  1 file changed, 16 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > > index 0eb68b47354f..a4a8c0305fb9 100644
> > > --- a/drivers/pci/probe.c
> > > +++ b/drivers/pci/probe.c
> > > @@ -2153,7 +2153,7 @@ static void pci_configure_ltr(struct pci_dev *dev)
> > >  {
> > >  #ifdef CONFIG_PCIEASPM
> > >   struct pci_host_bridge *host = pci_find_host_bridge(dev->bus);
> > > - struct pci_dev *bridge;
> > > + struct pci_dev *bridge = NULL;
> > >   u32 cap, ctl;
> > >  
> > >   if (!pci_is_pcie(dev))
> > > @@ -2191,6 +2191,21 @@ static void pci_configure_ltr(struct pci_dev *dev)
> > >   if (pci_pcie_type(dev) == PCI_EXP_TYPE_ROOT_PORT ||
> > >   ((bridge = pci_upstream_bridge(dev)) &&
> > > bridge->ltr_path)) {
> > > + /*
> > > +  * Downstream ports reset the LTR enable bit when the
> > > +  * link goes down (e.g on hot-remove) so re-enable the
> > > +  * bit here if not set anymore.
> > > +  * PCIe r5.0, sec 7.5.3.16.
> > > +  */
> > > + if (bridge) {
> > > + pcie_capability_read_dword(bridge, PCI_EXP_DEVCTL2, 
> > > &ctl);
> > > + if (!(ctl & PCI_EXP_DEVCTL2_LTR_EN)) {
> > > + pci_dbg(bridge, "re-enabling LTR\n");
> > > + pcie_capability_set_word(bridge, 
> > > PCI_EXP_DEVCTL2,
> > > +  
> > > PCI_EXP_DEVCTL2_LTR_EN);
> > > + }
> > > + }
> > > + pci_dbg(dev, "enabling LTR\n");
> > >   pcie_capability_set_word(dev, PCI_EXP_DEVCTL2,
> > >PCI_EXP_DEVCTL2_LTR_EN);
> > >   dev->ltr_path = 1;
> > > -- 
> > > 2.29.2
> > > 
> 

Re: [PATCH] pinctrl: clarify #pinctrl-cells for pinctrl-single,pins

[Linus Walleij]

On Wed, Jan 20, 2021 at 6:04 AM Drew Fustini  wrote:

> Document that #pinctrl-cells can be 1 or 2 for pinctrl-single,pins
>
> Fixes: 27c90e5e48d0 ("ARM: dts: am33xx-l4: change #pinctrl-cells from 1 to 2")
> Reported-by: Emmanuel Vadot 
> Link: 
> https://lore.kernel.org/linux-gpio/20210115190201.9273b637a7f967e7e55bc...@bidouilliste.com/
> Cc: Tony Lindgren 
> Signed-off-by: Drew Fustini 

Patch applied!

Yours,
Linus Walleij

Re: [PATCH 1/1] iommu/arm-smmu-v3: add support for BBML

[Leizhen (ThunderTown)]

On 2021/1/22 21:00, Robin Murphy wrote:
> On 2021-01-22 12:51, Will Deacon wrote:
>> On Thu, Nov 26, 2020 at 11:42:30AM +0800, Zhen Lei wrote:
>>> When changing from a set of pages/smaller blocks to a larger block for an
>>> address, the software should follow the sequence of BBML processing.
>>>
>>> When changing from a block to a set of pages/smaller blocks for an
>>> address, there's no need to use nT bit. If an address in the large block
>>> is accessed before page table switching, the TLB caches the large block
>>> mapping. After the page table is switched and before TLB invalidation
>>> finished, new access requests are still based on large block mapping.
>>> After the block or page is invalidated, the system reads the small block
>>> or page mapping from the memory; If the address in the large block is not
>>> accessed before page table switching, the TLB has no cache. After the
>>> page table is switched, a new access is initiated to read the small block
>>> or page mapping from the memory.
>>>
>>> Signed-off-by: Zhen Lei 
>>> ---
>>>   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c |  2 +
>>>   drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h |  2 +
>>>   drivers/iommu/io-pgtable-arm.c  | 46 -
>>>   include/linux/io-pgtable.h  |  1 +
>>>   4 files changed, 40 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c 
>>> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>>> index e634bbe60573..14a1a11565fb 100644
>>> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>>> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
>>> @@ -1977,6 +1977,7 @@ static int arm_smmu_domain_finalise(struct 
>>> iommu_domain *domain,
>>>   .coherent_walk    = smmu->features & ARM_SMMU_FEAT_COHERENCY,
>>>   .tlb    = &arm_smmu_flush_ops,
>>>   .iommu_dev    = smmu->dev,
>>> +    .bbml    = smmu->bbml,
>>>   };
>>>     if (smmu_domain->non_strict)
>>> @@ -3291,6 +3292,7 @@ static int arm_smmu_device_hw_probe(struct 
>>> arm_smmu_device *smmu)
>>>     /* IDR3 */
>>>   reg = readl_relaxed(smmu->base + ARM_SMMU_IDR3);
>>> +    smmu->bbml = FIELD_GET(IDR3_BBML, reg);
>>>   if (FIELD_GET(IDR3_RIL, reg))
>>>   smmu->features |= ARM_SMMU_FEAT_RANGE_INV;
>>>   diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h 
>>> b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
>>> index d4b7f40ccb02..aa7eb460fa09 100644
>>> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
>>> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
>>> @@ -51,6 +51,7 @@
>>>   #define IDR1_SIDSIZE    GENMASK(5, 0)
>>>     #define ARM_SMMU_IDR3    0xc
>>> +#define IDR3_BBML    GENMASK(12, 11)
>>>   #define IDR3_RIL    (1 << 10)
>>>     #define ARM_SMMU_IDR5    0x14
>>> @@ -617,6 +618,7 @@ struct arm_smmu_device {
>>>     int    gerr_irq;
>>>   int    combined_irq;
>>> +    int    bbml;
>>>     unsigned long    ias; /* IPA */
>>>   unsigned long    oas; /* PA */
>>> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
>>> index a7a9bc08dcd1..341581337ad0 100644
>>> --- a/drivers/iommu/io-pgtable-arm.c
>>> +++ b/drivers/iommu/io-pgtable-arm.c
>>> @@ -72,6 +72,7 @@
>>>     #define ARM_LPAE_PTE_NSTABLE    (((arm_lpae_iopte)1) << 63)
>>>   #define ARM_LPAE_PTE_XN    (((arm_lpae_iopte)3) << 53)
>>> +#define ARM_LPAE_PTE_nT    (((arm_lpae_iopte)1) << 16)
>>>   #define ARM_LPAE_PTE_AF    (((arm_lpae_iopte)1) << 10)
>>>   #define ARM_LPAE_PTE_SH_NS    (((arm_lpae_iopte)0) << 8)
>>>   #define ARM_LPAE_PTE_SH_OS    (((arm_lpae_iopte)2) << 8)
>>> @@ -255,7 +256,7 @@ static size_t __arm_lpae_unmap(struct 
>>> arm_lpae_io_pgtable *data,
>>>     static void __arm_lpae_init_pte(struct arm_lpae_io_pgtable *data,
>>>   phys_addr_t paddr, arm_lpae_iopte prot,
>>> -    int lvl, arm_lpae_iopte *ptep)
>>> +    int lvl, arm_lpae_iopte *ptep, arm_lpae_iopte nT)
>>>   {
>>>   arm_lpae_iopte pte = prot;
>>>   @@ -265,37 +266,60 @@ static void __arm_lpae_init_pte(struct 
>>> arm_lpae_io_pgtable *data,
>>>   pte |= ARM_LPAE_PTE_TYPE_BLOCK;
>>>     pte |= paddr_to_iopte(paddr, data);
>>> +    pte |= nT;
>>>     __arm_lpae_set_pte(ptep, pte, &data->iop.cfg);
>>>   }
>>>   +static void __arm_lpae_free_pgtable(struct arm_lpae_io_pgtable *data, 
>>> int lvl,
>>> +    arm_lpae_iopte *ptep);
>>>   static int arm_lpae_init_pte(struct arm_lpae_io_pgtable *data,
>>>    unsigned long iova, phys_addr_t paddr,
>>>    arm_lpae_iopte prot, int lvl,
>>>    arm_lpae_iopte *ptep)
>>>   {
>>>   arm_lpae_iopte pte = *ptep;
>>> +    struct io_pgtable_cfg *cfg = &data->iop.cfg;
>>>     if (iopte_leaf(pte, lvl, data->iop.fmt)) {
>>>   /* We require an unmap first */
>>>   

Re: [PATCH v2 08/12] ASoC: arizona-jack: convert into a helper library for codec drivers

[Charles Keepax]

On Thu, Jan 21, 2021 at 05:55:00PM +0100, Hans de Goede wrote:
> On 1/19/21 10:51 AM, Richard Fitzgerald wrote:
> > On 18/01/2021 17:24, Andy Shevchenko wrote:
> >> On Sun, Jan 17, 2021 at 6:06 PM Hans de Goede  wrote:
> 1. Keep the code as is, live with the debugfs error. This might be
> best for now, as I don't want to grow the scope of this series too much.
> I will go with this for the next version of this series (unless
> I receive feedback otherwise before I get around to posting the next
> version).

Thinking about this more, I seem to remember this is something
that has been discussed before, having the need to have
situations where a driver and the framework are both managing the
regulator at once on the same device.

I wonder if this commit was related to that:

commit ff268b56ce8c ("regulator: core: Don't spew backtraces on duplicate 
sysfs")

Apologies I don't have as much time as I normally would to look
into such issues at the moment, due to various internal company
things going on.

I do suspect that this option is the way to go though and if
there are issues of duplicates being created by the regulator
core those probably need to be resolved in there. But that can
probably be done separate from this series.

Thanks,
Charles

Re: [PATCH v3 0/5] Scan for an idle sibling in a single pass

[Vincent Guittot]

On Fri, 22 Jan 2021 at 11:14, Mel Gorman  wrote:
>
> On Fri, Jan 22, 2021 at 10:30:52AM +0100, Vincent Guittot wrote:
> > Hi Mel,
> >
> > On Tue, 19 Jan 2021 at 13:02, Mel Gorman  
> > wrote:
> > >
> > > On Tue, Jan 19, 2021 at 12:33:04PM +0100, Vincent Guittot wrote:
> > > > On Tue, 19 Jan 2021 at 12:22, Mel Gorman  
> > > > wrote:
> > > > >
> > > > > Changelog since v2
> > > > > o Remove unnecessary parameters
> > > > > o Update nr during scan only when scanning for cpus
> > > >
> > > > Hi Mel,
> > > >
> > > > I haven't looked at your previous version mainly because I'm chasing a
> > > > performance regression on v5.11-rcx which prevents me from testing the
> > > > impact of your patchset on my !SMT2 system.
> > > > Will do this as soon as this problem is fixed
> > > >
> > >
> > > Thanks, that would be appreciated as I do not have access to a !SMT2
> > > system to do my own evaluation.
> >
> > I have been able to run tests with your patchset on both large arm64
> > SMT4 system and small arm64 !SMT system and patch 3 is still a source
> > of regression on both. Decreasing min number of loops to 2 instead of
> > 4 and scaling it with smt weight doesn't seem to be a good option as
> > regressions disappear when I remove them as I tested with the patch
> > below
> >
> > hackbench -l 2560 -g 1 on 8 cores arm64
> > v5.11-rc4 : 1.355 (+/- 7.96)
> > + sis improvement : 1.923 (+/- 25%)
> > + the patch below : 1.332 (+/- 4.95)
> >
> > hackbench -l 2560 -g 256 on 8 cores arm64
> > v5.11-rc4 : 2.116 (+/- 4.62%)
> > + sis improvement : 2.216 (+/- 3.84%)
> > + the patch below : 2.113 (+/- 3.01%)
> >
> > So starting with a min of 2 loops instead of 4 currently and scaling
> > nr loop with smt weight doesn't seem to be a good option and we should
> > remove it for now
> >
>
> Ok
>
> Note that this is essentially reverting the patch. As you remove "nr *=
> sched_smt_weight", the scan is no longer proportional to cores, it's

Yes. My goal above was to narrow the changes only to lines that
generate the regressions but i agree that removing patch 3 is the
right solution


> proportial to logical CPUs and the rest of the patch and changelog becomes
> meaningless. On that basis, I'll queue tests over the weekend that remove
> this patch entirely and keep the CPU scan as a single pass.
>
> --
> Mel Gorman
> SUSE Labs

[PATCH] regulator: Fix lockdep warning resolving supplies

[Mark Brown]

With commit eaa7995c529b54 (regulator: core: avoid
regulator_resolve_supply() race condition) we started holding the rdev
lock while resolving supplies, an operation that requires holding the
regulator_list_mutex. This results in lockdep warnings since in other
places we take the list mutex then the mutex on an individual rdev.

Since the goal is to make sure that we don't call set_supply() twice
rather than a concern about the cost of resolution pull the rdev lock
and check for duplicate resolution down to immediately before we do the
set_supply() and drop it again once the allocation is done.

Fixes: eaa7995c529b54 (regulator: core: avoid regulator_resolve_supply() race 
condition)
Reported-by: Marek Szyprowski 
Tested-by: Marek Szyprowski 
Signed-off-by: Mark Brown 
---
 drivers/regulator/core.c | 29 +
 1 file changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 3ae5ccd9277d..3b73634d50ff 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -1823,17 +1823,6 @@ static int regulator_resolve_supply(struct regulator_dev 
*rdev)
if (rdev->supply)
return 0;
 
-   /*
-* Recheck rdev->supply with rdev->mutex lock held to avoid a race
-* between rdev->supply null check and setting rdev->supply in
-* set_supply() from concurrent tasks.
-*/
-   regulator_lock(rdev);
-
-   /* Supply just resolved by a concurrent task? */
-   if (rdev->supply)
-   goto out;
-
r = regulator_dev_lookup(dev, rdev->supply_name);
if (IS_ERR(r)) {
ret = PTR_ERR(r);
@@ -1885,12 +1874,29 @@ static int regulator_resolve_supply(struct 
regulator_dev *rdev)
goto out;
}
 
+   /*
+* Recheck rdev->supply with rdev->mutex lock held to avoid a race
+* between rdev->supply null check and setting rdev->supply in
+* set_supply() from concurrent tasks.
+*/
+   regulator_lock(rdev);
+
+   /* Supply just resolved by a concurrent task? */
+   if (rdev->supply) {
+   regulator_unlock(rdev);
+   put_device(&r->dev);
+   goto out;
+   }
+
ret = set_supply(rdev, r);
if (ret < 0) {
+   regulator_unlock(rdev);
put_device(&r->dev);
goto out;
}
 
+   regulator_unlock(rdev);
+
/*
 * In set_machine_constraints() we may have turned this regulator on
 * but we couldn't propagate to the supply if it hadn't been resolved
@@ -1906,7 +1912,6 @@ static int regulator_resolve_supply(struct regulator_dev 
*rdev)
}
 
 out:
-   regulator_unlock(rdev);
return ret;
 }
 
-- 
2.20.1

Re: [PATCH v6 3/6] tracing: Update synth command errors

[Masami Hiramatsu]

Hi Tom,

On Thu, 21 Jan 2021 11:01:06 -0600
Tom Zanussi  wrote:

> Since array types are handled differently, errors referencing them
> also need to be handled differently.  Add and use a new
> INVALID_ARRAY_SPEC error.  Also add INVALID_CMD and INVALID_DYN_CMD to
> catch and display the correct form for badly-formed commands, which
> can also be used in place of CMD_INCOMPLETE, which is removed, and
> remove CMD_TOO_LONG, since it's no longer used.

OK, so this will add new errors for precise error logging.

> 
> Signed-off-by: Tom Zanussi 
> ---
>  kernel/trace/trace_events_synth.c | 72 +++
>  1 file changed, 63 insertions(+), 9 deletions(-)
> 
> diff --git a/kernel/trace/trace_events_synth.c 
> b/kernel/trace/trace_events_synth.c
> index a79c17b97add..dd141ee6b3fc 100644
> --- a/kernel/trace/trace_events_synth.c
> +++ b/kernel/trace/trace_events_synth.c
> @@ -23,13 +23,14 @@
>  #undef ERRORS
>  #define ERRORS   \
>   C(BAD_NAME, "Illegal name"),\
> - C(CMD_INCOMPLETE,   "Incomplete command"),  \
> + C(INVALID_CMD,  "Command must be of the form:  
> field[;field] ..."),\
> + C(INVALID_DYN_CMD,  "Command must be of the form: s or 
> -:[synthetic/] field[;field] ..."),\
>   C(EVENT_EXISTS, "Event already exists"),\
>   C(TOO_MANY_FIELDS,  "Too many fields"), \
>   C(INCOMPLETE_TYPE,  "Incomplete type"), \
>   C(INVALID_TYPE, "Invalid type"),\
> - C(INVALID_FIELD,"Invalid field"),   \
> - C(CMD_TOO_LONG, "Command too long"),
> + C(INVALID_FIELD,"Invalid field"),   \
> + C(INVALID_ARRAY_SPEC,   "Invalid array specification"),
>  
>  #undef C
>  #define C(a, b)  SYNTH_ERR_##a
> @@ -655,7 +656,10 @@ static struct synth_field *parse_synth_field(int argc, 
> char **argv)
>  
>   size = synth_field_size(field->type);
>   if (size < 0) {
> - synth_err(SYNTH_ERR_INVALID_TYPE, errpos(field_type));
> + if (array)
> + synth_err(SYNTH_ERR_INVALID_ARRAY_SPEC, 
> errpos(field_name));
> + else
> + synth_err(SYNTH_ERR_INVALID_TYPE, errpos(field_type));
>   ret = -EINVAL;
>   goto free;
>   } else if (size == 0) {
> @@ -1176,7 +1180,7 @@ static int __create_synth_event(const char *name, const 
> char *raw_fields)
>   mutex_lock(&event_mutex);
>  
>   if (name[0] == '\0') {
> - synth_err(SYNTH_ERR_CMD_INCOMPLETE, 0);
> + synth_err(SYNTH_ERR_INVALID_CMD, 0);
>   ret = -EINVAL;
>   goto out;
>   }
> @@ -1228,7 +1232,7 @@ static int __create_synth_event(const char *name, const 
> char *raw_fields)
>   }
>  
>   if (n_fields == 0) {
> - synth_err(SYNTH_ERR_CMD_INCOMPLETE, 0);
> + synth_err(SYNTH_ERR_INVALID_CMD, 0);
>   ret = -EINVAL;
>   goto err;
>   }
> @@ -1366,6 +1370,40 @@ int synth_event_delete(const char *event_name)
>  }
>  EXPORT_SYMBOL_GPL(synth_event_delete);
>  
> +static int check_command(const char *raw_command)
> +{
> + char **argv = NULL, *cmd, *saved_cmd, *name_and_field;
> + int argc, ret = 0;
> +
> + cmd = saved_cmd = kstrdup(raw_command, GFP_KERNEL);
> + if (!cmd)
> + return -ENOMEM;
> +
> + name_and_field = strsep(&cmd, ";");
> + if (!name_and_field) {
> + ret = -EINVAL;
> + goto free;
> + }
> +
> + if (name_and_field[0] == '!')
> + goto free;
> +
> + argv = argv_split(GFP_KERNEL, name_and_field, &argc);
> + if (!argv) {
> + ret = -ENOMEM;
> + goto free;
> + }
> +
> + if (argc < 3)
> + ret = -EINVAL;
> +free:
> + kfree(saved_cmd);
> + if (argv)
> + argv_free(argv);
> +
> + return ret;
> +}

But I'm not sure why this (yet another parser) is needed. What you are expecting
for this check_command()? Could you tell me some examples?

Thank you,



-- 
Masami Hiramatsu 

Re: [PATCH v5 3/6] kasan: Add report for async mode

[Vincenzo Frascino]

On 1/22/21 1:19 PM, Catalin Marinas wrote:
> On Thu, Jan 21, 2021 at 04:39:40PM +, Vincenzo Frascino wrote:
>> diff --git a/include/linux/kasan.h b/include/linux/kasan.h
>> index bb862d1f0e15..b0a1d9dfa85c 100644
>> --- a/include/linux/kasan.h
>> +++ b/include/linux/kasan.h
>> @@ -351,6 +351,8 @@ static inline void *kasan_reset_tag(const void *addr)
>>  bool kasan_report(unsigned long addr, size_t size,
>>  bool is_write, unsigned long ip);
>>  
>> +void kasan_report_async(void);
>> +
>>  #else /* CONFIG_KASAN_SW_TAGS || CONFIG_KASAN_HW_TAGS */
>>  
>>  static inline void *kasan_reset_tag(const void *addr)
>> diff --git a/mm/kasan/report.c b/mm/kasan/report.c
>> index 234f35a84f19..2fd6845a95e9 100644
>> --- a/mm/kasan/report.c
>> +++ b/mm/kasan/report.c
>> @@ -358,6 +358,17 @@ void kasan_report_invalid_free(void *object, unsigned 
>> long ip)
>>  end_report(&flags);
>>  }
>>  
>> +void kasan_report_async(void)
>> +{
>> +unsigned long flags;
>> +
>> +start_report(&flags);
>> +pr_err("BUG: KASAN: invalid-access\n");
>> +pr_err("Asynchronous mode enabled: no access details available\n");
>> +dump_stack();
>> +end_report(&flags);
>> +}
> 
> I think the kernel test robot complains that with KASAN_SW_TAGS and
> HW_TAGS disabled, the kasan_report_async() prototype is no longer
> visible but you still have the non-static function definition here. So
> either move kasan_report_async() out of this #ifdef or add the #ifdef
> around the function definition.
>

I think adding #ifdef around the function would be the best way in this case,
for consistency with the header.

> It looks like the original kasan_report() prototype is declared in two
> places (second one in mm/kasan/kasan.h). I'd remove the latter and try
> to have a consistent approach for kasan_report() and
> kasan_report_async().
> 

Ok, I will remove it.

-- 
Regards,
Vincenzo

Re: [PATCHv2] lockdep: report broken irq restoration

[Peter Zijlstra]

On Fri, Jan 22, 2021 at 11:06:25AM +, Mark Rutland wrote:
> Hi all,
> 
> Any thoughts on this? I'd like to get this in soon if we could as it'll
> help to flush out any remaining issues that are liable to get in the way
> of planned rework for arm64 and x86.
> 

Ah, I actually have it queued, I'll try and push it out to locking/core
later today.

Re: [PATCH 2/2] spidev: Add cisco device compatible

[Mark Brown]

On Thu, Jan 21, 2021 at 03:12:36PM -0800, Daniel Walker wrote:
> Add compatible string for Cisco device present on the Cisco Petra
> platform.

I'm missing patch 1 of this series, what's the story with dependencies?


signature.asc
Description: PGP signature

Re: [PATCH 1/1] iommu/arm-smmu-v3: add support for BBML

[Will Deacon]

On Fri, Jan 22, 2021 at 09:21:20PM +0800, Leizhen (ThunderTown) wrote:
> On 2021/1/22 21:00, Robin Murphy wrote:
> > On 2021-01-22 12:51, Will Deacon wrote:
> >> On Thu, Nov 26, 2020 at 11:42:30AM +0800, Zhen Lei wrote:
> >>>   -    tblp = ptep - ARM_LPAE_LVL_IDX(iova, lvl, data);
> >>> -    if (__arm_lpae_unmap(data, NULL, iova, sz, lvl, tblp) != sz) {
> >>> -    WARN_ON(1);
> >>> -    return -EINVAL;
> >>> +    switch (cfg->bbml) {
> >>> +    case 0:
> >>> +    /*
> >>> + * We need to unmap and free the old table before
> >>> + * overwriting it with a block entry.
> >>> + */
> >>> +    tblp = ptep - ARM_LPAE_LVL_IDX(iova, lvl, data);
> >>> +    if (__arm_lpae_unmap(data, NULL, iova, sz, lvl, tblp) != sz) 
> >>> {
> >>> +    WARN_ON(1);
> >>> +    return -EINVAL;
> >>> +    }
> >>> +    break;
> >>> +    case 1:
> >>> +    __arm_lpae_init_pte(data, paddr, prot, lvl, ptep, 
> >>> ARM_LPAE_PTE_nT);
> >>> +
> >>> +    io_pgtable_tlb_flush_walk(iop, iova, sz, 
> >>> ARM_LPAE_GRANULE(data));
> >>> +    tblp = iopte_deref(pte, data);
> >>> +    __arm_lpae_free_pgtable(data, lvl + 1, tblp);
> >>> +    break;
> >>> +    case 2:
> >>> +    __arm_lpae_init_pte(data, paddr, prot, lvl, ptep, 0);
> >>> +
> >>> +    io_pgtable_tlb_flush_walk(iop, iova, sz, 
> >>> ARM_LPAE_GRANULE(data));
> >>> +    tblp = iopte_deref(pte, data);
> >>> +    __arm_lpae_free_pgtable(data, lvl + 1, tblp);
> >>> +    return 0;
> >>
> >> Sorry, but I really don't understand what you're trying to do here. The old
> >> code uses BBM for the table -> block path so we don't need anything extra
> >> here. The dodgy case is when we unmap part of a block, and end up 
> >> installing
> >> a table via arm_lpae_split_blk_unmap(). We can't use BBM there because 
> >> there
> >> could be ongoing DMA to parts of the block mapping that we want to remain 
> >> in
> >> place.
> >>
> >> Are you seeing a problem in practice?
> > 
> > Right, I was under the assumption that we could ignore BBML because we
> > should never have a legitimate reason to split blocks. I'm certainly not
> > keen on piling any more complexity into split_blk_unmap, because the
> > IOMMU API clearly doesn't have a well-defined behaviour for that case
> > anyway - some other drivers will just unmap the entire block, and IIRC
> > there was a hint somewhere in VFIO that it might actually expect that
> > behaviour.
> 
> I'm going home. I'll answer you two tomorrow.

It can wait until Monday! Have a good weekend :)

Will

Re: [PATCH v2 13/15] dt-binding: display: bcm2711-hdmi: Add CEC and hotplug interrupts

[Dave Stevenson]

Hi Maxime

On Mon, 11 Jan 2021 at 14:23, Maxime Ripard  wrote:
>
> The CEC and hotplug interrupts were missing when that binding was
> introduced, let's add them in now that we've figured out how it works.
>
> Signed-off-by: Maxime Ripard 

Looks reasonable to me, but I'm not a DT bindings expert

Acked-by: Dave Stevenson 

> ---
>  .../bindings/display/brcm,bcm2711-hdmi.yaml   | 20 ++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml 
> b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> index 7ce06f9f9f8e..6e8ac910bdd8 100644
> --- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml
> @@ -53,6 +53,24 @@ properties:
>- const: audio
>- const: cec
>
> +  interrupts:
> +items:
> +  - description: CEC TX interrupt
> +  - description: CEC RX interrupt
> +  - description: CEC stuck at low interrupt
> +  - description: Wake-up interrupt
> +  - description: Hotplug connected interrupt
> +  - description: Hotplug removed interrupt
> +
> +  interrupt-names:
> +items:
> +  - const: cec-tx
> +  - const: cec-rx
> +  - const: cec-low
> +  - const: wakeup
> +  - const: hpd-connected
> +  - const: hpd-removed
> +
>ddc:
>  allOf:
>- $ref: /schemas/types.yaml#/definitions/phandle
> @@ -90,7 +108,7 @@ required:
>- resets
>- ddc
>
> -additionalProperties: false
> +unevaluatedProperties: false
>
>  examples:
>- |
> --
> 2.29.2
>

Re: [RESEND PATCH v3 2/2] usb: dwc3: Add driver for Xilinx platforms

[Michael Grzeschik]

On Fri, Jan 22, 2021 at 01:06:22PM +, Manish Narani wrote:

Hi Michael,


-Original Message-
From: Michael Grzeschik 
Sent: Friday, January 22, 2021 1:39 PM
To: Manish Narani 
Cc: devicet...@vger.kernel.org; ker...@pengutronix.de; ba...@kernel.org;
gre...@linuxfoundation.org; linux-...@vger.kernel.org; Michal Simek
; linux-kernel@vger.kernel.org; robh...@kernel.org;
git ; p.za...@pengutronix.de; linux-arm-
ker...@lists.infradead.org
Subject: Re: [RESEND PATCH v3 2/2] usb: dwc3: Add driver for Xilinx
platforms

Hello!

On Mon, Jan 18, 2021 at 02:42:24PM +0100, Michael Grzeschik wrote:
>Hi!
>
>On Tue, Dec 15, 2020 at 12:24:51PM +0530, Manish Narani wrote:
>>Add a new driver for supporting Xilinx platforms. This driver is used
>>for some sequence of operations required for Xilinx USB controllers.
>>This driver is also used to choose between PIPE clock coming from SerDes
>>and the Suspend Clock. Before the controller is out of reset, the clock
>>selection should be changed to PIPE clock in order to make the USB
>>controller work. There is a register added in Xilinx USB controller
>>register space for the same.
>
>I tried out this driver with the vanilla kernel on an zynqmp. Without
>this patch the USB-Gadget is already acting buggy. In the gadget mode,
>some iterations of plug/unplug results to an stalled gadget which will
>never come back without a reboot.
>
>With the corresponding code of this driver (reset assert, clk modify,
>reset deassert) in the downstream kernels phy driver we found out it is
>totaly stable. But using this exact glue driver which should do the same
>as the downstream code, the gadget still was buggy the way described
>above.
>
>I suspect the difference lays in the different order of operations.
>While the downstream code is runing the resets inside the phy driver
>which is powered and initialized in the dwc3-core itself. With this glue
>layser approach of this patch the whole phy init is done before even
>touching dwc3-core in any way. It seems not to have the same effect,
>though.
>
>If really the order of operations is limiting us, we probably need
>another solution than this glue layer. Any Ideas?

I found out what the difference between the Downstream and this
Glue is. When using vanilla with this Glue code we may not set
the following bit:

https://www.xilinx.com/html_docs/registers/ug1087/ug1087-zynq-
ultrascale-registers.html#usb3_regs___fpd_power_prsnt.html

>>+   /* Set PIPE Power Present signal in FPD Power Present Register*/
>>+   writel(PIPE_POWER_ON, priv_data->regs +
XLNX_USB_FPD_POWER_PRSNT);

When I comment this out, the link stays stable. This is different in
the Downstream Xilinx Kernel, where the bit is also set but has no
negativ effect.

Manish, can you give me a pointer what to look for?
So setting this will also work with mainline?

I am looking further on this but from what I see here is that,
In order to make USB function properly, there are some dt changes needed in 
mainline for
USB node which include defining clocks coming from serdes.
The DT changes are pending to be sent to mainline.


Can you push that state somewhere, so I could test it?
Or is in the downstream kernel some things to copy?


Can you share the DT settings for USB node on your side?


Here is my current configuration for the device node at usb0:

zynqmp.dtsi

zynqmp_reset: reset-controller {
compatible = "xlnx,zynqmp-reset";
#reset-cells = <1>;
};

usb0: usb@ff9d {
#address-cells = <2>;
#size-cells = <2>;
status = "disabled";
compatible = "xlnx,zynqmp-dwc3";
reg = <0x0 0xff9d 0x0 0x100>;
clock-names = "bus_clk", "ref_clk";
power-domains = <&zynqmp_firmware PD_USB_0>;
ranges;
resets = <&zynqmp_reset ZYNQMP_RESET_USB0_CORERESET>,
<&zynqmp_reset ZYNQMP_RESET_USB0_HIBERRESET>,
<&zynqmp_reset ZYNQMP_RESET_USB0_APB>;
reset-names = "usb_crst", "usb_hibrst", "usb_apbrst";
phy-names = "usb3-phy";
phys = <&psgtr 2 PHY_TYPE_USB3 0 2>;

usb0_dwc3: dwc3@fe20 {
compatible = "snps,dwc3";
interrupt-parent = <&gic>;
interrupts = <0 65 4>;
clock-names = "ref", "bus_early", "suspend";
reg = <0x0 0xfe20 0x0 0x4>;
};
};

platform.dts

&usb0 {
status = "okay";
phy-names = "usb3-phy";
phys = <&psgtr 2 PHY_TYPE_USB3 0 2>;
};

&usb0_dwc3 {
dr_mode = "peripheral";

/* The following quirks are required, since the bInterval is 1 and we
 * handle steady ISOC streaming. See Usecase 3 in commit 729dcffd1ed3
 * ("usb: dwc3: gadget: Add support for disabling U1 and U2 entries").
 */
snps,dis-u1-entry-quirk;
snps,dis-u2-entry-quirk;
};



Meanwhile I will keep updating on the same.


Thanks, that sounds great!

Regards,
Michael


>>Signed-off-by: Manish Narani 
>>---
>>

Re: [PATCH] arm64: kprobes: Fix Uexpected kernel BRK exception at EL1

[Masami Hiramatsu]

On Fri, 22 Jan 2021 11:09:09 +
Qais Yousef  wrote:

> I was hitting the below panic continuously when attaching kprobes to
> scheduler functions
> 
>   [  159.045212] Unexpected kernel BRK exception at EL1
>   [  159.053753] Internal error: BRK handler: f206 [#1] PREEMPT SMP
>   [  159.059954] Modules linked in:
>   [  159.063025] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 
> 5.11.0-rc4-8-g1e2a199f6ccd #56
>   [rt-app]  [1] Exiting.[  159.071166] Hardware name: ARM Juno 
> development board (r2) (DT)
>   [  159.079689] pstate: 63c5 (nZCv DAIF -PAN -UAO -TCO BTYPE=--)
> 
>   [  159.085723] pc : 0x80001624501c
>   [  159.089377] lr : attach_entity_load_avg+0x2ac/0x350
>   [  159.094271] sp : 80001622b640
>   [rt-app]  [0] Exiting.[  159.097591] x29: 80001622b640 x28: 
> 0001
>   [  159.105515] x27: 0049 x26: 000800b79980
> 
>   [  159.110847] x25: 00097ef37840 x24: 
>   [  159.116331] x23: 0024eacec1ec x22: 00097ef12b90
>   [  159.121663] x21: 00097ef37700 x20: 800010119170
>   [rt-app]  [11] Exiting.[  159.126995] x19: 00097ef37840 
> x18: 000e
>   [  159.135003] x17: 0001 x16: 0019
>   [  159.140335] x15:  x14: 
>   [  159.145666] x13: 0002 x12: 0002
>   [  159.150996] x11: 80001592f9f0 x10: 0060
>   [  159.156327] x9 : 8000100f6f9c x8 : be618290de0999a1
>   [  159.161659] x7 : 80096a4b1000 x6 : 
>   [  159.166990] x5 : 00097ef37840 x4 : 
>   [  159.172321] x3 : 000800328948 x2 : 
>   [  159.177652] x1 : 002507d52fec x0 : 00097ef12b90
>   [  159.182983] Call trace:
>   [  159.185433]  0x80001624501c
>   [  159.188581]  update_load_avg+0x2d0/0x778
>   [  159.192516]  enqueue_task_fair+0x134/0xe20
>   [  159.196625]  enqueue_task+0x4c/0x2c8
>   [  159.200211]  ttwu_do_activate+0x70/0x138
>   [  159.204147]  sched_ttwu_pending+0xbc/0x160
>   [  159.208253]  flush_smp_call_function_queue+0x16c/0x320
>   [  159.213408]  generic_smp_call_function_single_interrupt+0x1c/0x28
>   [  159.219521]  ipi_handler+0x1e8/0x3c8
>   [  159.223106]  handle_percpu_devid_irq+0xd8/0x460
>   [  159.227650]  generic_handle_irq+0x38/0x50
>   [  159.231672]  __handle_domain_irq+0x6c/0xc8
>   [  159.235781]  gic_handle_irq+0xcc/0xf0
>   [  159.239452]  el1_irq+0xb4/0x180
>   [  159.242600]  rcu_is_watching+0x28/0x70
>   [  159.246359]  rcu_read_lock_held_common+0x44/0x88
>   [  159.250991]  rcu_read_lock_any_held+0x30/0xc0
>   [  159.255360]  kretprobe_dispatcher+0xc4/0xf0
>   [  159.259555]  __kretprobe_trampoline_handler+0xc0/0x150
>   [  159.264710]  trampoline_probe_handler+0x38/0x58
>   [  159.269255]  kretprobe_trampoline+0x70/0xc4
>   [  159.273450]  run_rebalance_domains+0x54/0x80
>   [  159.277734]  __do_softirq+0x164/0x684
>   [  159.281406]  irq_exit+0x198/0x1b8
>   [  159.284731]  __handle_domain_irq+0x70/0xc8
>   [  159.288840]  gic_handle_irq+0xb0/0xf0
>   [  159.292510]  el1_irq+0xb4/0x180
>   [  159.295658]  arch_cpu_idle+0x18/0x28
>   [  159.299245]  default_idle_call+0x9c/0x3e8
>   [  159.303265]  do_idle+0x25c/0x2a8
>   [  159.306502]  cpu_startup_entry+0x2c/0x78
>   [  159.310436]  secondary_start_kernel+0x160/0x198
>   [  159.314984] Code: d42000c0 aa1e03e9 d42000c0 aa1e03e9 (d42000c0)
> 
> After a bit of head scratching and debugging it turned out that it is
> due to kprobe handler being interrupted by a tick that causes us to go
> into (I think another) kprobe handler.
> 
> The culprit was kprobe_breakpoint_ss_handler() returning DBG_HOOK_ERROR
> which leads to the Unexpected kernel BRK exception.
> 
> Reverting commit ba090f9cafd5 ("arm64: kprobes: Remove redundant
> kprobe_step_ctx") seemed to fix the problem for me.
> 
> Further analysis showed that kcb->kprobe_status is set to
> KPROBE_REENTER when the error occurs. By teaching
> kprobe_breakpoint_ss_handler() to handle this status I can no  longer
> reproduce the problem.

Very good catch! Yes, this missed the reentered kprobe case.

Acked-by: Masami Hiramatsu 

> 
> Fixes: ba090f9cafd5 ("arm64: kprobes: Remove redundant kprobe_step_ctx")
> Signed-off-by: Qais Yousef 
> ---
> 
> Another change in behavior I noticed is that before ba090f9cafd5 ("arm64:
> kprobes: Remove redundant kprobe_step_ctx") if 'cur' was NULL we wouldn't
> return DBG_HOOK_ERROR, but after the change we do.

It should not happen, since the KPROBES_BRK_SS_IMM must be used only for
kprobes's second break which must happen on the trampoline instruction
buffer, which must set current kprobes before execution.

Thank you,

> 
> I didn't hit a problem because of that it's just something I n

Re: [PATCH v5 3/6] kasan: Add report for async mode

[Vincenzo Frascino]

On 1/22/21 1:27 PM, Vincenzo Frascino wrote:
>> It looks like the original kasan_report() prototype is declared in two
>> places (second one in mm/kasan/kasan.h). I'd remove the latter and try
>> to have a consistent approach for kasan_report() and
>> kasan_report_async().
>>
> Ok, I will remove it.

I just realized that the internal interface exposes the kasan_report() interface
for the GENERIC KASAN implementation. If I remove it that does not work anymore:

/data1/Projects/LinuxKernel/linux-mte/mm/kasan/common.c: In function
‘__kasan_check_byte’:
/data1/Projects/LinuxKernel/linux-mte/mm/kasan/common.c:503:17: error: implicit
declaration of function ‘kasan_report’ [-Werror=implicit-function-declaration]
  503 | kasan_report((unsigned long)address, 1, false, ip);
  | ^~~~
/data1/Projects/LinuxKernel/linux-mte/mm/kasan/generic.c: In function
‘check_region_inline’:
/data1/Projects/LinuxKernel/linux-mte/mm/kasan/generic.c:170:25: error: implicit
declaration of function ‘kasan_report’ [-Werror=implicit-function-declaration]
  170 | return !kasan_report(addr, size, write, ret_ip);
  | ^~~~
/data1/Projects/LinuxKernel/linux-mte/mm/kasan/report_generic.c: In function
‘__asan_report_load1_noabort’:
/data1/Projects/LinuxKernel/linux-mte/mm/kasan/report_generic.c:295:9: error:
implicit declaration of function ‘kasan_report’
[-Werror=implicit-function-declaration]
  295 | kasan_report(addr, size, false, _RET_IP_);\
  | ^~~~
/data1/Projects/LinuxKernel/linux-mte/mm/kasan/report_generic.c:306:1: note: in
expansion of macro ‘DEFINE_ASAN_REPORT_LOAD’
  306 | DEFINE_ASAN_REPORT_LOAD(1);

To do that cleanly few things need to be shuffled around, Andrey or I can take
care of it but if you agree we shall look into this after -rc1.

Thanks!

-- 
Regards,
Vincenzo

Re: [PATCH v3 2/4] drm/qxl: unpin release objects

[Gerd Hoffmann]

On Fri, Jan 22, 2021 at 09:13:42AM +0100, Thomas Zimmermann wrote:
> Hi
> 
> Am 20.01.21 um 12:12 schrieb Gerd Hoffmann:
> > Balances the qxl_create_bo(..., pinned=true, ...);
> > call in qxl_release_bo_alloc().
> > 
> > Signed-off-by: Gerd Hoffmann 
> > ---
> >   drivers/gpu/drm/qxl/qxl_release.c | 1 +
> >   1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
> > b/drivers/gpu/drm/qxl/qxl_release.c
> > index 0fcfc952d5e9..add979cba11b 100644
> > --- a/drivers/gpu/drm/qxl/qxl_release.c
> > +++ b/drivers/gpu/drm/qxl/qxl_release.c
> > @@ -166,6 +166,7 @@ qxl_release_free_list(struct qxl_release *release)
> > entry = container_of(release->bos.next,
> >  struct qxl_bo_list, tv.head);
> > bo = to_qxl_bo(entry->tv.bo);
> > +   bo->tbo.pin_count = 0; /* ttm_bo_unpin(&bo->tbo); */
> 
> This code looks like a workaround or a bug.
> 
> AFAICT the only place with pre-pinned BO is qdev->dumb_shadow_bo. Can you
> remove the pinned flag entirely and handle pinning as part of
> dumb_shadow_bo's code.

No, the release objects are pinned too, and they must be
pinned (qxl commands are in there, and references are
placed in the qxl rings, so allowing them to roam is
a non-starter).

> if (pin_count)
> ttm_bo_unpin();
> WARN_ON(pin_count); /* should always be 0 now */

Well, the pin_count is 1 at this point.
No need for the if().

Just calling ttm_bo_unpin() here makes lockdep unhappy.

Not calling ttm_bo_unpin() makes ttm_bo_release() throw
a WARN() because of the pin.

Clearing pin_count (which is how ttm fixes things up
in the error path) works.

I'm open to better ideas.

take care,
  Gerd

Re: [PATCH v2 08/12] ASoC: arizona-jack: convert into a helper library for codec drivers

[Hans de Goede]

Hi,

On 1/22/21 2:04 PM, Charles Keepax wrote:
> On Fri, Jan 22, 2021 at 01:23:44PM +0100, Hans de Goede wrote:
>> On 1/22/21 12:26 PM, Charles Keepax wrote:
>>> On Thu, Jan 21, 2021 at 05:55:00PM +0100, Hans de Goede wrote:
 On 1/19/21 10:51 AM, Richard Fitzgerald wrote:
> On 18/01/2021 17:24, Andy Shevchenko wrote:
>> On Sun, Jan 17, 2021 at 6:06 PM Hans de Goede  
>> wrote:
 Note there is a pretty big issue with the original code here, if
 the MICVDD DAPM pin is on for an internal-mic and then we run through the
 jack-detect mic-detect sequence, we end up setting
 bypass=true causing the micbias for the internal-mic to no longer
 be what was configured. IOW poking the bypass setting underneath the
 DAPM code is racy.

>>>
>>> The regulator bypass code keeps an internal reference count. All
>>> the users of the regulator need to allow bypass for it to be
>>> placed into bypass mode, so I believe this can't happen.
>>
>> Ah I did not know that, since the regulator_allow_bypass function
>> takes a bool rather then having enable/disable variants I thought
>> it would directly set the bypass, but you are right. So this is not
>> a problem, good.
>>
>> So this has made me look at the problem again and I believe that
>> a much better solution is to simply re-use the MICVDD regulator-reference
>> which has been regulator_get-ed by the dapm code when instantiating the:
>>
>> SND_SOC_DAPM_REGULATOR_SUPPLY("MICVDD", 0, SND_SOC_DAPM_REGULATOR_BYPASS),
>>
>> widget. So I plan to have a new patch in v3 of the series which replaces
>> the devm_regulator_get with something like this:
>>
>>  /*
>>   * There is a DAPM widget for the MICVDD regulator, since
>>   * the button-press detection has special requirements wrt
>>   * the regulator bypass settings we cannot directly
>>   * use snd_soc_component_force_enable_pin("MICVDD") /
>>   * snd_soc_component_disable_pin("MICVDD").
>>   *
>>   * Instead we lookup the widget's regulator reference here
>>   * and use that to directly control the regulator.
>>   * Both the regulator's enable and bypass settings are
>>   * ref-counted so this will not interfere with the DAPM use
>>   * of the regulator.
>>   */
>>  for_each_card_widgets(dapm->card, w) {
>>  if (!strcmp(w->name, "MICVDD"))
>>  info->micvdd_regulator = w->regulator;
>>  break;
>>  }
>>  }
>>
>> (note I've not tested this yet, but I expect this to work fine).
>>
> 



> Alas this won't work either. When I say reference count that
> isn't quite a totally accurate reflection of the usage of the
> function. When you call allow_bypass you are saying as this
> consumer of the regulator I don't mind if it goes into bypass.
> Then if all consumers agree the regulator will be put into
> bypass. So it is comparing the reference count to the number of
> consumers the regulator has to make a decision.
> 
> If you call allow_bypass independently from the jack detection
> code and the ASoC framework on the same consumer, as you
> describe here you will get bad effects.  For example the
> regulator has two consumers, our CODEC driver and some other
> device. If our codec driver calls allow_bypass twice, then
> the regulator would go into bypass without the other consumer
> having approved it would could be fatal to that device.

So I just double checked the regulator core code and you
are right that the bypass thing is per consumer. So we
will indeed need 2 calls to regulator_get, one for the
dapm use and one for the jack-det use since those 2
are independent.

Note your example does not work as you think it will though:

int regulator_allow_bypass(struct regulator *regulator, bool enable)
{
...

if (enable && !regulator->bypass) {
rdev->bypass_count++;
...

} else if (!enable && regulator->bypass) {
rdev->bypass_count--;
...
}

if (ret == 0)
regulator->bypass = enable;
}

So a second call to allow_bypass(..., true) from the same
consumer will be a no-op.

Sharing the same struct regulator result between the dapm widget
and the jack-det code would still be an issue though since it
will introduce the race which I was worried about earlier.

>> 1. Keep the code as is, live with the debugfs error. This might be
>> best for now, as I don't want to grow the scope of this series too much.
>> I will go with this for the next version of this series (unless
>> I receive feedback otherwise before I get around to posting the next
>> version).
>
> I wonder if this commit was related to that:
> 
> commit ff268b56ce8c ("regulator: core: Don't spew backtraces on duplicate 
> sysfs")
> 
> Apologies I don't have as much time as I normally would to look
> into such issues at the moment, due to various internal company
> things going on.

Actually you are being supe

Re: [RFC PATCH v3 1/1] iio/scmi: Adding support for IIO SCMI Based Sensors

[Cristian Marussi]

Hi Jyoti,

a few remarks below.

On Thu, Jan 21, 2021 at 11:21:47PM +, Jyoti Bhayana wrote:
> This change provides ARM SCMI Protocol based IIO device.
> This driver provides support for Accelerometer and Gyroscope using
> new SCMI Sensor Protocol defined by the upcoming SCMIv3.0

I'd say:

new SCMI Sensor Protocol extension added by the upcoming SCMIv3.0

given that SCMI Sensor existed already in SCMIv2.0

> ARM specification
> 
> Signed-off-by: Jyoti Bhayana 
> ---
>  MAINTAINERS|   6 +
>  drivers/iio/common/Kconfig |   1 +
>  drivers/iio/common/Makefile|   1 +
>  drivers/iio/common/scmi_sensors/Kconfig|  18 +
>  drivers/iio/common/scmi_sensors/Makefile   |   5 +
>  drivers/iio/common/scmi_sensors/scmi_iio.c | 736 +
>  6 files changed, 767 insertions(+)
>  create mode 100644 drivers/iio/common/scmi_sensors/Kconfig
>  create mode 100644 drivers/iio/common/scmi_sensors/Makefile
>  create mode 100644 drivers/iio/common/scmi_sensors/scmi_iio.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index b516bb34a8d5..ccf37d43ab41 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8567,6 +8567,12 @@ S: Maintained
>  F:   Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt
>  F:   drivers/iio/multiplexer/iio-mux.c
>  
> +IIO SCMI BASED DRIVER
> +M:   Jyoti Bhayana 
> +L:   linux-...@vger.kernel.org
> +S:   Maintained
> +F:   drivers/iio/common/scmi_sensors/scmi_iio.c
> +
>  IIO SUBSYSTEM AND DRIVERS
>  M:   Jonathan Cameron 
>  R:   Lars-Peter Clausen 
> diff --git a/drivers/iio/common/Kconfig b/drivers/iio/common/Kconfig
> index 2b9ee9161abd..0334b4954773 100644
> --- a/drivers/iio/common/Kconfig
> +++ b/drivers/iio/common/Kconfig
> @@ -6,5 +6,6 @@
>  source "drivers/iio/common/cros_ec_sensors/Kconfig"
>  source "drivers/iio/common/hid-sensors/Kconfig"
>  source "drivers/iio/common/ms_sensors/Kconfig"
> +source "drivers/iio/common/scmi_sensors/Kconfig"
>  source "drivers/iio/common/ssp_sensors/Kconfig"
>  source "drivers/iio/common/st_sensors/Kconfig"
> diff --git a/drivers/iio/common/Makefile b/drivers/iio/common/Makefile
> index 4bc30bb548e2..fad40e1e1718 100644
> --- a/drivers/iio/common/Makefile
> +++ b/drivers/iio/common/Makefile
> @@ -11,5 +11,6 @@
>  obj-y += cros_ec_sensors/
>  obj-y += hid-sensors/
>  obj-y += ms_sensors/
> +obj-y += scmi_sensors/
>  obj-y += ssp_sensors/
>  obj-y += st_sensors/
> diff --git a/drivers/iio/common/scmi_sensors/Kconfig 
> b/drivers/iio/common/scmi_sensors/Kconfig
> new file mode 100644
> index ..67e084cbb1ab
> --- /dev/null
> +++ b/drivers/iio/common/scmi_sensors/Kconfig
> @@ -0,0 +1,18 @@
> +#
> +# IIO over SCMI
> +#
> +# When adding new entries keep the list in alphabetical order
> +
> +menu "IIO SCMI Sensors"
> +
> +config IIO_SCMI
> + tristate "IIO SCMI"
> +depends on ARM_SCMI_PROTOCOL
> +select IIO_BUFFER
> +select IIO_KFIFO_BUF
> + help
> +  Say yes here to build support for IIO SCMI Driver.
> +  This provides ARM SCMI Protocol based IIO device.
> +  This driver provides support for accelerometer and gyroscope
> +  sensors available on SCMI based platforms.
> +endmenu
> diff --git a/drivers/iio/common/scmi_sensors/Makefile 
> b/drivers/iio/common/scmi_sensors/Makefile
> new file mode 100644
> index ..f13140a2575a
> --- /dev/null
> +++ b/drivers/iio/common/scmi_sensors/Makefile
> @@ -0,0 +1,5 @@
> +# SPDX - License - Identifier : GPL - 2.0 - only
> +#
> +# Makefile for the IIO over SCMI
> +#
> +obj-$(CONFIG_IIO_SCMI) += scmi_iio.o
> diff --git a/drivers/iio/common/scmi_sensors/scmi_iio.c 
> b/drivers/iio/common/scmi_sensors/scmi_iio.c
> new file mode 100644
> index ..3b76cc54511c
> --- /dev/null
> +++ b/drivers/iio/common/scmi_sensors/scmi_iio.c
> @@ -0,0 +1,736 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * System Control and Management Interface(SCMI) based IIO sensor driver
> + *
> + * Copyright (C) 2020 Google LLC
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ilog10(x) (ilog2(x) / const_ilog2(10))
> +#define UHZ_PER_HZ 100UL
> +#define ODR_EXPAND(odr, uodr) (((odr) * 100ULL) + (uodr))
> +#define MAX_NUM_OF_CHANNELS 4
> +#define H32(x) (((x) & 0xLL) >> 32)
> +#define L32(x) ((x) & 0xLL)

Probaly you want to use GENMASK here to define the masks, and not sure
but maybe there are already similar macros in linux to extract
upper/lower 32 bits.

> +
> +struct scmi_iio_priv {
> + struct scmi_handle *handle;
> + const struct scmi_sensor_info *sensor_info;
> + struct iio_dev *indio_dev;
> + long long iio_buf[MAX_NUM_OF_CHANNELS];
> + struct notifier_block sensor_update_nb;
> + u32 *freq_avail;
> + /*
> +  * range_avail = [minRange resolution maxRange]
> +  *

Re: [PATCH 4/6] regulator: Initial commit of sy7636a

[Mark Brown]

On Thu, Jan 21, 2021 at 10:24:10PM -0800, Alistair Francis wrote:
> On Mon, Jan 18, 2021 at 4:32 AM Mark Brown  wrote:
> > On Sat, Jan 16, 2021 at 08:25:37PM -0800, Alistair Francis wrote:

> > > +static int get_vcom_voltage_op(struct regulator_dev *rdev)
> > > +{
> > > + int ret = get_vcom_voltage_mv(rdev->regmap);
> > > +

> > Why is this get_vcom_voltage_mv() function not in the regulator driver,
> > and why is it not just inline here?  It also needs namespacing.

> I'm not sure what you mean, can you please explain?

This is a wrapper for a function that has exactly one caller but is not
only a separate function but also in the MFD header, part of a separate
driver.  This seems at best pointless.

> > Why do you need this delay here, and what purpose is this lock intended

> The delay is to allow a power ramp up, I have added a comment.

Use the standard ramp_delay, don't open code it.

> > > +static int sy7636a_regulator_suspend(struct device *dev)
> > > +{
> > > + int ret;
> > > + struct sy7636a *sy7636a = dev_get_drvdata(dev->parent);
> > > +
> > > + ret = get_vcom_voltage_mv(sy7636a->regmap);
> > > +
> > > + if (ret > 0)
> > > + sy7636a->vcom = (unsigned int)ret;
> > > +
> > > + return 0;
> > > +}

> > What's going on here, and if you are going to store this value over
> > suspend why not store it in a variable of the correct type?  In general

> It is part of the vendor's kernel, they specifically added it to
> ensure vcom is set on resume.

"I copied this from the vendor" isn't really a great explanation...  If
the device is likely to get completely powered off and loosing settings
then presumably the entire register map, not just this one value, needs
to be saved and restored instead of just this one value.  If that is the
case it's probably best to use a register cache and just resync it on
resume.


signature.asc
Description: PGP signature

Re: [PATCH] ASoC: qcom: Fix number of HDMI RDMA channels on sc7180

[Mark Brown]

On Fri, Jan 22, 2021 at 04:56:21PM +0530, Srinivasa Rao Mandadapu wrote:
> Hi Mark and Boyd,

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

> Thanks for your time on this issue.
> 
> In my opinion, It 's better not to apply this patch.
> 
> I will post patch with changing size in sc7180.dtsi file.

We can always do both...  If you think the patch should be reverted then
please submit a patch doing that (including a changelog which will
explain why), but note that the DT is in theory an ABI and it's possible
that people won't upgrade their DTs if the fix is in there.


signature.asc
Description: PGP signature

Re: [PATCH v3] regulator: Make regulator_sync_voltage() usable by coupled regulators

[Mark Brown]

On Fri, Jan 22, 2021 at 01:16:49AM +0300, Dmitry Osipenko wrote:

> + /* balance only if there are regulators coupled */
> + if (rdev->coupling_desc.n_coupled > 1) {
> + ret = regulator_balance_voltage(rdev, PM_SUSPEND_ON);
> + goto out;
> + }
> +
>   ret = _regulator_do_set_voltage(rdev, min_uV, max_uV);
>  
>  out:

This would be clearer written as an if/else rather than using the goto.


signature.asc
Description: PGP signature

Re: [PATCH v2 0/5] Optimize iommu_map_sg() performance

[Robin Murphy]

On 2021-01-21 21:30, isa...@codeaurora.org wrote:

On 2021-01-12 08:00, Robin Murphy wrote:

On 2021-01-11 14:54, Isaac J. Manjarres wrote:

The iommu_map_sg() code currently iterates through the given
scatter-gather list, and in the worst case, invokes iommu_map()
for each element in the scatter-gather list, which calls into
the IOMMU driver through an indirect call. For an IOMMU driver
that uses a format supported by the io-pgtable code, the IOMMU
driver will then call into the io-pgtable code to map the chunk.

Jumping between the IOMMU core code, the IOMMU driver, and the
io-pgtable code and back for each element in a scatter-gather list
is not efficient.

Instead, add a map_sg() hook in both the IOMMU driver ops and the
io-pgtable ops. iommu_map_sg() can then call into the IOMMU driver's
map_sg() hook with the entire scatter-gather list, which can call
into the io-pgtable map_sg() hook, which can process the entire
scatter-gather list, signficantly reducing the number of indirect
calls, and jumps between these layers, boosting performance.


Out of curiosity, how much of the difference is attributable to actual
indirect call overhead vs. the additional massive reduction in visits
to arm_smmu_rpm_{get,put} that you fail to mention?There are ways to

I did an experiment where I compared the two approaches without any calls
to arm_smmu_rpm_[get/put]. There's still a large amount of difference
without the overhead incurred by power management calls. Here are the 
results:


no optimizations and no power management calls:
  size    iommu_map_sg
   4K    0.609 us
  64K    8.583 us
   1M  136.083 us
   2M  273.145 us
  12M 1442.119 us
  24M 2876.078 us
  32M 3832.041 us

iommu_map_sg optimizations and no power management calls:
size    iommu_map_sg
   4K    0.645 us
  64K    1.229 us
   1M    9.531 us
   2M   23.198 us
  12M   99.250 us
  24M  185.713 us
  32M  248.781 us

 From here, we can see that the amount of latency incurred by the indirect
calls is fairly large.


OK, that's pretty much in line with what I was imagining, just wanted to 
confirm (if you ended up actually changing the power state around each 
page then the caller would likely be doing something very stupid).


I'm guessing the optimised numbers above looking ~20% slower than the 
ones below is just indicative of a high variance between runs, or maybe 
there's some funky cache interaction that really does make the RPM 
checks have effectively negative overhead.



optimise indirect calling that would benefit *all* cases, rather than
just one operation for one particular driver.

Do you mind sharing some more information on how to optimize the existing
approach further, such that it benefits other drivers as well?


This article touches on some of the possible techniques:

https://lwn.net/Articles/774743/


On a system that uses the ARM SMMU driver, and the ARM LPAE format,
the current implementation of iommu_map_sg() yields the following
latencies for mapping scatter-gather lists of various sizes. These
latencies are calculated by repeating the mapping operation 10 times:

 size    iommu_map_sg latency
   4K    0.624 us
  64K    9.468 us
   1M  122.557 us
   2M  239.807 us
  12M 1435.979 us
  24M 2884.968 us
  32M 3832.979 us

On the same system, the proposed modifications yield the following
results:

 size    iommu_map_sg latency
   4K    3.645 us
  64K    4.198 us
   1M   11.010 us
   2M   17.125 us
  12M   82.416 us
  24M  158.677 us
  32M  210.468 us

The procedure for collecting the iommu_map_sg latencies is
the same in both experiments. Clearly, reducing the jumps
between the different layers in the IOMMU code offers a
signficant performance boost in iommu_map_sg() latency.


Presumably those are deliberately worst-case numbers? After all, a
32MB scatterlist *could* incur less overhead than a 64KB one if things
line up just right (still 16 ->map calls, but each with one fewer

Yes, these are worst case numbers (i.e. a buffer is composed entirely
of 4 KB pages, so higher order mappings don't get used).

level of pagetable to traverse). TBH I find the significant regression
of the 4KB case the most interesting - what's going on there?

That was an error on my part. After fixing my error, I observed that the
time spent mapping the 4 KB buffer is comparable with and without 
optimizations,

which is expected.


My main reservation here is that we get an explosion of duplicate
copies of almost the same code, and it's code that's just non-trivial
enough to start being bug-prone. And it's all still only for one
specific operation - your argument about calling through multiple
layers 

Re: [PATCH v1] misc: pti: Remove driver for deprecated platform

[Alexander Shishkin]

Andy Shevchenko  writes:

> Intel Moorestown and Medfield are quite old Intel Atom based
> 32-bit platforms, which were in limited use in some Android phones,
> tablets and consumer electronics more than eight years ago.
>
> There are no bugs or problems ever reported outside from Intel
> for breaking any of that platforms for years. It seems no real
> users exists who run more or less fresh kernel on it. The commit
> 05f4434bc130 ("ASoC: Intel: remove mfld_machine") also in align
> with this theory.
>
> Due to above and to reduce a burden of supporting outdated drivers
> we remove the support of outdated platforms completely.
>
> Cc: Alexander Shishkin 
> Signed-off-by: Andy Shevchenko 
> Acked-by: Linus Walleij 

FWIW,

Acked-by: Alexander Shishkin 

Regards,
--
Alex

Re: [PATCH 1/2] dt-bindings: arm-smmu-qcom: Add Qualcomm SC8180X compatible

[Will Deacon]

On Wed, 20 Jan 2021 17:40:04 -0800, Bjorn Andersson wrote:
> Add compatible for the ARM SMMU found in the Qualcomm SC8180x platform.

Applied to will (for-joerg/arm-smmu/updates), thanks!

[1/2] dt-bindings: arm-smmu-qcom: Add Qualcomm SC8180X compatible
  https://git.kernel.org/will/c/9cde12ba07ce
[2/2] iommu/arm-smmu-qcom: Add Qualcomm SC8180X impl
  https://git.kernel.org/will/c/1a7180ff81aa

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev

Re: [PATCH 1/1] iommu/arm-smmu-v3: Use DEFINE_RES_MEM() to simplify code

[Will Deacon]

On Fri, 22 Jan 2021 21:14:48 +0800, Zhen Lei wrote:
> No functional change.

Applied to will (for-joerg/arm-smmu/updates), thanks!

[1/1] iommu/arm-smmu-v3: Use DEFINE_RES_MEM() to simplify code
  https://git.kernel.org/will/c/932bc8c7d742

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev

Re: [PATCHv2] lockdep: report broken irq restoration

[Mark Rutland]

On Fri, Jan 22, 2021 at 02:24:43PM +0100, Peter Zijlstra wrote:
> On Fri, Jan 22, 2021 at 11:06:25AM +, Mark Rutland wrote:
> > Hi all,
> > 
> > Any thoughts on this? I'd like to get this in soon if we could as it'll
> > help to flush out any remaining issues that are liable to get in the way
> > of planned rework for arm64 and x86.
> 
> Ah, I actually have it queued, I'll try and push it out to locking/core
> later today.

Thanks! I hadn't thought to check your queue; sorry for the noise.

Now I can forget all about this. ;)

Mark.

Re: [PATCH 2/2] dt-bindings: arm-smmu: Add binding for Qcom SDX55 SMMU

[Manivannan Sadhasivam]

On Fri, Jan 22, 2021 at 01:14:49PM +, Will Deacon wrote:
> On Tue, Jan 12, 2021 at 09:22:23PM -0600, Rob Herring wrote:
> > On Thu, 07 Jan 2021 20:01:18 +0530, Manivannan Sadhasivam wrote:
> > > Add devicetree binding for Qualcomm SDX55 SMMU.
> > > 
> > > Cc: Will Deacon 
> > > Cc: Robin Murphy 
> > > Cc: Joerg Roedel 
> > > Cc: io...@lists.linux-foundation.org
> > > Signed-off-by: Manivannan Sadhasivam 
> > > Reviewed-by: Vinod Koul 
> > > ---
> > >  Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > 
> > Acked-by: Rob Herring 
> 
> Is there another patch adding driver support for matching this new binding?
> 

Nope. But the compatible is used as a fallback with "arm,mmu-500". The
dts patch is merged into qcom tree:

https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux.git/commit/?h=dts-for-5.12&id=a2bdfdfba2afb532f2a2c8082bdb7de8379a4b6c

Thanks,
Mani

> Will

Re: [PATCH 1/2] dt-bindings: arm-smmu: Add sm8350 compatible string

[Will Deacon]

On Fri, 15 Jan 2021 14:33:21 +0530, Vinod Koul wrote:
> Add compatible string for sm8350 iommu to documentation.

Applied to will (for-joerg/arm-smmu/updates), thanks!

[1/2] dt-bindings: arm-smmu: Add sm8350 compatible string
  https://git.kernel.org/will/c/70b5b6a6daea
[2/2] iommu: arm-smmu-impl: Add SM8350 qcom iommu implementation
  https://git.kernel.org/will/c/d8498b1e4ecc

Cheers,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev

Re: [PATCH] pinctrl: actions: Add the platform dependency to drivers

[Manivannan Sadhasivam]

On Fri, Jan 22, 2021 at 02:19:07PM +0100, Linus Walleij wrote:
> On Thu, Jan 21, 2021 at 7:26 AM Manivannan Sadhasivam
>  wrote:
> 
> > The Actions Semi pinctrl drivers are a mix of both ARM32 and ARM64
> > platforms. So let's add the correct platform dependency to avoid them
> > being selected on the other.
> >
> > Signed-off-by: Manivannan Sadhasivam 
> 
> Are you not opting out of build tests when you do this?
> 
> What about:
> 
> depends on ARM64 || COMPILE_TEST
> (etc)
> ?
> 

Oh yeah, I missed it. Will send v2.

Thanks,
Mani

> Yours,
> Linus Walleij
> 
> Yours,
> Linus Walleij

[GIT PULL] perf tools fixes for v5.11, 2nd batch

[Arnaldo Carvalho de Melo]

Hi Linus,

Please consider pulling,

Best regards,

- Arnaldo

The following changes since commit 9f29bd8b2e7132b409178d1367dae1813017bd0e:

  Merge tag 'fs_for_v5.11-rc5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs (2021-01-21 
11:45:40 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
tags/perf-tools-fixes-v5.11-2-2021-01-22

for you to fetch changes up to 8adc0a06d68a2e433b960377e515e7a6b19b429f:

  perf script: Fix overrun issue for dynamically-allocated PMU type number 
(2021-01-21 17:25:33 -0300)


perf tools fixes for 5.11, 2nd batch:

- Fix id index used in Intel PT for heterogeneous systems.

- Fix overrun issue in 'perf script' for dynamically-allocated PMU type number.

- Fix 'perf stat' metrics containing the 'duration_time' synthetic event.

- Fix system PMU 'perf stat' metrics.

Signed-off-by: Arnaldo Carvalho de Melo 

Test results in the signed tag at:

https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tag/?h=perf-tools-fixes-v5.11-2-2021-01-22

Adrian Hunter (1):
  perf evlist: Fix id index for heterogeneous systems

Jin Yao (1):
  perf script: Fix overrun issue for dynamically-allocated PMU type number

John Garry (2):
  perf metricgroup: Fix for metrics containing duration_time
  perf metricgroup: Fix system PMU metrics

 tools/lib/perf/evlist.c   | 17 -
 tools/perf/builtin-script.c   | 18 +-
 tools/perf/util/metricgroup.c | 16 +++-
 3 files changed, 32 insertions(+), 19 deletions(-)

[tip: objtool/urgent] objtool: Don't fail on missing symbol table

[tip-bot2 for Josh Poimboeuf]

The following commit has been merged into the objtool/urgent branch of tip:

Commit-ID: 1d489151e9f9d1647110277ff77282fe4d96d09b
Gitweb:
https://git.kernel.org/tip/1d489151e9f9d1647110277ff77282fe4d96d09b
Author:Josh Poimboeuf 
AuthorDate:Thu, 14 Jan 2021 16:14:01 -06:00
Committer: Josh Poimboeuf 
CommitterDate: Thu, 21 Jan 2021 15:49:58 -06:00

objtool: Don't fail on missing symbol table

Thanks to a recent binutils change which doesn't generate unused
symbols, it's now possible for thunk_64.o be completely empty without
CONFIG_PREEMPTION: no text, no data, no symbols.

We could edit the Makefile to only build that file when
CONFIG_PREEMPTION is enabled, but that will likely create confusion
if/when the thunks end up getting used by some other code again.

Just ignore it and move on.

Reported-by: Nathan Chancellor 
Reviewed-by: Nathan Chancellor 
Reviewed-by: Miroslav Benes 
Tested-by: Nathan Chancellor 
Link: https://github.com/ClangBuiltLinux/linux/issues/1254
Signed-off-by: Josh Poimboeuf 
---
 tools/objtool/elf.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
index f9682db..d8421e1 100644
--- a/tools/objtool/elf.c
+++ b/tools/objtool/elf.c
@@ -380,8 +380,11 @@ static int read_symbols(struct elf *elf)
 
symtab = find_section_by_name(elf, ".symtab");
if (!symtab) {
-   WARN("missing symbol table");
-   return -1;
+   /*
+* A missing symbol table is actually possible if it's an empty
+* .o file.  This can happen for thunk_64.o.
+*/
+   return 0;
}
 
symtab_shndx = find_section_by_name(elf, ".symtab_shndx");

[tip: objtool/urgent] objtool: Don't fail the kernel build on fatal errors

[tip-bot2 for Josh Poimboeuf]

The following commit has been merged into the objtool/urgent branch of tip:

Commit-ID: 655cf86548a3938538642a6df27dd359e13c86bd
Gitweb:
https://git.kernel.org/tip/655cf86548a3938538642a6df27dd359e13c86bd
Author:Josh Poimboeuf 
AuthorDate:Thu, 14 Jan 2021 16:32:42 -06:00
Committer: Josh Poimboeuf 
CommitterDate: Thu, 21 Jan 2021 15:49:39 -06:00

objtool: Don't fail the kernel build on fatal errors

This is basically a revert of commit 644592d32837 ("objtool: Fail the
kernel build on fatal errors").

That change turned out to be more trouble than it's worth.  Failing the
build is an extreme measure which sometimes gets too much attention and
blocks CI build testing.

These fatal-type warnings aren't yet as rare as we'd hope, due to the
ever-increasing matrix of supported toolchains/plugins and their
fast-changing nature as of late.

Also, there are more people (and bots) looking for objtool warnings than
ever before, so even non-fatal warnings aren't likely to be ignored for
long.

Suggested-by: Nick Desaulniers 
Reviewed-by: Miroslav Benes 
Reviewed-by: Nick Desaulniers 
Reviewed-by: Kamalesh Babulal 
Signed-off-by: Josh Poimboeuf 
---
 tools/objtool/check.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 5f8d3ee..4bd3031 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -2928,14 +2928,10 @@ int check(struct objtool_file *file)
warnings += ret;
 
 out:
-   if (ret < 0) {
-   /*
-*  Fatal error.  The binary is corrupt or otherwise broken in
-*  some way, or objtool itself is broken.  Fail the kernel
-*  build.
-*/
-   return ret;
-   }
-
+   /*
+*  For now, don't fail the kernel build on fatal warnings.  These
+*  errors are still fairly common due to the growing matrix of
+*  supported toolchains and their recent pace of change.
+*/
return 0;
 }

Re: [PATCH v3 2/4] drm/qxl: unpin release objects

[Daniel Vetter]

On Fri, Jan 22, 2021 at 2:35 PM Gerd Hoffmann  wrote:
>
> On Fri, Jan 22, 2021 at 09:13:42AM +0100, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 20.01.21 um 12:12 schrieb Gerd Hoffmann:
> > > Balances the qxl_create_bo(..., pinned=true, ...);
> > > call in qxl_release_bo_alloc().
> > >
> > > Signed-off-by: Gerd Hoffmann 
> > > ---
> > >   drivers/gpu/drm/qxl/qxl_release.c | 1 +
> > >   1 file changed, 1 insertion(+)
> > >
> > > diff --git a/drivers/gpu/drm/qxl/qxl_release.c 
> > > b/drivers/gpu/drm/qxl/qxl_release.c
> > > index 0fcfc952d5e9..add979cba11b 100644
> > > --- a/drivers/gpu/drm/qxl/qxl_release.c
> > > +++ b/drivers/gpu/drm/qxl/qxl_release.c
> > > @@ -166,6 +166,7 @@ qxl_release_free_list(struct qxl_release *release)
> > > entry = container_of(release->bos.next,
> > >  struct qxl_bo_list, tv.head);
> > > bo = to_qxl_bo(entry->tv.bo);
> > > +   bo->tbo.pin_count = 0; /* ttm_bo_unpin(&bo->tbo); */
> >
> > This code looks like a workaround or a bug.
> >
> > AFAICT the only place with pre-pinned BO is qdev->dumb_shadow_bo. Can you
> > remove the pinned flag entirely and handle pinning as part of
> > dumb_shadow_bo's code.
>
> No, the release objects are pinned too, and they must be
> pinned (qxl commands are in there, and references are
> placed in the qxl rings, so allowing them to roam is
> a non-starter).
>
> > if (pin_count)
> > ttm_bo_unpin();
> > WARN_ON(pin_count); /* should always be 0 now */
>
> Well, the pin_count is 1 at this point.
> No need for the if().
>
> Just calling ttm_bo_unpin() here makes lockdep unhappy.

How does that one splat? But yeah if that's a problem should be
explained in the comment. I'd then also only do a pin_count--; to make
sure you can still catch other pin leaks if you have them. Setting it
to 0 kinda defeats the warning.
-Daniel

>
> Not calling ttm_bo_unpin() makes ttm_bo_release() throw
> a WARN() because of the pin.
>
> Clearing pin_count (which is how ttm fixes things up
> in the error path) works.
>
> I'm open to better ideas.
>
> take care,
>   Gerd
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 07/12] ASoC: arizona-jack: Use arizona->dev for runtime-pm

[Hans de Goede]

Hi,

On 1/22/21 10:38 AM, Andy Shevchenko wrote:
> On Fri, Jan 22, 2021 at 2:03 AM Hans de Goede  wrote:
>> On 1/18/21 1:02 PM, Andy Shevchenko wrote:
>>> On Sun, Jan 17, 2021 at 6:06 PM Hans de Goede  wrote:
> 
> ...
> 
>>> Can you elaborate switchings from get() to get_sync() in few places
>>
>> Sorry, those 2 changes really should have been in a separate commit.
>> I've put the 2 get -> get_sync() changed in their own commit now
>> with the following commit-msg:
>>
>> """
>> extcon: arizona: Always use pm_runtime_get_sync() when we need the device to 
>> be awake
>>
>> Before this commit the extcon-arizona code was mixing pm_runtime_get()
>> and pm_runtime_get_sync() in different places. In all cases where
>> either function is called we make use of the device immediately
> 
> called and we

That changes the meaning of the sentence in ways which does not match
my intent. I've changed this to:

"""
In all cases where pm_runtime_get[_sync]() is called, the code
makes use of the device immediately after the call.
This means that we should always use pm_runtime_get_sync().
"""

Regards,

Hans

[PATCH v6 0/4] arm64: ARMv8.5-A: MTE: Add async mode support

[Vincenzo Frascino]

This patchset implements the asynchronous mode support for ARMv8.5-A
Memory Tagging Extension (MTE), which is a debugging feature that allows
to detect with the help of the architecture the C and C++ programmatic
memory errors like buffer overflow, use-after-free, use-after-return, etc.

MTE is built on top of the AArch64 v8.0 virtual address tagging TBI
(Top Byte Ignore) feature and allows a task to set a 4 bit tag on any
subset of its address space that is multiple of a 16 bytes granule. MTE
is based on a lock-key mechanism where the lock is the tag associated to
the physical memory and the key is the tag associated to the virtual
address.
When MTE is enabled and tags are set for ranges of address space of a task,
the PE will compare the tag related to the physical memory with the tag
related to the virtual address (tag check operation). Access to the memory
is granted only if the two tags match. In case of mismatch the PE will raise
an exception.

The exception can be handled synchronously or asynchronously. When the
asynchronous mode is enabled:
  - Upon fault the PE updates the TFSR_EL1 register.
  - The kernel detects the change during one of the following:
- Context switching
- Return to user/EL0
- Kernel entry from EL1
- Kernel exit to EL1
  - If the register has been updated by the PE the kernel clears it and
reports the error.

The series is based on linux-next/akpm.

To simplify the testing a tree with the new patches on top has been made
available at [1].

[1] https://git.gitlab.arm.com/linux-arm/linux-vf.git mte/v10.async.akpm

Changes:

v6:
  - Drop patches that forbid KASAN KUNIT tests when async
mode is enabled.
  - Fix a warning reported by kernel test robot.
  - Address review comments.
v5:
  - Rebase the series on linux-next/akpm.
  - Forbid execution for KASAN KUNIT tests when async
mode is enabled.
  - Dropped patch to inline mte_assign_mem_tag_range().
  - Address review comments.
v4:
  - Added support for kasan.mode (sync/async) kernel
command line parameter.
  - Addressed review comments.
v3:
  - Exposed kasan_hw_tags_mode to convert the internal
KASAN represenetation.
  - Added dsb() for kernel exit paths in arm64.
  - Addressed review comments.
v2:
  - Fixed a compilation issue reported by krobot.
  - General cleanup.

Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Dmitry Vyukov 
Cc: Andrey Ryabinin 
Cc: Alexander Potapenko 
Cc: Marco Elver 
Cc: Evgenii Stepanov 
Cc: Branislav Rankov 
Cc: Andrey Konovalov 
Signed-off-by: Vincenzo Frascino 

Vincenzo Frascino (4):
  arm64: mte: Add asynchronous mode support
  kasan: Add KASAN mode kernel parameter
  kasan: Add report for async mode
  arm64: mte: Enable async tag check fault

 Documentation/dev-tools/kasan.rst  |  9 +
 arch/arm64/include/asm/memory.h|  3 +-
 arch/arm64/include/asm/mte-kasan.h |  9 -
 arch/arm64/include/asm/mte.h   | 32 
 arch/arm64/kernel/entry-common.c   |  6 +++
 arch/arm64/kernel/mte.c| 60 +-
 include/linux/kasan.h  |  2 +
 lib/test_kasan.c   |  2 +-
 mm/kasan/hw_tags.c | 32 +++-
 mm/kasan/kasan.h   |  6 ++-
 mm/kasan/report.c  | 11 ++
 11 files changed, 163 insertions(+), 9 deletions(-)

-- 
2.30.0

[PATCH v6 3/4] kasan: Add report for async mode

[Vincenzo Frascino]

KASAN provides an asynchronous mode of execution.

Add reporting functionality for this mode.

Cc: Dmitry Vyukov 
Cc: Andrey Ryabinin 
Cc: Alexander Potapenko 
Cc: Andrey Konovalov 
Reviewed-by: Andrey Konovalov 
Signed-off-by: Vincenzo Frascino 
---
 include/linux/kasan.h |  2 ++
 mm/kasan/report.c | 11 +++
 2 files changed, 13 insertions(+)

diff --git a/include/linux/kasan.h b/include/linux/kasan.h
index bb862d1f0e15..b0a1d9dfa85c 100644
--- a/include/linux/kasan.h
+++ b/include/linux/kasan.h
@@ -351,6 +351,8 @@ static inline void *kasan_reset_tag(const void *addr)
 bool kasan_report(unsigned long addr, size_t size,
bool is_write, unsigned long ip);
 
+void kasan_report_async(void);
+
 #else /* CONFIG_KASAN_SW_TAGS || CONFIG_KASAN_HW_TAGS */
 
 static inline void *kasan_reset_tag(const void *addr)
diff --git a/mm/kasan/report.c b/mm/kasan/report.c
index 234f35a84f19..2fd6845a95e9 100644
--- a/mm/kasan/report.c
+++ b/mm/kasan/report.c
@@ -358,6 +358,17 @@ void kasan_report_invalid_free(void *object, unsigned long 
ip)
end_report(&flags);
 }
 
+void kasan_report_async(void)
+{
+   unsigned long flags;
+
+   start_report(&flags);
+   pr_err("BUG: KASAN: invalid-access\n");
+   pr_err("Asynchronous mode enabled: no access details available\n");
+   dump_stack();
+   end_report(&flags);
+}
+
 static void __kasan_report(unsigned long addr, size_t size, bool is_write,
unsigned long ip)
 {
-- 
2.30.0

[PATCH v6 1/4] arm64: mte: Add asynchronous mode support

[Vincenzo Frascino]

MTE provides an asynchronous mode for detecting tag exceptions. In
particular instead of triggering a fault the arm64 core updates a
register which is checked by the kernel after the asynchronous tag
check fault has occurred.

Add support for MTE asynchronous mode.

The exception handling mechanism will be added with a future patch.

Note: KASAN HW activates async mode via kasan.mode kernel parameter.
The default mode is set to synchronous.
The code that verifies the status of TFSR_EL1 will be added with a
future patch.

Cc: Catalin Marinas 
Cc: Will Deacon 
Reviewed-by: Catalin Marinas 
Reviewed-by: Andrey Konovalov 
Signed-off-by: Vincenzo Frascino 
---
 arch/arm64/include/asm/memory.h|  3 ++-
 arch/arm64/include/asm/mte-kasan.h |  9 +++--
 arch/arm64/kernel/mte.c| 16 ++--
 3 files changed, 23 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index cedfc9e97bcc..df96b9c10b81 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -231,7 +231,8 @@ static inline const void *__tag_set(const void *addr, u8 
tag)
 }
 
 #ifdef CONFIG_KASAN_HW_TAGS
-#define arch_enable_tagging()  mte_enable_kernel()
+#define arch_enable_tagging_sync() mte_enable_kernel_sync()
+#define arch_enable_tagging_async()mte_enable_kernel_async()
 #define arch_set_tagging_report_once(state)mte_set_report_once(state)
 #define arch_init_tags(max_tag)mte_init_tags(max_tag)
 #define arch_get_random_tag()  mte_get_random_tag()
diff --git a/arch/arm64/include/asm/mte-kasan.h 
b/arch/arm64/include/asm/mte-kasan.h
index 3748d5bb88c0..8ad981069afb 100644
--- a/arch/arm64/include/asm/mte-kasan.h
+++ b/arch/arm64/include/asm/mte-kasan.h
@@ -29,7 +29,8 @@ u8 mte_get_mem_tag(void *addr);
 u8 mte_get_random_tag(void);
 void *mte_set_mem_tag_range(void *addr, size_t size, u8 tag);
 
-void mte_enable_kernel(void);
+void mte_enable_kernel_sync(void);
+void mte_enable_kernel_async(void);
 void mte_init_tags(u64 max_tag);
 
 void mte_set_report_once(bool state);
@@ -55,7 +56,11 @@ static inline void *mte_set_mem_tag_range(void *addr, size_t 
size, u8 tag)
return addr;
 }
 
-static inline void mte_enable_kernel(void)
+static inline void mte_enable_kernel_sync(void)
+{
+}
+
+static inline void mte_enable_kernel_async(void)
 {
 }
 
diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
index c63b3d7a3cd9..92078e1eb627 100644
--- a/arch/arm64/kernel/mte.c
+++ b/arch/arm64/kernel/mte.c
@@ -153,11 +153,23 @@ void mte_init_tags(u64 max_tag)
write_sysreg_s(SYS_GCR_EL1_RRND | gcr_kernel_excl, SYS_GCR_EL1);
 }
 
-void mte_enable_kernel(void)
+static inline void __mte_enable_kernel(const char *mode, unsigned long tcf)
 {
/* Enable MTE Sync Mode for EL1. */
-   sysreg_clear_set(sctlr_el1, SCTLR_ELx_TCF_MASK, SCTLR_ELx_TCF_SYNC);
+   sysreg_clear_set(sctlr_el1, SCTLR_ELx_TCF_MASK, tcf);
isb();
+
+   pr_info_once("MTE: enabled in %s mode at EL1\n", mode);
+}
+
+void mte_enable_kernel_sync(void)
+{
+   __mte_enable_kernel("synchronous", SCTLR_ELx_TCF_SYNC);
+}
+
+void mte_enable_kernel_async(void)
+{
+   __mte_enable_kernel("asynchronous", SCTLR_ELx_TCF_ASYNC);
 }
 
 void mte_set_report_once(bool state)
-- 
2.30.0

[PATCH v6 4/4] arm64: mte: Enable async tag check fault

[Vincenzo Frascino]

MTE provides a mode that asynchronously updates the TFSR_EL1 register
when a tag check exception is detected.

To take advantage of this mode the kernel has to verify the status of
the register at:
  1. Context switching
  2. Return to user/EL0 (Not required in entry from EL0 since the kernel
  did not run)
  3. Kernel entry from EL1
  4. Kernel exit to EL1

If the register is non-zero a trace is reported.

Add the required features for EL1 detection and reporting.

Note: ITFSB bit is set in the SCTLR_EL1 register hence it guaranties that
the indirect writes to TFSR_EL1 are synchronized at exception entry to
EL1. On the context switch path the synchronization is guarantied by the
dsb() in __switch_to().
The dsb(nsh) in mte_check_tfsr_exit() is provisional pending
confirmation by the architects.

Cc: Catalin Marinas 
Cc: Will Deacon 
Reviewed-by: Catalin Marinas 
Signed-off-by: Vincenzo Frascino 
---
 arch/arm64/include/asm/mte.h | 32 +++
 arch/arm64/kernel/entry-common.c |  6 +
 arch/arm64/kernel/mte.c  | 44 
 3 files changed, 82 insertions(+)

diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
index d02aff9f493d..237bb2f7309d 100644
--- a/arch/arm64/include/asm/mte.h
+++ b/arch/arm64/include/asm/mte.h
@@ -92,5 +92,37 @@ static inline void mte_assign_mem_tag_range(void *addr, 
size_t size)
 
 #endif /* CONFIG_ARM64_MTE */
 
+#ifdef CONFIG_KASAN_HW_TAGS
+void mte_check_tfsr_el1(void);
+
+static inline void mte_check_tfsr_entry(void)
+{
+   mte_check_tfsr_el1();
+}
+
+static inline void mte_check_tfsr_exit(void)
+{
+   /*
+* The asynchronous faults are sync'ed automatically with
+* TFSR_EL1 on kernel entry but for exit an explicit dsb()
+* is required.
+*/
+   dsb(nsh);
+   isb();
+
+   mte_check_tfsr_el1();
+}
+#else
+static inline void mte_check_tfsr_el1(void)
+{
+}
+static inline void mte_check_tfsr_entry(void)
+{
+}
+static inline void mte_check_tfsr_exit(void)
+{
+}
+#endif /* CONFIG_KASAN_HW_TAGS */
+
 #endif /* __ASSEMBLY__ */
 #endif /* __ASM_MTE_H  */
diff --git a/arch/arm64/kernel/entry-common.c b/arch/arm64/kernel/entry-common.c
index 5346953e4382..31666511ba67 100644
--- a/arch/arm64/kernel/entry-common.c
+++ b/arch/arm64/kernel/entry-common.c
@@ -37,6 +37,8 @@ static void noinstr enter_from_kernel_mode(struct pt_regs 
*regs)
lockdep_hardirqs_off(CALLER_ADDR0);
rcu_irq_enter_check_tick();
trace_hardirqs_off_finish();
+
+   mte_check_tfsr_entry();
 }
 
 /*
@@ -47,6 +49,8 @@ static void noinstr exit_to_kernel_mode(struct pt_regs *regs)
 {
lockdep_assert_irqs_disabled();
 
+   mte_check_tfsr_exit();
+
if (interrupts_enabled(regs)) {
if (regs->exit_rcu) {
trace_hardirqs_on_prepare();
@@ -243,6 +247,8 @@ asmlinkage void noinstr enter_from_user_mode(void)
 
 asmlinkage void noinstr exit_to_user_mode(void)
 {
+   mte_check_tfsr_exit();
+
trace_hardirqs_on_prepare();
lockdep_hardirqs_on_prepare(CALLER_ADDR0);
user_enter_irqoff();
diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c
index 92078e1eb627..7763ac1f2917 100644
--- a/arch/arm64/kernel/mte.c
+++ b/arch/arm64/kernel/mte.c
@@ -182,6 +182,37 @@ bool mte_report_once(void)
return READ_ONCE(report_fault_once);
 }
 
+#ifdef CONFIG_KASAN_HW_TAGS
+void mte_check_tfsr_el1(void)
+{
+   u64 tfsr_el1;
+
+   if (!system_supports_mte())
+   return;
+
+   tfsr_el1 = read_sysreg_s(SYS_TFSR_EL1);
+
+   /*
+* The kernel should never trigger an asynchronous fault on a
+* TTBR0 address, so we should never see TF0 set.
+* For futexes we disable checks via PSTATE.TCO.
+*/
+   WARN_ONCE(tfsr_el1 & SYS_TFSR_EL1_TF0,
+ "Kernel async tag fault on TTBR0 address");
+
+   if (unlikely(tfsr_el1 & SYS_TFSR_EL1_TF1)) {
+   /*
+* Note: isb() is not required after this direct write
+* because there is no indirect read subsequent to it
+* (per ARM DDI 0487F.c table D13-1).
+*/
+   write_sysreg_s(0, SYS_TFSR_EL1);
+
+   kasan_report_async();
+   }
+}
+#endif
+
 static void update_sctlr_el1_tcf0(u64 tcf0)
 {
/* ISB required for the kernel uaccess routines */
@@ -247,6 +278,19 @@ void mte_thread_switch(struct task_struct *next)
/* avoid expensive SCTLR_EL1 accesses if no change */
if (current->thread.sctlr_tcf0 != next->thread.sctlr_tcf0)
update_sctlr_el1_tcf0(next->thread.sctlr_tcf0);
+   else
+   isb();
+
+   /*
+* Check if an async tag exception occurred at EL1.
+*
+* Note: On the context switch path we rely on the dsb() present
+* in __switch_to() to guarantee that the indirect writes to TFSR_EL1
+* are synchronized before thi

Re: [PATCH v7 1/2] dt-bindings: iio: accel: Add bmi088 accelerometer bindings

[Rob Herring]

On Thu, 21 Jan 2021 16:56:58 +0100, Mike Looijmans wrote:
> This adds the device-tree bindings for the Bosch Sensortec BMI088 IMU,
> the accelerometer part.
> 
> Signed-off-by: Mike Looijmans 
> 
> ---
> 
> Changes in v7:
> Add additionalProperties
> Change bmi088_accel to bmi088-accel
> Add interrupt-names and adjust description
> 
> Changes in v6:
> I't been almost a year since the last commit, sorry...
> Fixed the yaml errors
> Add interrupt, vdd and vddio properties
> 
> Changes in v5:
> submit together with driver code as patch series
> 
> Changes in v2:
> convert to yaml format
> 
>  .../bindings/iio/accel/bosch,bmi088.yaml  | 66 +++
>  1 file changed, 66 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/iio/accel/bosch,bmi088.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iio/accel/bosch,bmi088.example.dt.yaml:
 bmi088-accel@1: 'spi-max-frequency' does not match any of the regexes: 
'pinctrl-[0-9]+'
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iio/accel/bosch,bmi088.yaml

See https://patchwork.ozlabs.org/patch/1429940

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

[PATCH v6 2/4] kasan: Add KASAN mode kernel parameter

[Vincenzo Frascino]

Architectures supported by KASAN_HW_TAGS can provide a sync or async mode
of execution. On an MTE enabled arm64 hw for example this can be identified
with the synchronous or asynchronous tagging mode of execution.
In synchronous mode, an exception is triggered if a tag check fault occurs.
In asynchronous mode, if a tag check fault occurs, the TFSR_EL1 register is
updated asynchronously. The kernel checks the corresponding bits
periodically.

KASAN requires a specific kernel command line parameter to make use of this
hw features.

Add KASAN HW execution mode kernel command line parameter.

Note: This patch adds the kasan.mode kernel parameter and the
sync/async kernel command line options to enable the described features.

Cc: Dmitry Vyukov 
Cc: Andrey Ryabinin 
Cc: Alexander Potapenko 
Cc: Andrey Konovalov 
Signed-off-by: Vincenzo Frascino 
---
 Documentation/dev-tools/kasan.rst |  9 +
 lib/test_kasan.c  |  2 +-
 mm/kasan/hw_tags.c| 32 ++-
 mm/kasan/kasan.h  |  6 --
 4 files changed, 45 insertions(+), 4 deletions(-)

diff --git a/Documentation/dev-tools/kasan.rst 
b/Documentation/dev-tools/kasan.rst
index e022b7506e37..e3dca4d1f2a7 100644
--- a/Documentation/dev-tools/kasan.rst
+++ b/Documentation/dev-tools/kasan.rst
@@ -161,6 +161,15 @@ particular KASAN features.
 
 - ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``).
 
+- ``kasan.mode=sync`` or ``=async`` controls whether KASAN is configured in
+  synchronous or asynchronous mode of execution (default: ``sync``).
+  Synchronous mode: a bad access is detected immediately when a tag
+  check fault occurs.
+  Asynchronous mode: a bad access detection is delayed. When a tag check
+  fault occurs, the information is stored in hardware (in the TFSR_EL1
+  register for arm64). The kernel periodically checks the hardware and
+  only reports tag faults during these checks.
+
 - ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack
   traces collection (default: ``on`` for ``CONFIG_DEBUG_KERNEL=y``, otherwise
   ``off``).
diff --git a/lib/test_kasan.c b/lib/test_kasan.c
index d16ec9e66806..7285dcf9fcc1 100644
--- a/lib/test_kasan.c
+++ b/lib/test_kasan.c
@@ -97,7 +97,7 @@ static void kasan_test_exit(struct kunit *test)
READ_ONCE(fail_data.report_found)); \
if (IS_ENABLED(CONFIG_KASAN_HW_TAGS)) { \
if (READ_ONCE(fail_data.report_found))  \
-   hw_enable_tagging();\
+   hw_enable_tagging_sync();   \
migrate_enable();   \
}   \
 } while (0)
diff --git a/mm/kasan/hw_tags.c b/mm/kasan/hw_tags.c
index e529428e7a11..308a879a3798 100644
--- a/mm/kasan/hw_tags.c
+++ b/mm/kasan/hw_tags.c
@@ -25,6 +25,12 @@ enum kasan_arg {
KASAN_ARG_ON,
 };
 
+enum kasan_arg_mode {
+   KASAN_ARG_MODE_DEFAULT,
+   KASAN_ARG_MODE_SYNC,
+   KASAN_ARG_MODE_ASYNC,
+};
+
 enum kasan_arg_stacktrace {
KASAN_ARG_STACKTRACE_DEFAULT,
KASAN_ARG_STACKTRACE_OFF,
@@ -38,6 +44,7 @@ enum kasan_arg_fault {
 };
 
 static enum kasan_arg kasan_arg __ro_after_init;
+static enum kasan_arg_mode kasan_arg_mode __ro_after_init;
 static enum kasan_arg_stacktrace kasan_arg_stacktrace __ro_after_init;
 static enum kasan_arg_fault kasan_arg_fault __ro_after_init;
 
@@ -68,6 +75,21 @@ static int __init early_kasan_flag(char *arg)
 }
 early_param("kasan", early_kasan_flag);
 
+/* kasan.mode=sync/async */
+static int __init early_kasan_mode(char *arg)
+{
+   /* If arg is not set the default mode is sync */
+   if ((!arg) || !strcmp(arg, "sync"))
+   kasan_arg_mode = KASAN_ARG_MODE_SYNC;
+   else if (!strcmp(arg, "async"))
+   kasan_arg_mode = KASAN_ARG_MODE_ASYNC;
+   else
+   return -EINVAL;
+
+   return 0;
+}
+early_param("kasan.mode", early_kasan_mode);
+
 /* kasan.stacktrace=off/on */
 static int __init early_kasan_flag_stacktrace(char *arg)
 {
@@ -115,7 +137,15 @@ void kasan_init_hw_tags_cpu(void)
return;
 
hw_init_tags(KASAN_TAG_MAX);
-   hw_enable_tagging();
+
+   /*
+* Enable async mode only when explicitly requested through
+* the command line.
+*/
+   if (kasan_arg_mode == KASAN_ARG_MODE_ASYNC)
+   hw_enable_tagging_async();
+   else
+   hw_enable_tagging_sync();
 }
 
 /* kasan_init_hw_tags() is called once on boot CPU. */
diff --git a/mm/kasan/kasan.h b/mm/kasan/kasan.h
index 07ef7fc742ad..3923d9744105 100644
--- a/mm/kasan/kasan.h
+++ b/mm/kasan/kasan.h
@@ -294,7 +294,8 @@ static inline const void *arch_kasan_set_tag(const void 
*addr, u8 tag)
 #define arch_set_mem_tag_range(addr, size, tag) ((void *)(addr))
 #endif
 
-#define hw_enable_tagging()  

[PATCH v5 5/5] mm: remove unneeded local variable in free_area_init_core

[Baoquan He]

Local variable 'zone_start_pfn' is not needed since there's only
one call site in free_area_init_core(). Let's remove it and pass
zone->zone_start_pfn directly to init_currently_empty_zone().

Signed-off-by: Baoquan He 
Reviewed-by: Mike Rapoport 
Reviewed-by: David Hildenbrand 
---
 mm/page_alloc.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 69cf19baac12..e0df67948ace 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6923,7 +6923,6 @@ static void __init free_area_init_core(struct pglist_data 
*pgdat)
for (j = 0; j < MAX_NR_ZONES; j++) {
struct zone *zone = pgdat->node_zones + j;
unsigned long size, freesize, memmap_pages;
-   unsigned long zone_start_pfn = zone->zone_start_pfn;
 
size = zone->spanned_pages;
freesize = zone->present_pages;
@@ -6972,7 +6971,7 @@ static void __init free_area_init_core(struct pglist_data 
*pgdat)
 
set_pageblock_order();
setup_usemap(zone);
-   init_currently_empty_zone(zone, zone_start_pfn, size);
+   init_currently_empty_zone(zone, zone->zone_start_pfn, size);
memmap_init_zone(zone);
}
 }
-- 
2.17.2

[PATCH v5 4/5] mm: simplify parameter of setup_usemap()

[Baoquan He]

Parameter 'zone' has got needed information, let's remove other
unnecessary parameters.

Signed-off-by: Baoquan He 
Reviewed-by: Mike Rapoport 
Reviewed-by: David Hildenbrand 
---
 mm/page_alloc.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index cbb67d9c1b2a..69cf19baac12 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6761,25 +6761,22 @@ static unsigned long __init usemap_size(unsigned long 
zone_start_pfn, unsigned l
return usemapsize / 8;
 }
 
-static void __ref setup_usemap(struct pglist_data *pgdat,
-   struct zone *zone,
-   unsigned long zone_start_pfn,
-   unsigned long zonesize)
+static void __ref setup_usemap(struct zone *zone)
 {
-   unsigned long usemapsize = usemap_size(zone_start_pfn, zonesize);
+   unsigned long usemapsize = usemap_size(zone->zone_start_pfn,
+  zone->spanned_pages);
zone->pageblock_flags = NULL;
if (usemapsize) {
zone->pageblock_flags =
memblock_alloc_node(usemapsize, SMP_CACHE_BYTES,
-   pgdat->node_id);
+   zone_to_nid(zone));
if (!zone->pageblock_flags)
panic("Failed to allocate %ld bytes for zone %s 
pageblock flags on node %d\n",
- usemapsize, zone->name, pgdat->node_id);
+ usemapsize, zone->name, zone_to_nid(zone));
}
 }
 #else
-static inline void setup_usemap(struct pglist_data *pgdat, struct zone *zone,
-   unsigned long zone_start_pfn, unsigned long 
zonesize) {}
+static inline void setup_usemap(struct zone *zone) {}
 #endif /* CONFIG_SPARSEMEM */
 
 #ifdef CONFIG_HUGETLB_PAGE_SIZE_VARIABLE
@@ -6974,7 +6971,7 @@ static void __init free_area_init_core(struct pglist_data 
*pgdat)
continue;
 
set_pageblock_order();
-   setup_usemap(pgdat, zone, zone_start_pfn, size);
+   setup_usemap(zone);
init_currently_empty_zone(zone, zone_start_pfn, size);
memmap_init_zone(zone);
}
-- 
2.17.2

[PATCH v5 2/5] mm: rename memmap_init() and memmap_init_zone()

[Baoquan He]

The current memmap_init_zone() only handles memory region inside one zone,
actually memmap_init() does the memmap init of one zone. So rename both of
them accordingly.

Signed-off-by: Baoquan He 
---
 arch/ia64/mm/init.c | 6 +++---
 include/linux/mm.h  | 4 ++--
 mm/memory_hotplug.c | 2 +-
 mm/page_alloc.c | 8 
 4 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index e76386a3479e..c8e68e92beb3 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -535,18 +535,18 @@ virtual_memmap_init(u64 start, u64 end, void *arg)
/ sizeof(struct page));
 
if (map_start < map_end)
-   memmap_init_zone((unsigned long)(map_end - map_start),
+   memmap_init_range((unsigned long)(map_end - map_start),
 args->nid, args->zone, page_to_pfn(map_start), 
page_to_pfn(map_end),
 MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
return 0;
 }
 
 void __meminit
-memmap_init (unsigned long size, int nid, unsigned long zone,
+memmap_init_zone(unsigned long size, int nid, unsigned long zone,
 unsigned long start_pfn)
 {
if (!vmem_map) {
-   memmap_init_zone(size, nid, zone, start_pfn, start_pfn + size,
+   memmap_init_range(size, nid, zone, start_pfn, start_pfn + size,
 MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
} else {
struct page *start;
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 3d82b4f7cabc..2395dc212221 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2398,10 +2398,10 @@ extern int __meminit early_pfn_to_nid(unsigned long 
pfn);
 #endif
 
 extern void set_dma_reserve(unsigned long new_dma_reserve);
-extern void memmap_init_zone(unsigned long, int, unsigned long,
+extern void memmap_init_range(unsigned long, int, unsigned long,
unsigned long, unsigned long, enum meminit_context,
struct vmem_altmap *, int migratetype);
-extern void memmap_init(unsigned long size, int nid,
+extern void memmap_init_zone(unsigned long size, int nid,
unsigned long zone, unsigned long range_start_pfn);
 extern void setup_per_zone_wmarks(void);
 extern int __meminit init_per_zone_wmark_min(void);
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index f9d57b9be8c7..ddcb1cd24c60 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -713,7 +713,7 @@ void __ref move_pfn_range_to_zone(struct zone *zone, 
unsigned long start_pfn,
 * expects the zone spans the pfn range. All the pages in the range
 * are reserved so nobody should be touching them so we should be safe
 */
-   memmap_init_zone(nr_pages, nid, zone_idx(zone), start_pfn, 0,
+   memmap_init_range(nr_pages, nid, zone_idx(zone), start_pfn, 0,
 MEMINIT_HOTPLUG, altmap, migratetype);
 
set_zone_contiguous(zone);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 44ec5594798d..42a1d2d2a87d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6117,7 +6117,7 @@ overlap_memmap_init(unsigned long zone, unsigned long 
*pfn)
  * (usually MIGRATE_MOVABLE). Besides setting the migratetype, no related
  * zone stats (e.g., nr_isolate_pageblock) are touched.
  */
-void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long 
zone,
+void __meminit memmap_init_range(unsigned long size, int nid, unsigned long 
zone,
unsigned long start_pfn, unsigned long zone_end_pfn,
enum meminit_context context,
struct vmem_altmap *altmap, int migratetype)
@@ -6254,7 +6254,7 @@ static void __meminit zone_init_free_lists(struct zone 
*zone)
}
 }
 
-void __meminit __weak memmap_init(unsigned long size, int nid,
+void __meminit __weak memmap_init_zone(unsigned long size, int nid,
  unsigned long zone,
  unsigned long range_start_pfn)
 {
@@ -6268,7 +6268,7 @@ void __meminit __weak memmap_init(unsigned long size, int 
nid,
 
if (end_pfn > start_pfn) {
size = end_pfn - start_pfn;
-   memmap_init_zone(size, nid, zone, start_pfn, 
range_end_pfn,
+   memmap_init_range(size, nid, zone, start_pfn, 
range_end_pfn,
 MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
}
}
@@ -6978,7 +6978,7 @@ static void __init free_area_init_core(struct pglist_data 
*pgdat)
set_pageblock_order();
setup_usemap(pgdat, zone, zone_start_pfn, size);
init_currently_empty_zone(zone, zone_start_pfn, size);
-   memmap_init(size, nid, j, zone_start_pfn);
+   memmap_init_zone(size, nid, j, zone_start_pfn);
}
 }
 
-- 
2.17.2

[PATCH v5 3/5] mm: simplify parater of function memmap_init_zone()

[Baoquan He]

As David suggested, simply passing 'struct zone *zone' is enough. We can
get all needed information from 'struct zone*' easily.

Suggested-by: David Hildenbrand 
Signed-off-by: Baoquan He 
---
 arch/ia64/mm/init.c | 12 +++-
 include/linux/mm.h  |  3 +--
 mm/page_alloc.c | 24 +++-
 3 files changed, 19 insertions(+), 20 deletions(-)

diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index c8e68e92beb3..88fb44895408 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -541,12 +541,14 @@ virtual_memmap_init(u64 start, u64 end, void *arg)
return 0;
 }
 
-void __meminit
-memmap_init_zone(unsigned long size, int nid, unsigned long zone,
-unsigned long start_pfn)
+void __meminit memmap_init_zone(struct zone *zone)
 {
+   int nid = zone_to_nid(zone), zone_id = zone_idx(zone);
+   unsigned long start_pfn = zone->zone_start_pfn;
+   unsigned long size = zone->spanned_pages;
+
if (!vmem_map) {
-   memmap_init_range(size, nid, zone, start_pfn, start_pfn + size,
+   memmap_init_range(size, nid, zone_id, start_pfn, start_pfn + 
size,
 MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
} else {
struct page *start;
@@ -556,7 +558,7 @@ memmap_init_zone(unsigned long size, int nid, unsigned long 
zone,
args.start = start;
args.end = start + size;
args.nid = nid;
-   args.zone = zone;
+   args.zone = zone_id;
 
efi_memmap_walk(virtual_memmap_init, &args);
}
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 2395dc212221..073049bd0b29 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2401,8 +2401,7 @@ extern void set_dma_reserve(unsigned long 
new_dma_reserve);
 extern void memmap_init_range(unsigned long, int, unsigned long,
unsigned long, unsigned long, enum meminit_context,
struct vmem_altmap *, int migratetype);
-extern void memmap_init_zone(unsigned long size, int nid,
-   unsigned long zone, unsigned long range_start_pfn);
+extern void memmap_init_zone(struct zone *zone);
 extern void setup_per_zone_wmarks(void);
 extern int __meminit init_per_zone_wmark_min(void);
 extern void mem_init(void);
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 42a1d2d2a87d..cbb67d9c1b2a 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6254,23 +6254,21 @@ static void __meminit zone_init_free_lists(struct zone 
*zone)
}
 }
 
-void __meminit __weak memmap_init_zone(unsigned long size, int nid,
- unsigned long zone,
- unsigned long range_start_pfn)
+void __meminit __weak memmap_init_zone(struct zone *zone)
 {
+   unsigned long zone_start_pfn = zone->zone_start_pfn;
+   unsigned long zone_end_pfn = zone_start_pfn + zone->spanned_pages;
+   int i, nid = zone_to_nid(zone), zone_id = zone_idx(zone);
unsigned long start_pfn, end_pfn;
-   unsigned long range_end_pfn = range_start_pfn + size;
-   int i;
 
for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn, NULL) {
-   start_pfn = clamp(start_pfn, range_start_pfn, range_end_pfn);
-   end_pfn = clamp(end_pfn, range_start_pfn, range_end_pfn);
+   start_pfn = clamp(start_pfn, zone_start_pfn, zone_end_pfn);
+   end_pfn = clamp(end_pfn, zone_start_pfn, zone_end_pfn);
 
-   if (end_pfn > start_pfn) {
-   size = end_pfn - start_pfn;
-   memmap_init_range(size, nid, zone, start_pfn, 
range_end_pfn,
-MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
-   }
+   if (end_pfn > start_pfn)
+   memmap_init_range(end_pfn - start_pfn, nid,
+   zone_id, start_pfn, zone_end_pfn,
+   MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
}
 }
 
@@ -6978,7 +6976,7 @@ static void __init free_area_init_core(struct pglist_data 
*pgdat)
set_pageblock_order();
setup_usemap(pgdat, zone, zone_start_pfn, size);
init_currently_empty_zone(zone, zone_start_pfn, size);
-   memmap_init_zone(size, nid, j, zone_start_pfn);
+   memmap_init_zone(zone);
}
 }
 
-- 
2.17.2

[PATCH v5 1/5] mm: fix prototype warning from kernel test robot

[Baoquan He]

Kernel test robot calling make with 'W=1' is triggering warning like
below for memmap_init_zone() function.

mm/page_alloc.c:6259:23: warning: no previous prototype for 'memmap_init_zone' 
[-Wmissing-prototypes]
 6259 | void __meminit __weak memmap_init_zone(unsigned long size, int nid,
  |   ^~~~

Fix it by adding the function declaration in include/linux/mm.h.
Since memmap_init_zone() has a generic version with '__weak',
the declaratoin in ia64 header file can be simply removed.

Signed-off-by: Baoquan He 
Reported-by: kernel test robot 
---
 arch/ia64/include/asm/pgtable.h | 6 --
 include/linux/mm.h  | 2 ++
 2 files changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/ia64/include/asm/pgtable.h b/arch/ia64/include/asm/pgtable.h
index 779b6972aa84..9b4efe89e62d 100644
--- a/arch/ia64/include/asm/pgtable.h
+++ b/arch/ia64/include/asm/pgtable.h
@@ -517,12 +517,6 @@ extern struct page *zero_page_memmap_ptr;
__changed;  \
 })
 #endif
-
-#  ifdef CONFIG_VIRTUAL_MEM_MAP
-  /* arch mem_map init routine is needed due to holes in a virtual mem_map */
-extern void memmap_init (unsigned long size, int nid, unsigned long zone,
-unsigned long start_pfn);
-#  endif /* CONFIG_VIRTUAL_MEM_MAP */
 # endif /* !__ASSEMBLY__ */
 
 /*
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 3dac7bc667ee..3d82b4f7cabc 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2401,6 +2401,8 @@ extern void set_dma_reserve(unsigned long 
new_dma_reserve);
 extern void memmap_init_zone(unsigned long, int, unsigned long,
unsigned long, unsigned long, enum meminit_context,
struct vmem_altmap *, int migratetype);
+extern void memmap_init(unsigned long size, int nid,
+   unsigned long zone, unsigned long range_start_pfn);
 extern void setup_per_zone_wmarks(void);
 extern int __meminit init_per_zone_wmark_min(void);
 extern void mem_init(void);
-- 
2.17.2

[PATCH v5 0/5] mm: clean up names and parameters of memmap_init_xxxx functions

[Baoquan He]

This patchset is correcting inappropriate function names of
memmap_init_xxx, and simplify parameters of functions in the code flow.
And also fix a prototype warning reported by lkp.

This is based on the latest next/master.

V4 can be found here:
https://lore.kernel.org/linux-mm/20210120045213.6571-1-...@redhat.com/

v4->v5:
 - Add patch 1 into series which fixes a prototype warning from kernel
   test robot. Then rebase the v4 patches on top of it.

v3->v4:
 - Rebased patch 1, 2 on top of Mike's below new patch.
   [PATCH v3 0/2] mm: fix initialization of struct page for holes in  memory 
layout

 - Move the code of renaming function parameter 'range_start_pfn' and local
   variable 'range_end_pfn' of memmap_init() from patch 1 to patch 2
   according to David's comment.

 - Use the reverse Christmas tree style to reorder the local variables
   in memmap_init_zone() in patch 2 accodrding to David's comment.

Baoquan He (5):
  mm: fix prototype warning from kernel test robot
  mm: rename memmap_init() and memmap_init_zone()
  mm: simplify parater of function memmap_init_zone()
  mm: simplify parameter of setup_usemap()
  mm: remove unneeded local variable in free_area_init_core

 arch/ia64/include/asm/pgtable.h |  6 -
 arch/ia64/mm/init.c | 14 +-
 include/linux/mm.h  |  3 ++-
 mm/memory_hotplug.c |  2 +-
 mm/page_alloc.c | 46 ++---
 5 files changed, 31 insertions(+), 40 deletions(-)

-- 
2.17.2

Re: [PATCH v5 1/2] dt-bindings: pinctrl: qcom: Add SM8350 pinctrl bindings

[Rob Herring]

On Thu, 21 Jan 2021 22:47:46 +0530, Vinod Koul wrote:
> Add device tree binding Documentation details for Qualcomm SM8350
> pinctrl driver.
> 
> Signed-off-by: Vinod Koul 
> ---
>  .../bindings/pinctrl/qcom,sm8350-pinctrl.yaml | 146 ++
>  1 file changed, 146 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
Unknown file referenced: [Errno 2] No such file or directory: 
'/usr/local/lib/python3.8/dist-packages/dtschema/schemas/pinctrl/qcom,tlmm-common.yaml'
xargs: dt-doc-validate: exited with status 255; aborting
make[1]: *** Deleting file 
'Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.example.dt.yaml'
Unknown file referenced: [Errno 2] No such file or directory: 
'/usr/local/lib/python3.8/dist-packages/dtschema/schemas/pinctrl/qcom,tlmm-common.yaml'
make[1]: *** [scripts/Makefile.lib:344: 
Documentation/devicetree/bindings/pinctrl/qcom,sm8350-pinctrl.example.dt.yaml] 
Error 255
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:1370: dt_binding_check] Error 2

See https://patchwork.ozlabs.org/patch/1429976

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

Re: [PATCH v5 4/8] dt-bindings: regulator: Add document for MT6359 regulator

[Rob Herring]

On Fri, 22 Jan 2021 19:19:37 +0800, Hsin-Hsiung Wang wrote:
> add dt-binding document for MediaTek MT6359 PMIC
> 
> Signed-off-by: Hsin-Hsiung Wang 
> ---
> changes since v4: fix yamllint errors in dt-binding document.
> ---
>  .../bindings/regulator/mt6359-regulator.yaml  | 169 ++
>  1 file changed, 169 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.example.dt.yaml:
 pmic: 'adc', 'compatible' do not match any of the regexes: 'pinctrl-[0-9]+'
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iio/adc/motorola,cpcap-adc.example.dt.yaml:
 pmic: '#address-cells', '#size-cells', 'adc' do not match any of the regexes: 
'pinctrl-[0-9]+'
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iio/adc/sprd,sc2720-adc.example.dt.yaml:
 pmic: '#address-cells', '#size-cells', 'adc@480' do not match any of the 
regexes: 'pinctrl-[0-9]+'
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/iio/adc/qcom,pm8018-adc.example.dt.yaml:
 pmic: '#address-cells', '#size-cells', 'adc@197' do not match any of the 
regexes: 'pinctrl-[0-9]+'
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/regulator/mt6359-regulator.yaml

See https://patchwork.ozlabs.org/patch/1430288

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

Re: [PATCH v8 8/8] dt-bindings: thermal: tsens: Document ipq8064 bindings

[Rob Herring]

On Thu, 21 Jan 2021 20:18:53 +0100, Ansuel Smith wrote:
> Document the use of bindings used for msm8960 tsens based devices.
> msm8960 use the same gcc regs and is set as a child of the qcom gcc.
> 
> Signed-off-by: Ansuel Smith 
> ---
>  .../bindings/thermal/qcom-tsens.yaml  | 75 ---
>  1 file changed, 65 insertions(+), 10 deletions(-)
> 

My bot found errors running 'make dt_binding_check' on your patch:

yamllint warnings/errors:
./Documentation/devicetree/bindings/thermal/qcom-tsens.yaml:25:13: [warning] 
wrong indentation: expected 14 but found 12 (indentation)

dtschema/dtc warnings/errors:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/thermal/qcom-tsens.example.dt.yaml:
 thermal-sensor@4a9000: nvmem-cell-names: ['calib'] is too short
From schema: 
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml

See https://patchwork.ozlabs.org/patch/1430043

This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.

If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:

pip3 install dtschema --upgrade

Please check and re-submit.

[PATCH v18 03/10] fs/ntfs3: Add bitmap

[Konstantin Komarov]

This adds bitmap

Signed-off-by: Konstantin Komarov 
---
 fs/ntfs3/bitfunc.c |  135 
 fs/ntfs3/bitmap.c  | 1506 
 2 files changed, 1641 insertions(+)
 create mode 100644 fs/ntfs3/bitfunc.c
 create mode 100644 fs/ntfs3/bitmap.c

diff --git a/fs/ntfs3/bitfunc.c b/fs/ntfs3/bitfunc.c
new file mode 100644
index ..2d43d718d645
--- /dev/null
+++ b/fs/ntfs3/bitfunc.c
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *
+ * Copyright (C) 2019-2020 Paragon Software GmbH, All rights reserved.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+
+#include "debug.h"
+#include "ntfs.h"
+#include "ntfs_fs.h"
+
+#define BITS_IN_SIZE_T (sizeof(size_t) * 8)
+
+/*
+ * fill_mask[i] - first i bits are '1' , i = 0,1,2,3,4,5,6,7,8
+ * fill_mask[i] = 0xFF >> (8-i)
+ */
+static const u8 fill_mask[] = { 0x00, 0x01, 0x03, 0x07, 0x0F,
+   0x1F, 0x3F, 0x7F, 0xFF };
+
+/*
+ * zero_mask[i] - first i bits are '0' , i = 0,1,2,3,4,5,6,7,8
+ * zero_mask[i] = 0xFF << i
+ */
+static const u8 zero_mask[] = { 0xFF, 0xFE, 0xFC, 0xF8, 0xF0,
+   0xE0, 0xC0, 0x80, 0x00 };
+
+/*
+ * are_bits_clear
+ *
+ * Returns true if all bits [bit, bit+nbits) are zeros "0"
+ */
+bool are_bits_clear(const ulong *lmap, size_t bit, size_t nbits)
+{
+   size_t pos = bit & 7;
+   const u8 *map = (u8 *)lmap + (bit >> 3);
+
+   if (pos) {
+   if (8 - pos >= nbits)
+   return !nbits || !(*map & fill_mask[pos + nbits] &
+  zero_mask[pos]);
+
+   if (*map++ & zero_mask[pos])
+   return false;
+   nbits -= 8 - pos;
+   }
+
+   pos = ((size_t)map) & (sizeof(size_t) - 1);
+   if (pos) {
+   pos = sizeof(size_t) - pos;
+   if (nbits >= pos * 8) {
+   for (nbits -= pos * 8; pos; pos--, map++) {
+   if (*map)
+   return false;
+   }
+   }
+   }
+
+   for (pos = nbits / BITS_IN_SIZE_T; pos; pos--, map += sizeof(size_t)) {
+   if (*((size_t *)map))
+   return false;
+   }
+
+   for (pos = (nbits % BITS_IN_SIZE_T) >> 3; pos; pos--, map++) {
+   if (*map)
+   return false;
+   }
+
+   pos = nbits & 7;
+   if (pos && (*map & fill_mask[pos]))
+   return false;
+
+   // All bits are zero
+   return true;
+}
+
+/*
+ * are_bits_set
+ *
+ * Returns true if all bits [bit, bit+nbits) are ones "1"
+ */
+bool are_bits_set(const ulong *lmap, size_t bit, size_t nbits)
+{
+   u8 mask;
+   size_t pos = bit & 7;
+   const u8 *map = (u8 *)lmap + (bit >> 3);
+
+   if (pos) {
+   if (8 - pos >= nbits) {
+   mask = fill_mask[pos + nbits] & zero_mask[pos];
+   return !nbits || (*map & mask) == mask;
+   }
+
+   mask = zero_mask[pos];
+   if ((*map++ & mask) != mask)
+   return false;
+   nbits -= 8 - pos;
+   }
+
+   pos = ((size_t)map) & (sizeof(size_t) - 1);
+   if (pos) {
+   pos = sizeof(size_t) - pos;
+   if (nbits >= pos * 8) {
+   for (nbits -= pos * 8; pos; pos--, map++) {
+   if (*map != 0xFF)
+   return false;
+   }
+   }
+   }
+
+   for (pos = nbits / BITS_IN_SIZE_T; pos; pos--, map += sizeof(size_t)) {
+   if (*((size_t *)map) != MINUS_ONE_T)
+   return false;
+   }
+
+   for (pos = (nbits % BITS_IN_SIZE_T) >> 3; pos; pos--, map++) {
+   if (*map != 0xFF)
+   return false;
+   }
+
+   pos = nbits & 7;
+   if (pos) {
+   u8 mask = fill_mask[pos];
+
+   if ((*map & mask) != mask)
+   return false;
+   }
+
+   // All bits are ones
+   return true;
+}
diff --git a/fs/ntfs3/bitmap.c b/fs/ntfs3/bitmap.c
new file mode 100644
index ..1a4d65a6aac1
--- /dev/null
+++ b/fs/ntfs3/bitmap.c
@@ -0,0 +1,1506 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *
+ * Copyright (C) 2019-2020 Paragon Software GmbH, All rights reserved.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "debug.h"
+#include "ntfs.h"
+#include "ntfs_fs.h"
+
+struct rb_node_key {
+   struct rb_node node;
+   size_t key;
+};
+
+/*
+ * Tree is sorted by start (key)
+ */
+struct e_node {
+   struct rb_node_key start; /* Tree sorted by start */
+   struct rb_node_key count; /* Tree sorted by len*/
+};
+
+static int wnd_rescan(struct wnd_bitmap *wnd);
+static struct buffer_head *wnd_map(struct wnd_bitmap *wnd, size_t iw);
+static bool wnd_is_free_hlp(struct wnd

[PATCH v18 06/10] fs/ntfs3: Add compression

[Konstantin Komarov]

This patch adds different types of NTFS-applicable compressions:
- lznt
- lzx
- xpress
Latter two (lzx, xpress) implement Windows Compact OS feature and
were taken from ntfs-3g system comression plugin authored by Eric Biggers
(https://github.com/ebiggers/ntfs-3g-system-compression)
which were ported to ntfs3 and adapted to Linux Kernel environment.

Signed-off-by: Konstantin Komarov 
---
 fs/ntfs3/lib/decompress_common.c | 332 +++
 fs/ntfs3/lib/decompress_common.h | 352 
 fs/ntfs3/lib/lib.h   |  26 ++
 fs/ntfs3/lib/lzx_decompress.c| 683 +++
 fs/ntfs3/lib/xpress_decompress.c | 155 +++
 fs/ntfs3/lznt.c  | 452 
 6 files changed, 2000 insertions(+)
 create mode 100644 fs/ntfs3/lib/decompress_common.c
 create mode 100644 fs/ntfs3/lib/decompress_common.h
 create mode 100644 fs/ntfs3/lib/lib.h
 create mode 100644 fs/ntfs3/lib/lzx_decompress.c
 create mode 100644 fs/ntfs3/lib/xpress_decompress.c
 create mode 100644 fs/ntfs3/lznt.c

diff --git a/fs/ntfs3/lib/decompress_common.c b/fs/ntfs3/lib/decompress_common.c
new file mode 100644
index ..83c9e93aea77
--- /dev/null
+++ b/fs/ntfs3/lib/decompress_common.c
@@ -0,0 +1,332 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * decompress_common.c - Code shared by the XPRESS and LZX decompressors
+ *
+ * Copyright (C) 2015 Eric Biggers
+ *
+ * This program is free software: you can redistribute it and/or modify it 
under
+ * the terms of the GNU General Public License as published by the Free 
Software
+ * Foundation, either version 2 of the License, or (at your option) any later
+ * version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 
FITNESS
+ * FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more
+ * details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "decompress_common.h"
+
+/*
+ * make_huffman_decode_table() -
+ *
+ * Build a decoding table for a canonical prefix code, or "Huffman code".
+ *
+ * This is an internal function, not part of the library API!
+ *
+ * This takes as input the length of the codeword for each symbol in the
+ * alphabet and produces as output a table that can be used for fast
+ * decoding of prefix-encoded symbols using read_huffsym().
+ *
+ * Strictly speaking, a canonical prefix code might not be a Huffman
+ * code.  But this algorithm will work either way; and in fact, since
+ * Huffman codes are defined in terms of symbol frequencies, there is no
+ * way for the decompressor to know whether the code is a true Huffman
+ * code or not until all symbols have been decoded.
+ *
+ * Because the prefix code is assumed to be "canonical", it can be
+ * reconstructed directly from the codeword lengths.  A prefix code is
+ * canonical if and only if a longer codeword never lexicographically
+ * precedes a shorter codeword, and the lexicographic ordering of
+ * codewords of the same length is the same as the lexicographic ordering
+ * of the corresponding symbols.  Consequently, we can sort the symbols
+ * primarily by codeword length and secondarily by symbol value, then
+ * reconstruct the prefix code by generating codewords lexicographically
+ * in that order.
+ *
+ * This function does not, however, generate the prefix code explicitly.
+ * Instead, it directly builds a table for decoding symbols using the
+ * code.  The basic idea is this: given the next 'max_codeword_len' bits
+ * in the input, we can look up the decoded symbol by indexing a table
+ * containing 2**max_codeword_len entries.  A codeword with length
+ * 'max_codeword_len' will have exactly one entry in this table, whereas
+ * a codeword shorter than 'max_codeword_len' will have multiple entries
+ * in this table.  Precisely, a codeword of length n will be represented
+ * by 2**(max_codeword_len - n) entries in this table.  The 0-based index
+ * of each such entry will contain the corresponding codeword as a prefix
+ * when zero-padded on the left to 'max_codeword_len' binary digits.
+ *
+ * That's the basic idea, but we implement two optimizations regarding
+ * the format of the decode table itself:
+ *
+ * - For many compression formats, the maximum codeword length is too
+ *   long for it to be efficient to build the full decoding table
+ *   whenever a new prefix code is used.  Instead, we can build the table
+ *   using only 2**table_bits entries, where 'table_bits' is some number
+ *   less than or equal to 'max_codeword_len'.  Then, only codewords of
+ *   length 'table_bits' and shorter can be directly looked up.  For
+ *   longer codewords, the direct lookup instead produces the root of a
+ *   binary tree.  Using this tree, the decoder can do traditional
+ *   bit-by-bit decoding of the remainder

[PATCH v18 08/10] fs/ntfs3: Add Kconfig, Makefile and doc

[Konstantin Komarov]

This adds Kconfig, Makefile and doc

Signed-off-by: Konstantin Komarov 
---
 Documentation/filesystems/ntfs3.rst | 107 
 fs/ntfs3/Kconfig|  45 
 fs/ntfs3/Makefile   |  31 
 3 files changed, 183 insertions(+)
 create mode 100644 Documentation/filesystems/ntfs3.rst
 create mode 100644 fs/ntfs3/Kconfig
 create mode 100644 fs/ntfs3/Makefile

diff --git a/Documentation/filesystems/ntfs3.rst 
b/Documentation/filesystems/ntfs3.rst
new file mode 100644
index ..fb29067360cc
--- /dev/null
+++ b/Documentation/filesystems/ntfs3.rst
@@ -0,0 +1,107 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+NTFS3
+=
+
+
+Summary and Features
+
+
+NTFS3 is fully functional NTFS Read-Write driver. The driver works with
+NTFS versions up to 3.1, normal/compressed/sparse files
+and journal replaying. File system type to use on mount is 'ntfs3'.
+
+- This driver implements NTFS read/write support for normal, sparse and
+  compressed files.
+- Supports native journal replaying;
+- Supports extended attributes
+   Predefined extended attributes:
+   - 'system.ntfs_security' gets/sets security
+   descriptor (SECURITY_DESCRIPTOR_RELATIVE)
+   - 'system.ntfs_attrib' gets/sets ntfs file/dir attributes.
+   Note: applied to empty files, this allows to switch type between
+   sparse(0x200), compressed(0x800) and normal;
+- Supports NFS export of mounted NTFS volumes.
+
+Mount Options
+=
+
+The list below describes mount options supported by NTFS3 driver in addition to
+generic ones.
+
+===
+
+nls=name   This option informs the driver how to interpret path
+   strings and translate them to Unicode and back. If
+   this option is not set, the default codepage will be
+   used (CONFIG_NLS_DEFAULT).
+   Examples:
+   'nls=utf8'
+
+uid=
+gid=
+umask= Controls the default permissions for files/directories 
created
+   after the NTFS volume is mounted.
+
+fmask=
+dmask= Instead of specifying umask which applies both to
+   files and directories, fmask applies only to files and
+   dmask only to directories.
+
+nohidden   Files with the Windows-specific HIDDEN 
(FILE_ATTRIBUTE_HIDDEN)
+   attribute will not be shown under Linux.
+
+sys_immutable  Files with the Windows-specific SYSTEM
+   (FILE_ATTRIBUTE_SYSTEM) attribute will be marked as 
system
+   immutable files.
+
+discardEnable support of the TRIM command for improved 
performance
+   on delete operations, which is recommended for use with 
the
+   solid-state drives (SSD).
+
+force  Forces the driver to mount partitions even if 'dirty' 
flag
+   (volume dirty) is set. Not recommended for use.
+
+sparse Create new files as "sparse".
+
+showmeta   Use this parameter to show all meta-files (System 
Files) on
+   a mounted NTFS partition.
+   By default, all meta-files are hidden.
+
+prealloc   Preallocate space for files excessively when file size 
is
+   increasing on writes. Decreases fragmentation in case of
+   parallel write operations to different files.
+
+no_acs_rules   "No access rules" mount option sets access rights for
+   files/folders to 777 and owner/group to root. This mount
+   option absorbs all other permissions:
+   - permissions change for files/folders will be reported
+   as successful, but they will remain 777;
+   - owner/group change will be reported as successful, but
+   they will stay as root
+
+aclSupport POSIX ACLs (Access Control Lists). Effective if
+   supported by Kernel. Not to be confused with NTFS ACLs.
+   The option specified as acl enables support for POSIX 
ACLs.
+
+noatimeAll files and directories will not update their 
last access
+   time attribute if a partition is mounted with this 
parameter.
+   This option can speed up file system operation.
+
+===
+
+ToDo list
+=
+
+- Full journaling support (currently journal replaying is supported) over JBD.
+
+
+References
+==
+https://www.paragon-software.com/home/ntfs-linux-professional/
+   

[PATCH v18 07/10] fs/ntfs3: Add NTFS journal

[Konstantin Komarov]

This adds NTFS journal

Signed-off-by: Konstantin Komarov 
---
 fs/ntfs3/fslog.c | 5204 ++
 1 file changed, 5204 insertions(+)
 create mode 100644 fs/ntfs3/fslog.c

diff --git a/fs/ntfs3/fslog.c b/fs/ntfs3/fslog.c
new file mode 100644
index ..1aeaa25441a2
--- /dev/null
+++ b/fs/ntfs3/fslog.c
@@ -0,0 +1,5204 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *
+ * Copyright (C) 2019-2020 Paragon Software GmbH, All rights reserved.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "debug.h"
+#include "ntfs.h"
+#include "ntfs_fs.h"
+
+/*
+ * LOG FILE structs
+ */
+
+// clang-format off
+
+#define MaxLogFileSize 0x1ull
+#define DefaultLogPageSize 4096
+#define MinLogRecordPages  0x30
+
+struct RESTART_HDR {
+   struct NTFS_RECORD_HEADER rhdr; // 'RSTR'
+   __le32 sys_page_size; // 0x10: Page size of the system which 
initialized the log
+   __le32 page_size; // 0x14: Log page size used for this log file
+   __le16 ra_off;// 0x18:
+   __le16 minor_ver; // 0x1A:
+   __le16 major_ver; // 0x1C:
+   __le16 fixups[1];
+};
+
+#define LFS_NO_CLIENT 0x
+#define LFS_NO_CLIENT_LE cpu_to_le16(0x)
+
+struct CLIENT_REC {
+   __le64 oldest_lsn;
+   __le64 restart_lsn; // 0x08:
+   __le16 prev_client; // 0x10:
+   __le16 next_client; // 0x12:
+   __le16 seq_num; // 0x14:
+   u8 align[6];// 0x16
+   __le32 name_bytes;  // 0x1C: in bytes
+   __le16 name[32];// 0x20: name of client
+};
+
+static_assert(sizeof(struct CLIENT_REC) == 0x60);
+
+/* Two copies of these will exist at the beginning of the log file */
+struct RESTART_AREA {
+   __le64 current_lsn;// 0x00: Current logical end of log file
+   __le16 log_clients;// 0x08: Maximum number of clients
+   __le16 client_idx[2];  // 0x0A: free/use index into the client record 
arrays
+   __le16 flags;  // 0x0E: See RESTART_SINGLE_PAGE_IO
+   __le32 seq_num_bits;   // 0x10: the number of bits in sequence number.
+   __le16 ra_len; // 0x14:
+   __le16 client_off; // 0x16:
+   __le64 l_size; // 0x18: Usable log file size.
+   __le32 last_lsn_data_len; // 0x20:
+   __le16 rec_hdr_len;// 0x24: log page data offset
+   __le16 data_off;   // 0x26: log page data length
+   __le32 open_log_count; // 0x28:
+   __le32 align[5];   // 0x2C:
+   struct CLIENT_REC clients[1]; // 0x40:
+};
+
+struct LOG_REC_HDR {
+   __le16 redo_op;  // 0x00:  NTFS_LOG_OPERATION
+   __le16 undo_op;  // 0x02:  NTFS_LOG_OPERATION
+   __le16 redo_off; // 0x04:  Offset to Redo record
+   __le16 redo_len; // 0x06:  Redo length
+   __le16 undo_off; // 0x08:  Offset to Undo record
+   __le16 undo_len; // 0x0A:  Undo length
+   __le16 target_attr;  // 0x0C:
+   __le16 lcns_follow;  // 0x0E:
+   __le16 record_off;   // 0x10:
+   __le16 attr_off; // 0x12:
+   __le16 cluster_off;  // 0x14:
+   __le16 reserved; // 0x16:
+   __le64 target_vcn;   // 0x18:
+   __le64 page_lcns[1]; // 0x20:
+};
+
+static_assert(sizeof(struct LOG_REC_HDR) == 0x28);
+
+#define RESTART_ENTRY_ALLOCATED0x
+#define RESTART_ENTRY_ALLOCATED_LE cpu_to_le32(0x)
+
+struct RESTART_TABLE {
+   __le16 size;   // 0x00:  In bytes
+   __le16 used;   // 0x02: entries
+   __le16 total;  // 0x04: entries
+   __le16 res[3]; // 0x06:
+   __le32 free_goal;  // 0x0C:
+   __le32 first_free; // 0x10
+   __le32 last_free;  // 0x14
+
+};
+
+static_assert(sizeof(struct RESTART_TABLE) == 0x18);
+
+struct ATTR_NAME_ENTRY {
+   __le16 off; // offset in the Open attribute Table
+   __le16 name_bytes;
+   __le16 name[1];
+};
+
+struct OPEN_ATTR_ENRTY {
+   __le32 next;// 0x00: RESTART_ENTRY_ALLOCATED if allocated
+   __le32 bytes_per_index; // 0x04:
+   enum ATTR_TYPE type;// 0x08:
+   u8 is_dirty_pages;  // 0x0C:
+   u8 is_attr_name;// 0x0B: Faked field to manage 'ptr'
+   u8 name_len;// 0x0C: Faked field to manage 'ptr'
+   u8 res;
+   struct MFT_REF ref; // 0x10: File Reference of file containing attribute
+   __le64 open_record_lsn; // 0x18:
+   void *ptr;  // 0x20:
+};
+
+/* 32 bit version of 'struct OPEN_ATTR_ENRTY' */
+struct OPEN_ATTR_ENRTY_32 {
+   __le32 next;// 0x00: RESTART_ENTRY_ALLOCATED if allocated
+   __le32 ptr; // 0x04:
+   struct MFT_REF ref; // 0x08:
+   __le64 open_record_lsn; // 0x10:
+   u8 is_dirty_pages;  // 0x18:
+   u8 is_attr_name;// 0x19
+   u8 res1[2];
+   enum ATTR_TYPE type;// 0x1C:
+   u8 name_len;// 0x20:  in wchar
+   u8 res2[3];
+   __le32 AttributeName;   // 0x24:
+ 

Re: [PATCH v6 0/4] arm64: ARMv8.5-A: MTE: Add async mode support

[Vincenzo Frascino]

On 1/22/21 1:59 PM, Vincenzo Frascino wrote:
> This patchset implements the asynchronous mode support for ARMv8.5-A
> Memory Tagging Extension (MTE), which is a debugging feature that allows
> to detect with the help of the architecture the C and C++ programmatic
> memory errors like buffer overflow, use-after-free, use-after-return, etc.
> 
> MTE is built on top of the AArch64 v8.0 virtual address tagging TBI
> (Top Byte Ignore) feature and allows a task to set a 4 bit tag on any
> subset of its address space that is multiple of a 16 bytes granule. MTE
> is based on a lock-key mechanism where the lock is the tag associated to
> the physical memory and the key is the tag associated to the virtual
> address.
> When MTE is enabled and tags are set for ranges of address space of a task,
> the PE will compare the tag related to the physical memory with the tag
> related to the virtual address (tag check operation). Access to the memory
> is granted only if the two tags match. In case of mismatch the PE will raise
> an exception.
> 
> The exception can be handled synchronously or asynchronously. When the
> asynchronous mode is enabled:
>   - Upon fault the PE updates the TFSR_EL1 register.
>   - The kernel detects the change during one of the following:
> - Context switching
> - Return to user/EL0
> - Kernel entry from EL1
> - Kernel exit to EL1
>   - If the register has been updated by the PE the kernel clears it and
> reports the error.
> 
> The series is based on linux-next/akpm.
> 
> To simplify the testing a tree with the new patches on top has been made
> available at [1].
> 
> [1] https://git.gitlab.arm.com/linux-arm/linux-vf.git mte/v10.async.akpm

Please ignore this series, I missed a fix. I will re-post it shortly. Sorry for
the inconvenience.

Thanks!

[tip: locking/core] locking: Add Reviewers

[tip-bot2 for Peter Zijlstra]

The following commit has been merged into the locking/core branch of tip:

Commit-ID: c7539258146844ebd8795c31275c720ded61bb84
Gitweb:
https://git.kernel.org/tip/c7539258146844ebd8795c31275c720ded61bb84
Author:Peter Zijlstra 
AuthorDate:Thu, 17 Dec 2020 10:32:16 +01:00
Committer: Peter Zijlstra 
CommitterDate: Fri, 22 Jan 2021 11:08:55 +01:00

locking: Add Reviewers

Spread the love..

Signed-off-by: Peter Zijlstra (Intel) 
Acked-by: Will Deacon 
Acked-by: Waiman Long 
Acked-by: Boqun Feng 
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 6eff4f7..de903d1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10373,6 +10373,8 @@ LOCKING PRIMITIVES
 M: Peter Zijlstra 
 M: Ingo Molnar 
 M: Will Deacon 
+R: Waiman Long 
+R: Boqun Feng  (LOCKDEP)
 L: linux-kernel@vger.kernel.org
 S: Maintained
 T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
locking/core

[tip: locking/core] jump_label: Do not profile branch annotations

[tip-bot2 for Steven Rostedt (VMware)]

The following commit has been merged into the locking/core branch of tip:

Commit-ID: 2f0df49c89acaa58571d509830bc481250699885
Gitweb:
https://git.kernel.org/tip/2f0df49c89acaa58571d509830bc481250699885
Author:Steven Rostedt (VMware) 
AuthorDate:Fri, 11 Dec 2020 16:37:54 -05:00
Committer: Peter Zijlstra 
CommitterDate: Fri, 22 Jan 2021 11:08:56 +01:00

jump_label: Do not profile branch annotations

While running my branch profiler that checks for incorrect "likely" and
"unlikely"s around the kernel, there's a large number of them that are
incorrect due to being "static_branches".

As static_branches are rather special, as they are likely or unlikely for
other reasons than normal annotations are used for, there's no reason to
have them be profiled.

Expose the "unlikely_notrace" and "likely_notrace" so that the
static_branch can use them, and have them be ignored by the branch
profilers.

Signed-off-by: Steven Rostedt (VMware) 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://lkml.kernel.org/r/20201211163754.58517...@gandalf.local.home
---
 include/linux/compiler.h   |  2 ++
 include/linux/jump_label.h | 12 ++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index b8fe0c2..df5b405 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -76,6 +76,8 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int 
val,
 #else
 # define likely(x) __builtin_expect(!!(x), 1)
 # define unlikely(x)   __builtin_expect(!!(x), 0)
+# define likely_notrace(x) likely(x)
+# define unlikely_notrace(x)   unlikely(x)
 #endif
 
 /* Optimization barrier */
diff --git a/include/linux/jump_label.h b/include/linux/jump_label.h
index 3280962..d926912 100644
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@ -261,14 +261,14 @@ static __always_inline void jump_label_init(void)
 
 static __always_inline bool static_key_false(struct static_key *key)
 {
-   if (unlikely(static_key_count(key) > 0))
+   if (unlikely_notrace(static_key_count(key) > 0))
return true;
return false;
 }
 
 static __always_inline bool static_key_true(struct static_key *key)
 {
-   if (likely(static_key_count(key) > 0))
+   if (likely_notrace(static_key_count(key) > 0))
return true;
return false;
 }
@@ -460,7 +460,7 @@ extern bool wrong_branch_error(void);
branch = !arch_static_branch_jump(&(x)->key, true); 
\
else
\
branch = wrong_branch_error();  
\
-   likely(branch); 
\
+   likely_notrace(branch); 
\
 })
 
 #define static_branch_unlikely(x)  
\
@@ -472,13 +472,13 @@ extern bool wrong_branch_error(void);
branch = arch_static_branch(&(x)->key, false);  
\
else
\
branch = wrong_branch_error();  
\
-   unlikely(branch);   
\
+   unlikely_notrace(branch);   
\
 })
 
 #else /* !CONFIG_JUMP_LABEL */
 
-#define static_branch_likely(x)
likely(static_key_enabled(&(x)->key))
-#define static_branch_unlikely(x)  unlikely(static_key_enabled(&(x)->key))
+#define static_branch_likely(x)
likely_notrace(static_key_enabled(&(x)->key))
+#define static_branch_unlikely(x)  
unlikely_notrace(static_key_enabled(&(x)->key))
 
 #endif /* CONFIG_JUMP_LABEL */
 

[PATCH v18 09/10] fs/ntfs3: Add NTFS3 in fs/Kconfig and fs/Makefile

[Konstantin Komarov]

This adds NTFS3 in fs/Kconfig and fs/Makefile

Signed-off-by: Konstantin Komarov 
---
 fs/Kconfig  | 1 +
 fs/Makefile | 1 +
 2 files changed, 2 insertions(+)

diff --git a/fs/Kconfig b/fs/Kconfig
index aa4c12282301..eae96d55ab67 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -145,6 +145,7 @@ menu "DOS/FAT/EXFAT/NT Filesystems"
 source "fs/fat/Kconfig"
 source "fs/exfat/Kconfig"
 source "fs/ntfs/Kconfig"
+source "fs/ntfs3/Kconfig"
 
 endmenu
 endif # BLOCK
diff --git a/fs/Makefile b/fs/Makefile
index 999d1a23f036..4f5242cdaee2 100644
--- a/fs/Makefile
+++ b/fs/Makefile
@@ -100,6 +100,7 @@ obj-$(CONFIG_SYSV_FS)   += sysv/
 obj-$(CONFIG_CIFS) += cifs/
 obj-$(CONFIG_HPFS_FS)  += hpfs/
 obj-$(CONFIG_NTFS_FS)  += ntfs/
+obj-$(CONFIG_NTFS3_FS) += ntfs3/
 obj-$(CONFIG_UFS_FS)   += ufs/
 obj-$(CONFIG_EFS_FS)   += efs/
 obj-$(CONFIG_JFFS2_FS) += jffs2/
-- 
2.25.4

[PATCH v18 10/10] fs/ntfs3: Add MAINTAINERS

[Konstantin Komarov]

This adds MAINTAINERS

Signed-off-by: Konstantin Komarov 
---
 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index f79ec98bbb29..49db3a3c15c5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12666,6 +12666,13 @@ T: git 
git://git.kernel.org/pub/scm/linux/kernel/git/aia21/ntfs.git
 F: Documentation/filesystems/ntfs.rst
 F: fs/ntfs/
 
+NTFS3 FILESYSTEM
+M: Konstantin Komarov 
+S: Supported
+W: http://www.paragon-software.com/
+F: Documentation/filesystems/ntfs3.rst
+F: fs/ntfs3/
+
 NUBUS SUBSYSTEM
 M: Finn Thain 
 L: linux-m...@lists.linux-m68k.org
-- 
2.25.4

[PATCH v18 05/10] fs/ntfs3: Add attrib operations

[Konstantin Komarov]

This adds attrib operations

Signed-off-by: Konstantin Komarov 
---
 fs/ntfs3/attrib.c   | 2085 +++
 fs/ntfs3/attrlist.c |  457 ++
 fs/ntfs3/xattr.c| 1072 ++
 3 files changed, 3614 insertions(+)
 create mode 100644 fs/ntfs3/attrib.c
 create mode 100644 fs/ntfs3/attrlist.c
 create mode 100644 fs/ntfs3/xattr.c

diff --git a/fs/ntfs3/attrib.c b/fs/ntfs3/attrib.c
new file mode 100644
index ..79360d94498d
--- /dev/null
+++ b/fs/ntfs3/attrib.c
@@ -0,0 +1,2085 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ *
+ * Copyright (C) 2019-2020 Paragon Software GmbH, All rights reserved.
+ *
+ * TODO: merge attr_set_size/attr_data_get_block/attr_allocate_frame?
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "debug.h"
+#include "ntfs.h"
+#include "ntfs_fs.h"
+
+/*
+ * You can set external NTFS_MIN_LOG2_OF_CLUMP/NTFS_MAX_LOG2_OF_CLUMP to manage
+ * preallocate algorithm
+ */
+#ifndef NTFS_MIN_LOG2_OF_CLUMP
+#define NTFS_MIN_LOG2_OF_CLUMP 16
+#endif
+
+#ifndef NTFS_MAX_LOG2_OF_CLUMP
+#define NTFS_MAX_LOG2_OF_CLUMP 26
+#endif
+
+// 16M
+#define NTFS_CLUMP_MIN (1 << (NTFS_MIN_LOG2_OF_CLUMP + 8))
+// 16G
+#define NTFS_CLUMP_MAX (1ull << (NTFS_MAX_LOG2_OF_CLUMP + 8))
+
+/*
+ * get_pre_allocated
+ *
+ */
+static inline u64 get_pre_allocated(u64 size)
+{
+   u32 clump;
+   u8 align_shift;
+   u64 ret;
+
+   if (size <= NTFS_CLUMP_MIN) {
+   clump = 1 << NTFS_MIN_LOG2_OF_CLUMP;
+   align_shift = NTFS_MIN_LOG2_OF_CLUMP;
+   } else if (size >= NTFS_CLUMP_MAX) {
+   clump = 1 << NTFS_MAX_LOG2_OF_CLUMP;
+   align_shift = NTFS_MAX_LOG2_OF_CLUMP;
+   } else {
+   align_shift = NTFS_MIN_LOG2_OF_CLUMP - 1 +
+ __ffs(size >> (8 + NTFS_MIN_LOG2_OF_CLUMP));
+   clump = 1u << align_shift;
+   }
+
+   ret = (((size + clump - 1) >> align_shift)) << align_shift;
+
+   return ret;
+}
+
+/*
+ * attr_must_be_resident
+ *
+ * returns true if attribute must be resident
+ */
+static inline bool attr_must_be_resident(struct ntfs_sb_info *sbi,
+enum ATTR_TYPE type)
+{
+   const struct ATTR_DEF_ENTRY *de;
+
+   switch (type) {
+   case ATTR_STD:
+   case ATTR_NAME:
+   case ATTR_ID:
+   case ATTR_LABEL:
+   case ATTR_VOL_INFO:
+   case ATTR_ROOT:
+   case ATTR_EA_INFO:
+   return true;
+   default:
+   de = ntfs_query_def(sbi, type);
+   if (de && (de->flags & NTFS_ATTR_MUST_BE_RESIDENT))
+   return true;
+   return false;
+   }
+}
+
+/*
+ * attr_load_runs
+ *
+ * load all runs stored in 'attr'
+ */
+int attr_load_runs(struct ATTRIB *attr, struct ntfs_inode *ni,
+  struct runs_tree *run, const CLST *vcn)
+{
+   int err;
+   CLST svcn = le64_to_cpu(attr->nres.svcn);
+   CLST evcn = le64_to_cpu(attr->nres.evcn);
+   u32 asize;
+   u16 run_off;
+
+   if (svcn >= evcn + 1 || run_is_mapped_full(run, svcn, evcn))
+   return 0;
+
+   if (vcn && (evcn < *vcn || *vcn < svcn))
+   return -EINVAL;
+
+   asize = le32_to_cpu(attr->size);
+   run_off = le16_to_cpu(attr->nres.run_off);
+   err = run_unpack_ex(run, ni->mi.sbi, ni->mi.rno, svcn, evcn,
+   vcn ? *vcn : svcn, Add2Ptr(attr, run_off),
+   asize - run_off);
+   if (err < 0)
+   return err;
+
+   return 0;
+}
+
+/*
+ * int run_deallocate_ex
+ *
+ * Deallocate clusters
+ */
+static int run_deallocate_ex(struct ntfs_sb_info *sbi, struct runs_tree *run,
+CLST vcn, CLST len, CLST *done, bool trim)
+{
+   int err = 0;
+   CLST vcn_next, vcn0 = vcn, lcn, clen, dn = 0;
+   size_t idx;
+
+   if (!len)
+   goto out;
+
+   if (!run_lookup_entry(run, vcn, &lcn, &clen, &idx)) {
+failed:
+   run_truncate(run, vcn0);
+   err = -EINVAL;
+   goto out;
+   }
+
+   for (;;) {
+   if (clen > len)
+   clen = len;
+
+   if (!clen) {
+   err = -EINVAL;
+   goto out;
+   }
+
+   if (lcn != SPARSE_LCN) {
+   mark_as_free_ex(sbi, lcn, clen, trim);
+   dn += clen;
+   }
+
+   len -= clen;
+   if (!len)
+   break;
+
+   vcn_next = vcn + clen;
+   if (!run_get_entry(run, ++idx, &vcn, &lcn, &clen) ||
+   vcn != vcn_next) {
+   // save memory - don't load entire run
+   goto failed;
+   }
+   }
+
+out:
+   if (done)
+   *done += dn;
+
+   return err;
+}
+
+/*
+ * attr_

[tip: locking/core] lockdep: report broken irq restoration

[tip-bot2 for Mark Rutland]

The following commit has been merged into the locking/core branch of tip:

Commit-ID: 997acaf6b4b59c6a9c259740312a69ea549cc684
Gitweb:
https://git.kernel.org/tip/997acaf6b4b59c6a9c259740312a69ea549cc684
Author:Mark Rutland 
AuthorDate:Mon, 11 Jan 2021 15:37:07 
Committer: Peter Zijlstra 
CommitterDate: Fri, 22 Jan 2021 11:08:56 +01:00

lockdep: report broken irq restoration

We generally expect local_irq_save() and local_irq_restore() to be
paired and sanely nested, and so local_irq_restore() expects to be
called with irqs disabled. Thus, within local_irq_restore() we only
trace irq flag changes when unmasking irqs.

This means that a sequence such as:

| local_irq_disable();
| local_irq_save(flags);
| local_irq_enable();
| local_irq_restore(flags);

... is liable to break things, as the local_irq_restore() would mask
irqs without tracing this change. Similar problems may exist for
architectures whose arch_irq_restore() function depends on being called
with irqs disabled.

We don't consider such sequences to be a good idea, so let's define
those as forbidden, and add tooling to detect such broken cases.

This patch adds debug code to WARN() when raw_local_irq_restore() is
called with irqs enabled. As raw_local_irq_restore() is expected to pair
with raw_local_irq_save(), it should never be called with irqs enabled.

To avoid the possibility of circular header dependencies between
irqflags.h and bug.h, the warning is handled in a separate C file.

The new code is all conditional on a new CONFIG_DEBUG_IRQFLAGS symbol
which is independent of CONFIG_TRACE_IRQFLAGS. As noted above such cases
will confuse lockdep, so CONFIG_DEBUG_LOCKDEP now selects
CONFIG_DEBUG_IRQFLAGS.

Signed-off-by: Mark Rutland 
Signed-off-by: Peter Zijlstra (Intel) 
Link: https://lkml.kernel.org/r/2021053707.10071-1-mark.rutl...@arm.com
---
 include/linux/irqflags.h   | 12 
 kernel/locking/Makefile|  1 +
 kernel/locking/irqflag-debug.c | 11 +++
 lib/Kconfig.debug  |  8 
 4 files changed, 32 insertions(+)
 create mode 100644 kernel/locking/irqflag-debug.c

diff --git a/include/linux/irqflags.h b/include/linux/irqflags.h
index 8de0e13..600c10d 100644
--- a/include/linux/irqflags.h
+++ b/include/linux/irqflags.h
@@ -149,6 +149,17 @@ do {   \
 # define start_critical_timings() do { } while (0)
 #endif
 
+#ifdef CONFIG_DEBUG_IRQFLAGS
+extern void warn_bogus_irq_restore(void);
+#define raw_check_bogus_irq_restore()  \
+   do {\
+   if (unlikely(!arch_irqs_disabled()))\
+   warn_bogus_irq_restore();   \
+   } while (0)
+#else
+#define raw_check_bogus_irq_restore() do { } while (0)
+#endif
+
 /*
  * Wrap the arch provided IRQ routines to provide appropriate checks.
  */
@@ -162,6 +173,7 @@ do {\
 #define raw_local_irq_restore(flags)   \
do {\
typecheck(unsigned long, flags);\
+   raw_check_bogus_irq_restore();  \
arch_local_irq_restore(flags);  \
} while (0)
 #define raw_local_save_flags(flags)\
diff --git a/kernel/locking/Makefile b/kernel/locking/Makefile
index 6d11cfb..8838f1d 100644
--- a/kernel/locking/Makefile
+++ b/kernel/locking/Makefile
@@ -15,6 +15,7 @@ CFLAGS_REMOVE_mutex-debug.o = $(CC_FLAGS_FTRACE)
 CFLAGS_REMOVE_rtmutex-debug.o = $(CC_FLAGS_FTRACE)
 endif
 
+obj-$(CONFIG_DEBUG_IRQFLAGS) += irqflag-debug.o
 obj-$(CONFIG_DEBUG_MUTEXES) += mutex-debug.o
 obj-$(CONFIG_LOCKDEP) += lockdep.o
 ifeq ($(CONFIG_PROC_FS),y)
diff --git a/kernel/locking/irqflag-debug.c b/kernel/locking/irqflag-debug.c
new file mode 100644
index 000..9603d20
--- /dev/null
+++ b/kernel/locking/irqflag-debug.c
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include 
+#include 
+#include 
+
+void warn_bogus_irq_restore(void)
+{
+   WARN_ONCE(1, "raw_local_irq_restore() called with IRQs enabled\n");
+}
+EXPORT_SYMBOL(warn_bogus_irq_restore);
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index e6e58b2..78eadf6 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1343,6 +1343,7 @@ config LOCKDEP_SMALL
 config DEBUG_LOCKDEP
bool "Lock dependency engine debugging"
depends on DEBUG_KERNEL && LOCKDEP
+   select DEBUG_IRQFLAGS
help
  If you say Y here, the lock dependency engine will do
  additional runtime checks to debug itself, at the price
@@ -1431,6 +1432,13 @@ config TRACE_IRQFLAGS_NMI
depends on TRACE_IRQFLAGS
depends on TRACE_IRQFLAGS_NMI_SUPPORT
 
+config DEBUG_IRQFLAGS
+   bool "Debug IRQ flag manipulation"
+   help
+ Enables checks for potentially unsafe enabling or disabling of
+ interrupts, such as calling 

Re: [RFC PATCH v2] taskstats: add /proc/taskstats to fetch pid/tgid status

[Weiping Zhang]

Hello Balbir Singh,

Could you help review this patch, thanks

On Mon, Dec 28, 2020 at 10:10 PM Weiping Zhang  wrote:
>
> Hi David,
>
> Could you help review this patch ?
>
> thanks
>
> On Fri, Dec 18, 2020 at 1:24 AM Weiping Zhang
>  wrote:
> >
> > If a program needs monitor lots of process's status, it needs two
> > syscalls for every process. The first one is telling kernel which
> > pid/tgid should be monitored by send a command(write socket) to kernel.
> > The second one is read the statistics by read socket. This patch add
> > a new interface /proc/taskstats to reduce two syscalls to one ioctl.
> > The user just set the target pid/tgid to the struct taskstats.ac_pid,
> > then kernel will collect statistics for that pid/tgid.
> >
> > Signed-off-by: Weiping Zhang 
> > ---
> > Changes since v1:
> >  * use /proc/taskstats instead of /dev/taskstats
> >
> >  include/uapi/linux/taskstats.h |  5 +++
> >  kernel/taskstats.c | 73 +-
> >  2 files changed, 77 insertions(+), 1 deletion(-)
> >
> > diff --git a/include/uapi/linux/taskstats.h b/include/uapi/linux/taskstats.h
> > index ccbd08709321..077eab84c77e 100644
> > --- a/include/uapi/linux/taskstats.h
> > +++ b/include/uapi/linux/taskstats.h
> > @@ -214,6 +214,11 @@ enum {
> >
> >  #define TASKSTATS_CMD_ATTR_MAX (__TASKSTATS_CMD_ATTR_MAX - 1)
> >
> > +/* ioctl command */
> > +#define TASKSTATS_IOC_ATTR_PID _IO('T', TASKSTATS_CMD_ATTR_PID)
> > +#define TASKSTATS_IOC_ATTR_TGID_IO('T', TASKSTATS_CMD_ATTR_TGID)
> > +
> > +
> >  /* NETLINK_GENERIC related info */
> >
> >  #define TASKSTATS_GENL_NAME"TASKSTATS"
> > diff --git a/kernel/taskstats.c b/kernel/taskstats.c
> > index a2802b6ff4bb..c0f9e2f2308b 100644
> > --- a/kernel/taskstats.c
> > +++ b/kernel/taskstats.c
> > @@ -21,6 +21,8 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> >
> >  /*
> >   * Maximum length of a cpumask that can be specified in
> > @@ -28,6 +30,10 @@
> >   */
> >  #define TASKSTATS_CPUMASK_MAXLEN   (100+6*NR_CPUS)
> >
> > +#ifdef CONFIG_PROC_FS
> > +#define PROC_TASKSTATS "taskstats"
> > +#endif
> > +
> >  static DEFINE_PER_CPU(__u32, taskstats_seqnum);
> >  static int family_registered;
> >  struct kmem_cache *taskstats_cache;
> > @@ -666,6 +672,60 @@ static struct genl_family family __ro_after_init = {
> > .n_ops  = ARRAY_SIZE(taskstats_ops),
> >  };
> >
> > +#ifdef CONFIG_PROC_FS
> > +static long taskstats_ioctl_pid_tgid(unsigned long arg, bool tgid)
> > +{
> > +   struct taskstats kstat;
> > +   struct taskstats *ustat = (struct taskstats *)arg;
> > +   u32 id;
> > +   unsigned long offset = offsetof(struct taskstats, ac_pid);
> > +   long ret;
> > +
> > +   /* userspace set monitored pid/tgid to the field "ac_pid" */
> > +   if (unlikely(copy_from_user(&id, (void *)(arg + offset), 
> > sizeof(u32
> > +   return -EFAULT;
> > +
> > +   if (tgid)
> > +   ret = fill_stats_for_tgid(id, &kstat);
> > +   else
> > +   ret = fill_stats_for_pid(id, &kstat);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   if (unlikely(copy_to_user(ustat, &kstat, sizeof(struct taskstats
> > +   return -EFAULT;
> > +
> > +   return 0;
> > +}
> > +
> > +static long taskstats_ioctl(struct file *file, unsigned int cmd, unsigned 
> > long arg)
> > +{
> > +   long ret;
> > +
> > +   switch (cmd) {
> > +   case TASKSTATS_IOC_ATTR_PID:
> > +   ret = taskstats_ioctl_pid_tgid(arg, false);
> > +   break;
> > +   case TASKSTATS_IOC_ATTR_TGID:
> > +   ret = taskstats_ioctl_pid_tgid(arg, true);
> > +   break;
> > +   default:
> > +   ret = -EINVAL;
> > +   break;
> > +   }
> > +
> > +   return ret;
> > +}
> > +
> > +static const struct proc_ops taskstats_proc_ops = {
> > +   .proc_ioctl = taskstats_ioctl,
> > +#ifdef CONFIG_COMPAT
> > +   .proc_compat_ioctl = taskstats_ioctl,
> > +#endif
> > +};
> > +#endif
> > +
> > +
> >  /* Needed early in initialization */
> >  void __init taskstats_init_early(void)
> >  {
> > @@ -682,9 +742,20 @@ static int __init taskstats_init(void)
> >  {
> > int rc;
> >
> > +#ifdef CONFIG_PROC_FS
> > +   if (!proc_create(PROC_TASKSTATS,  0, NULL, &taskstats_proc_ops)) {
> > +   pr_err("failed to create /proc/%s\n", PROC_TASKSTATS);
> > +   return -1;
> > +   }
> > +#endif
> > +
> > rc = genl_register_family(&family);
> > -   if (rc)
> > +   if (rc) {
> > +#ifdef CONFIG_PROC_FS
> > +   remove_proc_entry(PROC_TASKSTATS, NULL);
> > +#endif
> > return rc;
> > +   }
> >
> > family_registered = 1;
> > pr_info("registered taskstats version %d\n", 
> > TASKSTATS_GENL_VERSION);
> > --
> > 2.17.2
> >

[PATCH 4.4 01/31] ASoC: dapm: remove widget from dirty list on free

[Greg Kroah-Hartman]

From: Thomas Hebb 

commit 5c6679b5cb120f07652418524ab186ac47680b49 upstream.

A widget's "dirty" list_head, much like its "list" list_head, eventually
chains back to a list_head on the snd_soc_card itself. This means that
the list can stick around even after the widget (or all widgets) have
been freed. Currently, however, widgets that are in the dirty list when
freed remain there, corrupting the entire list and leading to memory
errors and undefined behavior when the list is next accessed or
modified.

I encountered this issue when a component failed to probe relatively
late in snd_soc_bind_card(), causing it to bail out and call
soc_cleanup_card_resources(), which eventually called
snd_soc_dapm_free() with widgets that were still dirty from when they'd
been added.

Fixes: db432b414e20 ("ASoC: Do DAPM power checks only for widgets changed since 
last run")
Cc: sta...@vger.kernel.org
Signed-off-by: Thomas Hebb 
Reviewed-by: Charles Keepax 
Link: 
https://lore.kernel.org/r/f8b5f031d50122bf1a9bfc9cae046badf4a7a31a.1607822410.git.tommyh...@gmail.com
Signed-off-by: Mark Brown 
Signed-off-by: Greg Kroah-Hartman 

---
 sound/soc/soc-dapm.c |1 +
 1 file changed, 1 insertion(+)

--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -2316,6 +2316,7 @@ void snd_soc_dapm_free_widget(struct snd
enum snd_soc_dapm_direction dir;
 
list_del(&w->list);
+   list_del(&w->dirty);
/*
 * remove source and sink paths associated to this widget.
 * While removing the path, remove reference to it from both

[PATCH 4.4 02/31] MIPS: Fix malformed NT_FILE and NT_SIGINFO in 32bit coredumps

[Greg Kroah-Hartman]

From: Al Viro 

commit 698222457465ce343443be81c5512edda86e5914 upstream.

Patches that introduced NT_FILE and NT_SIGINFO notes back in 2012
had taken care of native (fs/binfmt_elf.c) and compat (fs/compat_binfmt_elf.c)
coredumps; unfortunately, compat on mips (which does not go through the
usual compat_binfmt_elf.c) had not been noticed.

As the result, both N32 and O32 coredumps on 64bit mips kernels
have those sections malformed enough to confuse the living hell out of
all gdb and readelf versions (up to and including the tip of binutils-gdb.git).

Longer term solution is to make both O32 and N32 compat use the
regular compat_binfmt_elf.c, but that's too much for backports.  The minimal
solution is to do in arch/mips/kernel/binfmt_elf[on]32.c the same thing
those patches have done in fs/compat_binfmt_elf.c

Cc: sta...@kernel.org # v3.7+
Signed-off-by: Al Viro 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/binfmt_elfn32.c |7 +++
 arch/mips/kernel/binfmt_elfo32.c |7 +++
 2 files changed, 14 insertions(+)

--- a/arch/mips/kernel/binfmt_elfn32.c
+++ b/arch/mips/kernel/binfmt_elfn32.c
@@ -130,4 +130,11 @@ cputime_to_compat_timeval(const cputime_
value->tv_sec = jiffies / HZ;
 }
 
+/*
+ * Some data types as stored in coredump.
+ */
+#define user_long_t compat_long_t
+#define user_siginfo_t  compat_siginfo_t
+#define copy_siginfo_to_externalcopy_siginfo_to_external32
+
 #include "../../../fs/binfmt_elf.c"
--- a/arch/mips/kernel/binfmt_elfo32.c
+++ b/arch/mips/kernel/binfmt_elfo32.c
@@ -149,4 +149,11 @@ cputime_to_compat_timeval(const cputime_
value->tv_sec = jiffies / HZ;
 }
 
+/*
+ * Some data types as stored in coredump.
+ */
+#define user_long_t compat_long_t
+#define user_siginfo_t  compat_siginfo_t
+#define copy_siginfo_to_externalcopy_siginfo_to_external32
+
 #include "../../../fs/binfmt_elf.c"

Re: [PATCH v9 17/17] Documentation: PCI: Add userguide for PCI endpoint NTB function

[Kishon Vijay Abraham I]

Hi Bjorn,

On 20/01/21 12:04 am, Bjorn Helgaas wrote:
> On Mon, Jan 04, 2021 at 08:59:09PM +0530, Kishon Vijay Abraham I wrote:
>> Add documentation to help users use pci-epf-ntb function driver and
>> existing host side NTB infrastructure for NTB functionality.
>>
>> Signed-off-by: Kishon Vijay Abraham I 
>> Reviewed-by: Randy Dunlap 
>> ---
>>  Documentation/PCI/endpoint/index.rst |   1 +
>>  Documentation/PCI/endpoint/pci-ntb-howto.rst | 160 +++
>>  2 files changed, 161 insertions(+)
>>  create mode 100644 Documentation/PCI/endpoint/pci-ntb-howto.rst
>>
>> diff --git a/Documentation/PCI/endpoint/index.rst 
>> b/Documentation/PCI/endpoint/index.rst
>> index 9cb6e5f3c4d5..38ea1f604b6d 100644
>> --- a/Documentation/PCI/endpoint/index.rst
>> +++ b/Documentation/PCI/endpoint/index.rst
>> @@ -12,6 +12,7 @@ PCI Endpoint Framework
>> pci-test-function
>> pci-test-howto
>> pci-ntb-function
>> +   pci-ntb-howto
>>  
>> function/binding/pci-test
>> function/binding/pci-ntb
>> diff --git a/Documentation/PCI/endpoint/pci-ntb-howto.rst 
>> b/Documentation/PCI/endpoint/pci-ntb-howto.rst
>> new file mode 100644
>> index ..b6e1073c9a39
>> --- /dev/null
>> +++ b/Documentation/PCI/endpoint/pci-ntb-howto.rst
>> @@ -0,0 +1,160 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> +
>> +===
>> +PCI Non-Transparent Bridge (NTB) Endpoint Function (EPF) User Guide
>> +===
>> +
>> +:Author: Kishon Vijay Abraham I 
>> +
>> +This document is a guide to help users use pci-epf-ntb function driver
>> +and ntb_hw_epf host driver for NTB functionality. The list of steps to
>> +be followed in the host side and EP side is given below. For the hardware
>> +configuration and internals of NTB using configurable endpoints see
>> +Documentation/PCI/endpoint/pci-ntb-function.rst
>> +
>> +Endpoint Device
>> +===
>> +
>> +Endpoint Controller Devices
>> +---
>> +
>> +For implementing NTB functionality at least two endpoint controller devices
>> +are required.
>> +To find the list of endpoint controller devices in the system::
> 
> Is the above one paragraph or two?  Reflow or add blank line as
> appropriate.

I'll add blank line above.

Thanks
Kishon

[PATCH 4.4 07/31] arch/arc: add copy_user_page() to to fix build error on ARC

[Greg Kroah-Hartman]

From: Randy Dunlap 

[ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ]

fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.

Provide copy_user_page() in .

../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page'; 
did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration]

Reported-by: kernel test robot 
Signed-off-by: Randy Dunlap 
Cc: Vineet Gupta 
Cc: linux-snps-...@lists.infradead.org
Cc: Dan Williams 
#Acked-by: Vineet Gupta  # v1
Cc: Andrew Morton 
Cc: Matthew Wilcox 
Cc: Jan Kara 
Cc: linux-fsde...@vger.kernel.org
Cc: linux-nvd...@lists.01.org
#Reviewed-by: Ira Weiny  # v2
Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin 
---
 arch/arc/include/asm/page.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arc/include/asm/page.h b/arch/arc/include/asm/page.h
index 8f1145ed0046f..fd2c88ef2e2b8 100644
--- a/arch/arc/include/asm/page.h
+++ b/arch/arc/include/asm/page.h
@@ -17,6 +17,7 @@
 #define free_user_page(page, addr) free_page(addr)
 
 #define clear_page(paddr)  memset((paddr), 0, PAGE_SIZE)
+#define copy_user_page(to, from, vaddr, pg)copy_page(to, from)
 #define copy_page(to, from)memcpy((to), (from), PAGE_SIZE)
 
 struct vm_area_struct;
-- 
2.27.0

[PATCH 4.4 19/31] usb: ohci: Make distrust_firmware param default to false

[Greg Kroah-Hartman]

From: Hamish Martin 

commit c4005a8f65edc55fb1700dfc5c1c3dc58be80209 upstream.

The 'distrust_firmware' module parameter dates from 2004 and the USB
subsystem is a lot more mature and reliable now than it was then.
Alter the default to false now.

Suggested-by: Alan Stern 
Acked-by: Alan Stern 
Signed-off-by: Hamish Martin 
Link: 
https://lore.kernel.org/r/20200910212512.16670-2-hamish.mar...@alliedtelesis.co.nz
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/host/ohci-hcd.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -99,7 +99,7 @@ static void io_watchdog_func(unsigned lo
 
 
 /* Some boards misreport power switching/overcurrent */
-static bool distrust_firmware = 1;
+static bool distrust_firmware;
 module_param (distrust_firmware, bool, 0);
 MODULE_PARM_DESC (distrust_firmware,
"true to distrust firmware power/overcurrent setup");

[PATCH 4.4 25/31] rndis_host: set proper input size for OID_GEN_PHYSICAL_MEDIUM request

[Greg Kroah-Hartman]

From: Andrey Zhizhikin 

[ Upstream commit e56b3d94d939f52d46209b9e1b6700c5bfff3123 ]

MSFT ActiveSync implementation requires that the size of the response for
incoming query is to be provided in the request input length. Failure to
set the input size proper results in failed request transfer, where the
ActiveSync counterpart reports the NDIS_STATUS_INVALID_LENGTH (0xC0010014L)
error.

Set the input size for OID_GEN_PHYSICAL_MEDIUM query to the expected size
of the response in order for the ActiveSync to properly respond to the
request.

Fixes: 039ee17d1baa ("rndis_host: Add RNDIS physical medium checking into 
generic_rndis_bind()")
Signed-off-by: Andrey Zhizhikin 
Link: 
https://lore.kernel.org/r/20210108095839.3335-1-andrey.zhizhi...@leica-geosystems.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/usb/rndis_host.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/usb/rndis_host.c
+++ b/drivers/net/usb/rndis_host.c
@@ -398,7 +398,7 @@ generic_rndis_bind(struct usbnet *dev, s
reply_len = sizeof *phym;
retval = rndis_query(dev, intf, u.buf,
 RNDIS_OID_GEN_PHYSICAL_MEDIUM,
-0, (void **) &phym, &reply_len);
+reply_len, (void **)&phym, &reply_len);
if (retval != 0 || !phym) {
/* OID is optional so don't fail here. */
phym_unspec = cpu_to_le32(RNDIS_PHYSICAL_MEDIUM_UNSPECIFIED);

[PATCH 4.9 13/35] ACPI: scan: add stub acpi_create_platform_device() for !CONFIG_ACPI

[Greg Kroah-Hartman]

From: Shawn Guo 

[ Upstream commit ee61cfd955a64a58ed35cbcfc54068fcbd486945 ]

It adds a stub acpi_create_platform_device() for !CONFIG_ACPI build, so
that caller doesn't have to deal with !CONFIG_ACPI build issue.

Reported-by: kernel test robot 
Signed-off-by: Shawn Guo 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin 
---
 include/linux/acpi.h | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 5670bb9788bb4..192b045cc56ec 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -734,6 +734,13 @@ static inline int acpi_device_modalias(struct device *dev,
return -ENODEV;
 }
 
+static inline struct platform_device *
+acpi_create_platform_device(struct acpi_device *adev,
+   struct property_entry *properties)
+{
+   return NULL;
+}
+
 static inline bool acpi_dma_supported(struct acpi_device *adev)
 {
return false;
-- 
2.27.0

[PATCH 4.4 06/31] ethernet: ucc_geth: fix definition and size of ucc_geth_tx_global_pram

[Greg Kroah-Hartman]

From: Rasmus Villemoes 

[ Upstream commit 887078de2a23689e29d6fa1b75d7cbc544c280be ]

Table 8-53 in the QUICC Engine Reference manual shows definitions of
fields up to a size of 192 bytes, not just 128. But in table 8-111,
one does find the text

  Base Address of the Global Transmitter Parameter RAM Page. [...]
  The user needs to allocate 128 bytes for this page. The address must
  be aligned to the page size.

I've checked both rev. 7 (11/2015) and rev. 9 (05/2018) of the manual;
they both have this inconsistency (and the table numbers are the
same).

Adding a bit of debug printing, on my board the struct
ucc_geth_tx_global_pram is allocated at offset 0x880, while
the (opaque) ucc_geth_thread_data_tx gets allocated immediately
afterwards, at 0x900. So whatever the engine writes into the thread
data overlaps with the tail of the global tx pram (and devmem says
that something does get written during a simple ping).

I haven't observed any failure that could be attributed to this, but
it seems to be the kind of thing that would be extremely hard to
debug. So extend the struct definition so that we do allocate 192
bytes.

Signed-off-by: Rasmus Villemoes 
Signed-off-by: Jakub Kicinski 
Signed-off-by: Sasha Levin 
---
 drivers/net/ethernet/freescale/ucc_geth.h | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/ucc_geth.h 
b/drivers/net/ethernet/freescale/ucc_geth.h
index 75f337163ce3c..1a40a5f11081b 100644
--- a/drivers/net/ethernet/freescale/ucc_geth.h
+++ b/drivers/net/ethernet/freescale/ucc_geth.h
@@ -580,7 +580,14 @@ struct ucc_geth_tx_global_pram {
u32 vtagtable[0x8]; /* 8 4-byte VLAN tags */
u32 tqptr;  /* a base pointer to the Tx Queues Memory
   Region */
-   u8 res2[0x80 - 0x74];
+   u8 res2[0x78 - 0x74];
+   u64 snums_en;
+   u32 l2l3baseptr;/* top byte consists of a few other bit fields 
*/
+
+   u16 mtu[8];
+   u8 res3[0xa8 - 0x94];
+   u32 wrrtablebase;   /* top byte is reserved */
+   u8 res4[0xc0 - 0xac];
 } __packed;
 
 /* structure representing Extended Filtering Global Parameters in PRAM */
-- 
2.27.0

[PATCH 4.9 02/35] MIPS: boot: Fix unaligned access with CONFIG_MIPS_RAW_APPENDED_DTB

[Greg Kroah-Hartman]

From: Paul Cercueil 

commit 4d4f9c1a17a3480f8fe523673f7232b254d724b7 upstream.

The compressed payload is not necesarily 4-byte aligned, at least when
compiling with Clang. In that case, the 4-byte value appended to the
compressed payload that corresponds to the uncompressed kernel image
size must be read using get_unaligned_le32().

This fixes Clang-built kernels not booting on MIPS (tested on a Ingenic
JZ4770 board).

Fixes: b8f54f2cde78 ("MIPS: ZBOOT: copy appended dtb to the end of the kernel")
Cc:  # v4.7
Signed-off-by: Paul Cercueil 
Reviewed-by: Nick Desaulniers 
Reviewed-by: Philippe Mathieu-Daudé 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/boot/compressed/decompress.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/arch/mips/boot/compressed/decompress.c
+++ b/arch/mips/boot/compressed/decompress.c
@@ -17,6 +17,7 @@
 #include 
 
 #include 
+#include 
 
 /*
  * These two variables specify the free mem region
@@ -124,7 +125,7 @@ void decompress_kernel(unsigned long boo
dtb_size = fdt_totalsize((void *)&__appended_dtb);
 
/* last four bytes is always image size in little endian */
-   image_size = le32_to_cpup((void *)&__image_end - 4);
+   image_size = get_unaligned_le32((void *)&__image_end - 4);
 
/* copy dtb to where the booted kernel will expect it */
memcpy((void *)VMLINUX_LOAD_ADDRESS_ULL + image_size,

[PATCH 4.9 15/35] Input: uinput - avoid FF flush when destroying device

[Greg Kroah-Hartman]

From: Dmitry Torokhov 

commit e8b95728f724797f958912fd9b765a695595d3a6 upstream.

Normally, when input device supporting force feedback effects is being
destroyed, we try to "flush" currently playing effects, so that the
physical device does not continue vibrating (or executing other effects).
Unfortunately this does not work well for uinput as flushing of the effects
deadlocks with the destroy action:

- if device is being destroyed because the file descriptor is being closed,
  then there is noone to even service FF requests;

- if device is being destroyed because userspace sent UI_DEV_DESTROY,
  while theoretically it could be possible to service FF requests,
  userspace is unlikely to do so (they'd need to make sure FF handling
  happens on a separate thread) even if kernel solves the issue with FF
  ioctls deadlocking with UI_DEV_DESTROY ioctl on udev->mutex.

To avoid lockups like the one below, let's install a custom input device
flush handler, and avoid trying to flush force feedback effects when we
destroying the device, and instead rely on uinput to shut off the device
properly.

NMI watchdog: Watchdog detected hard LOCKUP on cpu 3
...
 <>  [] _raw_spin_lock_irqsave+0x37/0x40
 [] complete+0x1d/0x50
 [] uinput_request_done+0x3c/0x40 [uinput]
 [] uinput_request_submit.part.7+0x47/0xb0 [uinput]
 [] uinput_dev_erase_effect+0x5b/0x76 [uinput]
 [] erase_effect+0xad/0xf0
 [] flush_effects+0x4d/0x90
 [] input_flush_device+0x40/0x60
 [] evdev_cleanup+0xac/0xc0
 [] evdev_disconnect+0x2b/0x60
 [] __input_unregister_device+0xac/0x150
 [] input_unregister_device+0x47/0x70
 [] uinput_destroy_device+0xb5/0xc0 [uinput]
 [] uinput_ioctl_handler.isra.9+0x65e/0x740 [uinput]
 [] ? do_futex+0x12b/0xad0
 [] uinput_ioctl+0x18/0x20 [uinput]
 [] do_vfs_ioctl+0x298/0x480
 [] ? security_file_ioctl+0x43/0x60
 [] SyS_ioctl+0x79/0x90
 [] entry_SYSCALL_64_fastpath+0x12/0x71

Reported-by: Rodrigo Rivas Costa 
Reported-by: Clément VUCHENER 
Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=193741
Signed-off-by: Dmitry Torokhov 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/input/ff-core.c |   13 ++---
 drivers/input/misc/uinput.c |   18 ++
 include/linux/input.h   |1 +
 3 files changed, 29 insertions(+), 3 deletions(-)

--- a/drivers/input/ff-core.c
+++ b/drivers/input/ff-core.c
@@ -237,9 +237,15 @@ int input_ff_erase(struct input_dev *dev
 EXPORT_SYMBOL_GPL(input_ff_erase);
 
 /*
- * flush_effects - erase all effects owned by a file handle
+ * input_ff_flush - erase all effects owned by a file handle
+ * @dev: input device to erase effect from
+ * @file: purported owner of the effects
+ *
+ * This function erases all force-feedback effects associated with
+ * the given owner from specified device. Note that @file may be %NULL,
+ * in which case all effects will be erased.
  */
-static int flush_effects(struct input_dev *dev, struct file *file)
+int input_ff_flush(struct input_dev *dev, struct file *file)
 {
struct ff_device *ff = dev->ff;
int i;
@@ -255,6 +261,7 @@ static int flush_effects(struct input_de
 
return 0;
 }
+EXPORT_SYMBOL_GPL(input_ff_flush);
 
 /**
  * input_ff_event() - generic handler for force-feedback events
@@ -343,7 +350,7 @@ int input_ff_create(struct input_dev *de
mutex_init(&ff->mutex);
 
dev->ff = ff;
-   dev->flush = flush_effects;
+   dev->flush = input_ff_flush;
dev->event = input_ff_event;
__set_bit(EV_FF, dev->evbit);
 
--- a/drivers/input/misc/uinput.c
+++ b/drivers/input/misc/uinput.c
@@ -231,6 +231,18 @@ static int uinput_dev_erase_effect(struc
return uinput_request_submit(udev, &request);
 }
 
+static int uinput_dev_flush(struct input_dev *dev, struct file *file)
+{
+   /*
+* If we are called with file == NULL that means we are tearing
+* down the device, and therefore we can not handle FF erase
+* requests: either we are handling UI_DEV_DESTROY (and holding
+* the udev->mutex), or the file descriptor is closed and there is
+* nobody on the other side anymore.
+*/
+   return file ? input_ff_flush(dev, file) : 0;
+}
+
 static void uinput_destroy_device(struct uinput_device *udev)
 {
const char *name, *phys;
@@ -298,6 +310,12 @@ static int uinput_create_device(struct u
dev->ff->playback = uinput_dev_playback;
dev->ff->set_gain = uinput_dev_set_gain;
dev->ff->set_autocenter = uinput_dev_set_autocenter;
+   /*
+* The standard input_ff_flush() implementation does
+* not quite work for uinput as we can't reasonably
+* handle FF requests during device teardown.
+*/
+   dev->flush = uinput_dev_flush;
}
 
error = input_register_device(udev->dev);
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -529,6 +529,7 @@ int input_ff_event(struct input_dev *dev
 
 int input_ff_upl

[PATCH 4.9 34/35] tipc: fix NULL deref in tipc_link_xmit()

[Greg Kroah-Hartman]

From: Hoang Le 

[ Upstream commit b77413446408fdd256599daf00d5be72b5f3e7c6 ]

The buffer list can have zero skb as following path:
tipc_named_node_up()->tipc_node_xmit()->tipc_link_xmit(), so
we need to check the list before casting an &sk_buff.

Fault report:
 [] tipc: Bulk publication failure
 [] general protection fault, probably for non-canonical [#1] PREEMPT [...]
 [] KASAN: null-ptr-deref in range [0x00c8-0x00cf]
 [] CPU: 0 PID: 0 Comm: swapper/0 Kdump: loaded Not tainted 5.10.0-rc4+ #2
 [] Hardware name: Bochs ..., BIOS Bochs 01/01/2011
 [] RIP: 0010:tipc_link_xmit+0xc1/0x2180
 [] Code: 24 b8 00 00 00 00 4d 39 ec 4c 0f 44 e8 e8 d7 0a 10 f9 48 [...]
 [] RSP: 0018:c9006ea0 EFLAGS: 00010202
 [] RAX: dc00 RBX: 8880224da000 RCX: 111003d3cc0d
 [] RDX: 0019 RSI: 886007b9 RDI: 00c8
 [] RBP: c9007018 R08: 0001 R09: f5200ded
 [] R10: 0003 R11: f5200dec R12: c9007148
 [] R13:  R14:  R15: c9007018
 [] FS:  () GS:88803740() knlGS:000[...]
 [] CS:  0010 DS:  ES:  CR0: 80050033
 [] CR2: 7fffd2db5000 CR3: 2b08f000 CR4: 06f0

Fixes: af9b028e270fd ("tipc: make media xmit call outside node spinlock 
context")
Acked-by: Jon Maloy 
Signed-off-by: Hoang Le 
Link: https://lore.kernel.org/r/20210108071337.3598-1-hoang.h...@dektech.com.au
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 net/tipc/link.c |   11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

--- a/net/tipc/link.c
+++ b/net/tipc/link.c
@@ -877,9 +877,8 @@ void tipc_link_reset(struct tipc_link *l
 int tipc_link_xmit(struct tipc_link *l, struct sk_buff_head *list,
   struct sk_buff_head *xmitq)
 {
-   struct tipc_msg *hdr = buf_msg(skb_peek(list));
unsigned int maxwin = l->window;
-   unsigned int i, imp = msg_importance(hdr);
+   unsigned int i;
unsigned int mtu = l->mtu;
u16 ack = l->rcv_nxt - 1;
u16 seqno = l->snd_nxt;
@@ -888,7 +887,13 @@ int tipc_link_xmit(struct tipc_link *l,
struct sk_buff_head *backlogq = &l->backlogq;
struct sk_buff *skb, *_skb, *bskb;
int pkt_cnt = skb_queue_len(list);
+   struct tipc_msg *hdr;
+   int imp;
 
+   if (pkt_cnt <= 0)
+   return 0;
+
+   imp = msg_importance(hdr);
/* Match msg importance against this and all higher backlog limits: */
if (!skb_queue_empty(backlogq)) {
for (i = imp; i <= TIPC_SYSTEM_IMPORTANCE; i++) {
@@ -896,6 +901,8 @@ int tipc_link_xmit(struct tipc_link *l,
return link_schedule_user(l, list);
}
}
+
+   hdr = buf_msg(skb_peek(list));
if (unlikely(msg_size(hdr) > mtu)) {
skb_queue_purge(list);
return -EMSGSIZE;

[PATCH 4.9 10/35] arch/arc: add copy_user_page() to to fix build error on ARC

[Greg Kroah-Hartman]

From: Randy Dunlap 

[ Upstream commit 8a48c0a3360bf2bf4f40c980d0ec216e770e58ee ]

fs/dax.c uses copy_user_page() but ARC does not provide that interface,
resulting in a build error.

Provide copy_user_page() in .

../fs/dax.c: In function 'copy_cow_page_dax':
../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page'; 
did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration]

Reported-by: kernel test robot 
Signed-off-by: Randy Dunlap 
Cc: Vineet Gupta 
Cc: linux-snps-...@lists.infradead.org
Cc: Dan Williams 
#Acked-by: Vineet Gupta  # v1
Cc: Andrew Morton 
Cc: Matthew Wilcox 
Cc: Jan Kara 
Cc: linux-fsde...@vger.kernel.org
Cc: linux-nvd...@lists.01.org
#Reviewed-by: Ira Weiny  # v2
Signed-off-by: Vineet Gupta 
Signed-off-by: Sasha Levin 
---
 arch/arc/include/asm/page.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arc/include/asm/page.h b/arch/arc/include/asm/page.h
index ffb5f33475f19..f0f43eb709d2f 100644
--- a/arch/arc/include/asm/page.h
+++ b/arch/arc/include/asm/page.h
@@ -13,6 +13,7 @@
 #ifndef __ASSEMBLY__
 
 #define clear_page(paddr)  memset((paddr), 0, PAGE_SIZE)
+#define copy_user_page(to, from, vaddr, pg)copy_page(to, from)
 #define copy_page(to, from)memcpy((to), (from), PAGE_SIZE)
 
 struct vm_area_struct;
-- 
2.27.0

[PATCH 4.9 19/35] RDMA/usnic: Fix memleak in find_free_vf_and_create_qp_grp

[Greg Kroah-Hartman]

From: Dinghao Liu 

commit a306aba9c8d869b1fdfc8ad9237f1ed718ea55e6 upstream.

If usnic_ib_qp_grp_create() fails at the first call, dev_list
will not be freed on error, which leads to memleak.

Fixes: e3cf00d0a87f ("IB/usnic: Add Cisco VIC low-level hardware driver")
Link: https://lore.kernel.org/r/20201226074248.2893-1-dinghao@zju.edu.cn
Signed-off-by: Dinghao Liu 
Reviewed-by: Leon Romanovsky 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/infiniband/hw/usnic/usnic_ib_verbs.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/infiniband/hw/usnic/usnic_ib_verbs.c
+++ b/drivers/infiniband/hw/usnic/usnic_ib_verbs.c
@@ -180,6 +180,7 @@ find_free_vf_and_create_qp_grp(struct us
 
}
usnic_uiom_free_dev_list(dev_list);
+   dev_list = NULL;
}
 
if (!found) {
@@ -207,6 +208,8 @@ find_free_vf_and_create_qp_grp(struct us
spin_unlock(&vf->lock);
if (IS_ERR_OR_NULL(qp_grp)) {
usnic_err("Failed to allocate qp_grp\n");
+   if (usnic_ib_share_vf)
+   usnic_uiom_free_dev_list(dev_list);
return ERR_PTR(qp_grp ? PTR_ERR(qp_grp) : -ENOMEM);
}
 

[PATCH 4.9 16/35] dump_common_audit_data(): fix racy accesses to ->d_name

[Greg Kroah-Hartman]

From: Al Viro 

commit d36a1dd9f77ae1e72da48f4123ed35627848507d upstream.

We are not guaranteed the locking environment that would prevent
dentry getting renamed right under us.  And it's possible for
old long name to be freed after rename, leading to UAF here.

Cc: sta...@kernel.org # v2.6.2+
Signed-off-by: Al Viro 
Signed-off-by: Greg Kroah-Hartman 

---
 security/lsm_audit.c |7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

--- a/security/lsm_audit.c
+++ b/security/lsm_audit.c
@@ -277,7 +277,9 @@ static void dump_common_audit_data(struc
struct inode *inode;
 
audit_log_format(ab, " name=");
+   spin_lock(&a->u.dentry->d_lock);
audit_log_untrustedstring(ab, a->u.dentry->d_name.name);
+   spin_unlock(&a->u.dentry->d_lock);
 
inode = d_backing_inode(a->u.dentry);
if (inode) {
@@ -295,8 +297,9 @@ static void dump_common_audit_data(struc
dentry = d_find_alias(inode);
if (dentry) {
audit_log_format(ab, " name=");
-   audit_log_untrustedstring(ab,
-dentry->d_name.name);
+   spin_lock(&dentry->d_lock);
+   audit_log_untrustedstring(ab, dentry->d_name.name);
+   spin_unlock(&dentry->d_lock);
dput(dentry);
}
audit_log_format(ab, " dev=");

[PATCH 4.9 25/35] nfsd4: readdirplus shouldnt return parent of export

[Greg Kroah-Hartman]

From: J. Bruce Fields 

commit 51b2ee7d006a736a9126e8111d1f24e4fd0afaa6 upstream.

If you export a subdirectory of a filesystem, a READDIRPLUS on the root
of that export will return the filehandle of the parent with the ".."
entry.

The filehandle is optional, so let's just not return the filehandle for
".." if we're at the root of an export.

Note that once the client learns one filehandle outside of the export,
they can trivially access the rest of the export using further lookups.

However, it is also not very difficult to guess filehandles outside of
the export.  So exporting a subdirectory of a filesystem should
considered equivalent to providing access to the entire filesystem.  To
avoid confusion, we recommend only exporting entire filesystems.

Reported-by: Youjipeng 
Signed-off-by: J. Bruce Fields 
Cc: sta...@vger.kernel.org
Signed-off-by: Chuck Lever 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nfsd/nfs3xdr.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/fs/nfsd/nfs3xdr.c
+++ b/fs/nfsd/nfs3xdr.c
@@ -822,9 +822,14 @@ compose_entry_fh(struct nfsd3_readdirres
if (isdotent(name, namlen)) {
if (namlen == 2) {
dchild = dget_parent(dparent);
-   /* filesystem root - cannot return filehandle for ".." 
*/
+   /*
+* Don't return filehandle for ".." if we're at
+* the filesystem or export root:
+*/
if (dchild == dparent)
goto out;
+   if (dparent == exp->ex_path.dentry)
+   goto out;
} else
dchild = dget(dparent);
} else

[PATCH 4.14 24/50] NFS: nfs_igrab_and_active must first reference the superblock

[Greg Kroah-Hartman]

From: Trond Myklebust 

commit 896567ee7f17a8a736cda8a28cc987228410a2ac upstream.

Before referencing the inode, we must ensure that the superblock can be
referenced. Otherwise, we can end up with iput() calling superblock
operations that are no longer valid or accessible.

Fixes: ea7c38fef0b7 ("NFSv4: Ensure we reference the inode for return-on-close 
in delegreturn")
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nfs/internal.h |   12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

--- a/fs/nfs/internal.h
+++ b/fs/nfs/internal.h
@@ -575,12 +575,14 @@ extern int nfs4_test_session_trunk(struc
 
 static inline struct inode *nfs_igrab_and_active(struct inode *inode)
 {
-   inode = igrab(inode);
-   if (inode != NULL && !nfs_sb_active(inode->i_sb)) {
-   iput(inode);
-   inode = NULL;
+   struct super_block *sb = inode->i_sb;
+
+   if (sb && nfs_sb_active(sb)) {
+   if (igrab(inode))
+   return inode;
+   nfs_sb_deactive(sb);
}
-   return inode;
+   return NULL;
 }
 
 static inline void nfs_iput_and_deactive(struct inode *inode)

[PATCH 4.14 09/50] ext4: fix bug for rename with RENAME_WHITEOUT

[Greg Kroah-Hartman]

From: yangerkun 

[ Upstream commit 6b4b8e6b4ad8553660421d6360678b3811d5deb9 ]

We got a "deleted inode referenced" warning cross our fsstress test. The
bug can be reproduced easily with following steps:

  cd /dev/shm
  mkdir test/
  fallocate -l 128M img
  mkfs.ext4 -b 1024 img
  mount img test/
  dd if=/dev/zero of=test/foo bs=1M count=128
  mkdir test/dir/ && cd test/dir/
  for ((i=0;i<1000;i++)); do touch file$i; done # consume all block
  cd ~ && renameat2(AT_FDCWD, /dev/shm/test/dir/file1, AT_FDCWD,
/dev/shm/test/dir/dst_file, RENAME_WHITEOUT) # ext4_add_entry in
ext4_rename will return ENOSPC!!
  cd /dev/shm/ && umount test/ && mount img test/ && ls -li test/dir/file1
  We will get the output:
  "ls: cannot access 'test/dir/file1': Structure needs cleaning"
  and the dmesg show:
  "EXT4-fs error (device loop0): ext4_lookup:1626: inode #2049: comm ls:
  deleted inode referenced: 139"

ext4_rename will create a special inode for whiteout and use this 'ino'
to replace the source file's dir entry 'ino'. Once error happens
latter(the error above was the ENOSPC return from ext4_add_entry in
ext4_rename since all space has been consumed), the cleanup do drop the
nlink for whiteout, but forget to restore 'ino' with source file. This
will trigger the bug describle as above.

Signed-off-by: yangerkun 
Reviewed-by: Jan Kara 
Cc: sta...@vger.kernel.org
Fixes: cd808deced43 ("ext4: support RENAME_WHITEOUT")
Link: https://lore.kernel.org/r/20210105062857.3566-1-yanger...@huawei.com
Signed-off-by: Theodore Ts'o 
Signed-off-by: Sasha Levin 
---
 fs/ext4/namei.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index 6936de30fcf0d..a4301fa4719ff 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -3442,8 +3442,6 @@ static int ext4_setent(handle_t *handle, struct 
ext4_renament *ent,
return retval;
}
}
-   brelse(ent->bh);
-   ent->bh = NULL;
 
return 0;
 }
@@ -3656,6 +3654,7 @@ static int ext4_rename(struct inode *old_dir, struct 
dentry *old_dentry,
}
}
 
+   old_file_type = old.de->file_type;
if (IS_DIRSYNC(old.dir) || IS_DIRSYNC(new.dir))
ext4_handle_sync(handle);
 
@@ -3683,7 +3682,6 @@ static int ext4_rename(struct inode *old_dir, struct 
dentry *old_dentry,
force_reread = (new.dir->i_ino == old.dir->i_ino &&
ext4_test_inode_flag(new.dir, EXT4_INODE_INLINE_DATA));
 
-   old_file_type = old.de->file_type;
if (whiteout) {
/*
 * Do this before adding a new entry, so the old entry is sure
@@ -3755,15 +3753,19 @@ static int ext4_rename(struct inode *old_dir, struct 
dentry *old_dentry,
retval = 0;
 
 end_rename:
-   brelse(old.dir_bh);
-   brelse(old.bh);
-   brelse(new.bh);
if (whiteout) {
-   if (retval)
+   if (retval) {
+   ext4_setent(handle, &old,
+   old.inode->i_ino, old_file_type);
drop_nlink(whiteout);
+   }
unlock_new_inode(whiteout);
iput(whiteout);
+
}
+   brelse(old.dir_bh);
+   brelse(old.bh);
+   brelse(new.bh);
if (handle)
ext4_journal_stop(handle);
return retval;
-- 
2.27.0

[PATCH 4.14 03/50] MIPS: Fix malformed NT_FILE and NT_SIGINFO in 32bit coredumps

[Greg Kroah-Hartman]

From: Al Viro 

commit 698222457465ce343443be81c5512edda86e5914 upstream.

Patches that introduced NT_FILE and NT_SIGINFO notes back in 2012
had taken care of native (fs/binfmt_elf.c) and compat (fs/compat_binfmt_elf.c)
coredumps; unfortunately, compat on mips (which does not go through the
usual compat_binfmt_elf.c) had not been noticed.

As the result, both N32 and O32 coredumps on 64bit mips kernels
have those sections malformed enough to confuse the living hell out of
all gdb and readelf versions (up to and including the tip of binutils-gdb.git).

Longer term solution is to make both O32 and N32 compat use the
regular compat_binfmt_elf.c, but that's too much for backports.  The minimal
solution is to do in arch/mips/kernel/binfmt_elf[on]32.c the same thing
those patches have done in fs/compat_binfmt_elf.c

Cc: sta...@kernel.org # v3.7+
Signed-off-by: Al Viro 
Signed-off-by: Thomas Bogendoerfer 
Signed-off-by: Greg Kroah-Hartman 

---
 arch/mips/kernel/binfmt_elfn32.c |7 +++
 arch/mips/kernel/binfmt_elfo32.c |7 +++
 2 files changed, 14 insertions(+)

--- a/arch/mips/kernel/binfmt_elfn32.c
+++ b/arch/mips/kernel/binfmt_elfn32.c
@@ -103,4 +103,11 @@ jiffies_to_compat_timeval(unsigned long
 #undef ns_to_timeval
 #define ns_to_timeval ns_to_compat_timeval
 
+/*
+ * Some data types as stored in coredump.
+ */
+#define user_long_t compat_long_t
+#define user_siginfo_t  compat_siginfo_t
+#define copy_siginfo_to_externalcopy_siginfo_to_external32
+
 #include "../../../fs/binfmt_elf.c"
--- a/arch/mips/kernel/binfmt_elfo32.c
+++ b/arch/mips/kernel/binfmt_elfo32.c
@@ -106,4 +106,11 @@ jiffies_to_compat_timeval(unsigned long
 #undef ns_to_timeval
 #define ns_to_timeval ns_to_compat_timeval
 
+/*
+ * Some data types as stored in coredump.
+ */
+#define user_long_t compat_long_t
+#define user_siginfo_t  compat_siginfo_t
+#define copy_siginfo_to_externalcopy_siginfo_to_external32
+
 #include "../../../fs/binfmt_elf.c"

[PATCH 4.14 07/50] dm snapshot: flush merged data before committing metadata

[Greg Kroah-Hartman]

From: Akilesh Kailash 

commit fcc42338375a1e67b8568dbb558f8b784d0f3b01 upstream.

If the origin device has a volatile write-back cache and the following
events occur:

1: After finishing merge operation of one set of exceptions,
   merge_callback() is invoked.
2: Update the metadata in COW device tracking the merge completion.
   This update to COW device is flushed cleanly.
3: System crashes and the origin device's cache where the recent
   merge was completed has not been flushed.

During the next cycle when we read the metadata from the COW device,
we will skip reading those metadata whose merge was completed in
step (1). This will lead to data loss/corruption.

To address this, flush the origin device post merge IO before
updating the metadata.

Cc: sta...@vger.kernel.org
Signed-off-by: Akilesh Kailash 
Signed-off-by: Mike Snitzer 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/md/dm-snap.c |   24 
 1 file changed, 24 insertions(+)

--- a/drivers/md/dm-snap.c
+++ b/drivers/md/dm-snap.c
@@ -137,6 +137,11 @@ struct dm_snapshot {
 * for them to be committed.
 */
struct bio_list bios_queued_during_merge;
+
+   /*
+* Flush data after merge.
+*/
+   struct bio flush_bio;
 };
 
 /*
@@ -1060,6 +1065,17 @@ shut:
 
 static void error_bios(struct bio *bio);
 
+static int flush_data(struct dm_snapshot *s)
+{
+   struct bio *flush_bio = &s->flush_bio;
+
+   bio_reset(flush_bio);
+   bio_set_dev(flush_bio, s->origin->bdev);
+   flush_bio->bi_opf = REQ_OP_WRITE | REQ_PREFLUSH;
+
+   return submit_bio_wait(flush_bio);
+}
+
 static void merge_callback(int read_err, unsigned long write_err, void 
*context)
 {
struct dm_snapshot *s = context;
@@ -1073,6 +1089,11 @@ static void merge_callback(int read_err,
goto shut;
}
 
+   if (flush_data(s) < 0) {
+   DMERR("Flush after merge failed: shutting down merge");
+   goto shut;
+   }
+
if (s->store->type->commit_merge(s->store,
 s->num_merging_chunks) < 0) {
DMERR("Write error in exception store: shutting down merge");
@@ -1197,6 +1218,7 @@ static int snapshot_ctr(struct dm_target
s->first_merging_chunk = 0;
s->num_merging_chunks = 0;
bio_list_init(&s->bios_queued_during_merge);
+   bio_init(&s->flush_bio, NULL, 0);
 
/* Allocate hash table for COW data */
if (init_hash_tables(s)) {
@@ -1391,6 +1413,8 @@ static void snapshot_dtr(struct dm_targe
 
mutex_destroy(&s->lock);
 
+   bio_uninit(&s->flush_bio);
+
dm_put_device(ti, s->cow);
 
dm_put_device(ti, s->origin);

[PATCH 4.14 43/50] net: avoid 32 x truesize under-estimation for tiny skbs

[Greg Kroah-Hartman]

From: Eric Dumazet 

[ Upstream commit 3226b158e67cfaa677fd180152bfb28989cb2fac ]

Both virtio net and napi_get_frags() allocate skbs
with a very small skb->head

While using page fragments instead of a kmalloc backed skb->head might give
a small performance improvement in some cases, there is a huge risk of
under estimating memory usage.

For both GOOD_COPY_LEN and GRO_MAX_HEAD, we can fit at least 32 allocations
per page (order-3 page in x86), or even 64 on PowerPC

We have been tracking OOM issues on GKE hosts hitting tcp_mem limits
but consuming far more memory for TCP buffers than instructed in tcp_mem[2]

Even if we force napi_alloc_skb() to only use order-0 pages, the issue
would still be there on arches with PAGE_SIZE >= 32768

This patch makes sure that small skb head are kmalloc backed, so that
other objects in the slab page can be reused instead of being held as long
as skbs are sitting in socket queues.

Note that we might in the future use the sk_buff napi cache,
instead of going through a more expensive __alloc_skb()

Another idea would be to use separate page sizes depending
on the allocated length (to never have more than 4 frags per page)

I would like to thank Greg Thelen for his precious help on this matter,
analysing crash dumps is always a time consuming task.

Fixes: fd11a83dd363 ("net: Pull out core bits of __netdev_alloc_skb and add 
__napi_alloc_skb")
Signed-off-by: Eric Dumazet 
Cc: Paolo Abeni 
Cc: Greg Thelen 
Reviewed-by: Alexander Duyck 
Acked-by: Michael S. Tsirkin 
Link: https://lore.kernel.org/r/20210113161819.1155526-1-eric.duma...@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 net/core/skbuff.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -459,13 +459,17 @@ EXPORT_SYMBOL(__netdev_alloc_skb);
 struct sk_buff *__napi_alloc_skb(struct napi_struct *napi, unsigned int len,
 gfp_t gfp_mask)
 {
-   struct napi_alloc_cache *nc = this_cpu_ptr(&napi_alloc_cache);
+   struct napi_alloc_cache *nc;
struct sk_buff *skb;
void *data;
 
len += NET_SKB_PAD + NET_IP_ALIGN;
 
-   if ((len > SKB_WITH_OVERHEAD(PAGE_SIZE)) ||
+   /* If requested length is either too small or too big,
+* we use kmalloc() for skb->head allocation.
+*/
+   if (len <= SKB_WITH_OVERHEAD(1024) ||
+   len > SKB_WITH_OVERHEAD(PAGE_SIZE) ||
(gfp_mask & (__GFP_DIRECT_RECLAIM | GFP_DMA))) {
skb = __alloc_skb(len, gfp_mask, SKB_ALLOC_RX, NUMA_NO_NODE);
if (!skb)
@@ -473,6 +477,7 @@ struct sk_buff *__napi_alloc_skb(struct
goto skb_success;
}
 
+   nc = this_cpu_ptr(&napi_alloc_cache);
len += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
len = SKB_DATA_ALIGN(len);
 

[PATCH 4.19 15/22] net: sit: unregister_netdevice on newlinks error path

[Greg Kroah-Hartman]

From: Jakub Kicinski 

[ Upstream commit 47e4bb147a96f1c9b4e7691e7e994e53838bfff8 ]

We need to unregister the netdevice if config failed.
.ndo_uninit takes care of most of the heavy lifting.

This was uncovered by recent commit c269a24ce057 ("net: make
free_netdev() more lenient with unregistering devices").
Previously the partially-initialized device would be left
in the system.

Reported-and-tested-by: syzbot+2393580080a2da190...@syzkaller.appspotmail.com
Fixes: e2f1f072db8d ("sit: allow to configure 6rd tunnels via netlink")
Acked-by: Nicolas Dichtel 
Link: https://lore.kernel.org/r/20210114012947.2515313-1-k...@kernel.org
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv6/sit.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1596,8 +1596,11 @@ static int ipip6_newlink(struct net *src
}
 
 #ifdef CONFIG_IPV6_SIT_6RD
-   if (ipip6_netlink_6rd_parms(data, &ip6rd))
+   if (ipip6_netlink_6rd_parms(data, &ip6rd)) {
err = ipip6_tunnel_update_6rd(nt, &ip6rd);
+   if (err < 0)
+   unregister_netdevice_queue(dev, NULL);
+   }
 #endif
 
return err;

[PATCH 4.19 16/22] net: avoid 32 x truesize under-estimation for tiny skbs

[Greg Kroah-Hartman]

From: Eric Dumazet 

[ Upstream commit 3226b158e67cfaa677fd180152bfb28989cb2fac ]

Both virtio net and napi_get_frags() allocate skbs
with a very small skb->head

While using page fragments instead of a kmalloc backed skb->head might give
a small performance improvement in some cases, there is a huge risk of
under estimating memory usage.

For both GOOD_COPY_LEN and GRO_MAX_HEAD, we can fit at least 32 allocations
per page (order-3 page in x86), or even 64 on PowerPC

We have been tracking OOM issues on GKE hosts hitting tcp_mem limits
but consuming far more memory for TCP buffers than instructed in tcp_mem[2]

Even if we force napi_alloc_skb() to only use order-0 pages, the issue
would still be there on arches with PAGE_SIZE >= 32768

This patch makes sure that small skb head are kmalloc backed, so that
other objects in the slab page can be reused instead of being held as long
as skbs are sitting in socket queues.

Note that we might in the future use the sk_buff napi cache,
instead of going through a more expensive __alloc_skb()

Another idea would be to use separate page sizes depending
on the allocated length (to never have more than 4 frags per page)

I would like to thank Greg Thelen for his precious help on this matter,
analysing crash dumps is always a time consuming task.

Fixes: fd11a83dd363 ("net: Pull out core bits of __netdev_alloc_skb and add 
__napi_alloc_skb")
Signed-off-by: Eric Dumazet 
Cc: Paolo Abeni 
Cc: Greg Thelen 
Reviewed-by: Alexander Duyck 
Acked-by: Michael S. Tsirkin 
Link: https://lore.kernel.org/r/20210113161819.1155526-1-eric.duma...@gmail.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 net/core/skbuff.c |9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -459,13 +459,17 @@ EXPORT_SYMBOL(__netdev_alloc_skb);
 struct sk_buff *__napi_alloc_skb(struct napi_struct *napi, unsigned int len,
 gfp_t gfp_mask)
 {
-   struct napi_alloc_cache *nc = this_cpu_ptr(&napi_alloc_cache);
+   struct napi_alloc_cache *nc;
struct sk_buff *skb;
void *data;
 
len += NET_SKB_PAD + NET_IP_ALIGN;
 
-   if ((len > SKB_WITH_OVERHEAD(PAGE_SIZE)) ||
+   /* If requested length is either too small or too big,
+* we use kmalloc() for skb->head allocation.
+*/
+   if (len <= SKB_WITH_OVERHEAD(1024) ||
+   len > SKB_WITH_OVERHEAD(PAGE_SIZE) ||
(gfp_mask & (__GFP_DIRECT_RECLAIM | GFP_DMA))) {
skb = __alloc_skb(len, gfp_mask, SKB_ALLOC_RX, NUMA_NO_NODE);
if (!skb)
@@ -473,6 +477,7 @@ struct sk_buff *__napi_alloc_skb(struct
goto skb_success;
}
 
+   nc = this_cpu_ptr(&napi_alloc_cache);
len += SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
len = SKB_DATA_ALIGN(len);
 

[PATCH 5.4 14/33] net: introduce skb_list_walk_safe for skb segment walking

[Greg Kroah-Hartman]

From: Jason A. Donenfeld 

commit dcfea72e79b0aa7a057c8f6024169d86a1bbc84b upstream.

As part of the continual effort to remove direct usage of skb->next and
skb->prev, this patch adds a helper for iterating through the
singly-linked variant of skb lists, which are used for lists of GSO
packet. The name "skb_list_..." has been chosen to match the existing
function, "kfree_skb_list, which also operates on these singly-linked
lists, and the "..._walk_safe" part is the same idiom as elsewhere in
the kernel.

This patch removes the helper from wireguard and puts it into
linux/skbuff.h, while making it a bit more robust for general usage. In
particular, parenthesis are added around the macro argument usage, and it
now accounts for trying to iterate through an already-null skb pointer,
which will simply run the iteration zero times. This latter enhancement
means it can be used to replace both do { ... } while and while (...)
open-coded idioms.

This should take care of these three possible usages, which match all
current methods of iterations.

skb_list_walk_safe(segs, skb, next) { ... }
skb_list_walk_safe(skb, skb, next) { ... }
skb_list_walk_safe(segs, skb, segs) { ... }

Gcc appears to generate efficient code for each of these.

Signed-off-by: Jason A. Donenfeld 
Signed-off-by: David S. Miller 
[ Just the skbuff.h changes for backporting - gregkh]
Signed-off-by: Greg Kroah-Hartman 
---
 include/linux/skbuff.h |5 +
 1 file changed, 5 insertions(+)

--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1480,6 +1480,11 @@ static inline void skb_mark_not_on_list(
skb->next = NULL;
 }
 
+/* Iterate through singly-linked GSO fragments of an skb. */
+#define skb_list_walk_safe(first, skb, next)   
\
+   for ((skb) = (first), (next) = (skb) ? (skb)->next : NULL; (skb);  \
+(skb) = (next), (next) = (skb) ? (skb)->next : NULL)
+
 static inline void skb_list_del_init(struct sk_buff *skb)
 {
__list_del_entry(&skb->list);

[PATCH 5.4 22/33] net: dcb: Validate netlink message in DCB handler

[Greg Kroah-Hartman]

From: Petr Machata 

[ Upstream commit 826f328e2b7e8854dd42ea44e6519cd75018e7b1 ]

DCB uses the same handler function for both RTM_GETDCB and RTM_SETDCB
messages. dcb_doit() bounces RTM_SETDCB mesasges if the user does not have
the CAP_NET_ADMIN capability.

However, the operation to be performed is not decided from the DCB message
type, but from the DCB command. Thus DCB_CMD_*_GET commands are used for
reading DCB objects, the corresponding SET and DEL commands are used for
manipulation.

The assumption is that set-like commands will be sent via an RTM_SETDCB
message, and get-like ones via RTM_GETDCB. However, this assumption is not
enforced.

It is therefore possible to manipulate DCB objects without CAP_NET_ADMIN
capability by sending the corresponding command in an RTM_GETDCB message.
That is a bug. Fix it by validating the type of the request message against
the type used for the response.

Fixes: 2f90b8657ec9 ("ixgbe: this patch adds support for DCB to the kernel and 
ixgbe driver")
Signed-off-by: Petr Machata 
Link: 
https://lore.kernel.org/r/a2a9b88418f3a58ef211b718f2970128ef9e3793.1608673640.git...@pmachata.org
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 net/dcb/dcbnl.c |2 ++
 1 file changed, 2 insertions(+)

--- a/net/dcb/dcbnl.c
+++ b/net/dcb/dcbnl.c
@@ -1765,6 +1765,8 @@ static int dcb_doit(struct sk_buff *skb,
fn = &reply_funcs[dcb->cmd];
if (!fn->cb)
return -EOPNOTSUPP;
+   if (fn->type != nlh->nlmsg_type)
+   return -EPERM;
 
if (!tb[DCB_ATTR_IFNAME])
return -EINVAL;

[PATCH 5.4 21/33] esp: avoid unneeded kmap_atomic call

[Greg Kroah-Hartman]

From: Willem de Bruijn 

[ Upstream commit 9bd6b629c39e3fa9e14243a6d8820492be1a5b2e ]

esp(6)_output_head uses skb_page_frag_refill to allocate a buffer for
the esp trailer.

It accesses the page with kmap_atomic to handle highmem. But
skb_page_frag_refill can return compound pages, of which
kmap_atomic only maps the first underlying page.

skb_page_frag_refill does not return highmem, because flag
__GFP_HIGHMEM is not set. ESP uses it in the same manner as TCP.
That also does not call kmap_atomic, but directly uses page_address,
in skb_copy_to_page_nocache. Do the same for ESP.

This issue has become easier to trigger with recent kmap local
debugging feature CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP.

Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible")
Fixes: 03e2a30f6a27 ("esp6: Avoid skb_cow_data whenever possible")
Signed-off-by: Willem de Bruijn 
Acked-by: Steffen Klassert 
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv4/esp4.c |7 +--
 net/ipv6/esp6.c |7 +--
 2 files changed, 2 insertions(+), 12 deletions(-)

--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -272,7 +272,6 @@ static int esp_output_udp_encap(struct x
 int esp_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info 
*esp)
 {
u8 *tail;
-   u8 *vaddr;
int nfrags;
int esph_offset;
struct page *page;
@@ -314,14 +313,10 @@ int esp_output_head(struct xfrm_state *x
page = pfrag->page;
get_page(page);
 
-   vaddr = kmap_atomic(page);
-
-   tail = vaddr + pfrag->offset;
+   tail = page_address(page) + pfrag->offset;
 
esp_output_fill_trailer(tail, esp->tfclen, esp->plen, 
esp->proto);
 
-   kunmap_atomic(vaddr);
-
nfrags = skb_shinfo(skb)->nr_frags;
 
__skb_fill_page_desc(skb, nfrags, page, pfrag->offset,
--- a/net/ipv6/esp6.c
+++ b/net/ipv6/esp6.c
@@ -226,7 +226,6 @@ static void esp_output_fill_trailer(u8 *
 int esp6_output_head(struct xfrm_state *x, struct sk_buff *skb, struct 
esp_info *esp)
 {
u8 *tail;
-   u8 *vaddr;
int nfrags;
struct page *page;
struct sk_buff *trailer;
@@ -259,14 +258,10 @@ int esp6_output_head(struct xfrm_state *
page = pfrag->page;
get_page(page);
 
-   vaddr = kmap_atomic(page);
-
-   tail = vaddr + pfrag->offset;
+   tail = page_address(page) + pfrag->offset;
 
esp_output_fill_trailer(tail, esp->tfclen, esp->plen, 
esp->proto);
 
-   kunmap_atomic(vaddr);
-
nfrags = skb_shinfo(skb)->nr_frags;
 
__skb_fill_page_desc(skb, nfrags, page, pfrag->offset,

[PATCH 5.4 23/33] net: dcb: Accept RTM_GETDCB messages carrying set-like DCB commands

[Greg Kroah-Hartman]

From: Petr Machata 

[ Upstream commit df85bc140a4d6cbaa78d8e9c35154e1a2f0622c7 ]

In commit 826f328e2b7e ("net: dcb: Validate netlink message in DCB
handler"), Linux started rejecting RTM_GETDCB netlink messages if they
contained a set-like DCB_CMD_ command.

The reason was that privileges were only verified for RTM_SETDCB messages,
but the value that determined the action to be taken is the command, not
the message type. And validation of message type against the DCB command
was the obvious missing piece.

Unfortunately it turns out that mlnx_qos, a somewhat widely deployed tool
for configuration of DCB, accesses the DCB set-like APIs through
RTM_GETDCB.

Therefore do not bounce the discrepancy between message type and command.
Instead, in addition to validating privileges based on the actual message
type, validate them also based on the expected message type. This closes
the loophole of allowing DCB configuration on non-admin accounts, while
maintaining backward compatibility.

Fixes: 2f90b8657ec9 ("ixgbe: this patch adds support for DCB to the kernel and 
ixgbe driver")
Fixes: 826f328e2b7e ("net: dcb: Validate netlink message in DCB handler")
Signed-off-by: Petr Machata 
Link: 
https://lore.kernel.org/r/a3edcfda0825f2aa2591801c5232f2bbf2d8a554.1610384801.git...@pmachata.org
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 net/dcb/dcbnl.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/dcb/dcbnl.c
+++ b/net/dcb/dcbnl.c
@@ -1765,7 +1765,7 @@ static int dcb_doit(struct sk_buff *skb,
fn = &reply_funcs[dcb->cmd];
if (!fn->cb)
return -EOPNOTSUPP;
-   if (fn->type != nlh->nlmsg_type)
+   if (fn->type == RTM_SETDCB && !netlink_capable(skb, CAP_NET_ADMIN))
return -EPERM;
 
if (!tb[DCB_ATTR_IFNAME])

[PATCH 5.10 10/43] bpf: Fix helper bpf_map_peek_elem_proto pointing to wrong callback

[Greg Kroah-Hartman]

From: Mircea Cirjaliu 

commit 301a33d51880619d0c5a581b5a48d3a5248fa84b upstream.

I assume this was obtained by copy/paste. Point it to bpf_map_peek_elem()
instead of bpf_map_pop_elem(). In practice it may have been less likely
hit when under JIT given shielded via 84430d4232c3 ("bpf, verifier: avoid
retpoline for map push/pop/peek operation").

Fixes: f1a2e44a3aec ("bpf: add queue and stack maps")
Signed-off-by: Mircea Cirjaliu 
Signed-off-by: Daniel Borkmann 
Cc: Mauricio Vasquez 
Link: 
https://lore.kernel.org/bpf/am7pr02mb6082663dfdcce8da7a6dd6b1bb...@am7pr02mb6082.eurprd02.prod.outlook.com
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/bpf/helpers.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/bpf/helpers.c
+++ b/kernel/bpf/helpers.c
@@ -108,7 +108,7 @@ BPF_CALL_2(bpf_map_peek_elem, struct bpf
 }
 
 const struct bpf_func_proto bpf_map_peek_elem_proto = {
-   .func   = bpf_map_pop_elem,
+   .func   = bpf_map_peek_elem,
.gpl_only   = false,
.ret_type   = RET_INTEGER,
.arg1_type  = ARG_CONST_MAP_PTR,

[PATCH 5.4 20/33] rndis_host: set proper input size for OID_GEN_PHYSICAL_MEDIUM request

[Greg Kroah-Hartman]

From: Andrey Zhizhikin 

[ Upstream commit e56b3d94d939f52d46209b9e1b6700c5bfff3123 ]

MSFT ActiveSync implementation requires that the size of the response for
incoming query is to be provided in the request input length. Failure to
set the input size proper results in failed request transfer, where the
ActiveSync counterpart reports the NDIS_STATUS_INVALID_LENGTH (0xC0010014L)
error.

Set the input size for OID_GEN_PHYSICAL_MEDIUM query to the expected size
of the response in order for the ActiveSync to properly respond to the
request.

Fixes: 039ee17d1baa ("rndis_host: Add RNDIS physical medium checking into 
generic_rndis_bind()")
Signed-off-by: Andrey Zhizhikin 
Link: 
https://lore.kernel.org/r/20210108095839.3335-1-andrey.zhizhi...@leica-geosystems.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/usb/rndis_host.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/usb/rndis_host.c
+++ b/drivers/net/usb/rndis_host.c
@@ -387,7 +387,7 @@ generic_rndis_bind(struct usbnet *dev, s
reply_len = sizeof *phym;
retval = rndis_query(dev, intf, u.buf,
 RNDIS_OID_GEN_PHYSICAL_MEDIUM,
-0, (void **) &phym, &reply_len);
+reply_len, (void **)&phym, &reply_len);
if (retval != 0 || !phym) {
/* OID is optional so don't fail here. */
phym_unspec = cpu_to_le32(RNDIS_PHYSICAL_MEDIUM_UNSPECIFIED);

[PATCH 5.10 02/43] bpf: Fix selftest compilation on clang 11

[Greg Kroah-Hartman]

From: Andrei Matei 

commit fb3558127cb62ba2dea9e3d0efa1bb1d7e5eee2a upstream.

Before this patch, profiler.inc.h wouldn't compile with clang-11 (before
the __builtin_preserve_enum_value LLVM builtin was introduced in
https://reviews.llvm.org/D83242).

Another test that uses this builtin (test_core_enumval) is conditionally
skipped if the compiler is too old. In that spirit, this patch inhibits
part of populate_cgroup_info(), which needs this CO-RE builtin. The
selftests build again on clang-11.

The affected test (the profiler test) doesn't pass on clang-11 because
it's missing https://reviews.llvm.org/D85570, but at least the test suite
as a whole compiles. The test's expected failure is already called out in
the README.

Signed-off-by: Andrei Matei 
Signed-off-by: Daniel Borkmann 
Tested-by: Florian Lehner 
Acked-by: Yonghong Song 
Link: https://lore.kernel.org/bpf/20201125035255.17970-1-andreimat...@gmail.com
Cc: Lorenz Bauer 
Signed-off-by: Greg Kroah-Hartman 

---
 tools/testing/selftests/bpf/progs/profiler.inc.h |2 ++
 1 file changed, 2 insertions(+)

--- a/tools/testing/selftests/bpf/progs/profiler.inc.h
+++ b/tools/testing/selftests/bpf/progs/profiler.inc.h
@@ -256,6 +256,7 @@ static INLINE void* populate_cgroup_info
BPF_CORE_READ(task, nsproxy, cgroup_ns, root_cset, dfl_cgrp, 
kn);
struct kernfs_node* proc_kernfs = BPF_CORE_READ(task, cgroups, 
dfl_cgrp, kn);
 
+#if __has_builtin(__builtin_preserve_enum_value)
if (ENABLE_CGROUP_V1_RESOLVER && CONFIG_CGROUP_PIDS) {
int cgrp_id = bpf_core_enum_value(enum cgroup_subsys_id___local,
  pids_cgrp_id___local);
@@ -275,6 +276,7 @@ static INLINE void* populate_cgroup_info
}
}
}
+#endif
 
cgroup_data->cgroup_root_inode = get_inode_from_kernfs(root_kernfs);
cgroup_data->cgroup_proc_inode = get_inode_from_kernfs(proc_kernfs);

[PATCH 5.10 15/43] net: ipv6: Validate GSO SKB before finish IPv6 processing

[Greg Kroah-Hartman]

From: Aya Levin 

[ Upstream commit b210de4f8c97d57de051e805686248ec4c6cfc52 ]

There are cases where GSO segment's length exceeds the egress MTU:
 - Forwarding of a TCP GRO skb, when DF flag is not set.
 - Forwarding of an skb that arrived on a virtualisation interface
   (virtio-net/vhost/tap) with TSO/GSO size set by other network
   stack.
 - Local GSO skb transmitted on an NETIF_F_TSO tunnel stacked over an
   interface with a smaller MTU.
 - Arriving GRO skb (or GSO skb in a virtualised environment) that is
   bridged to a NETIF_F_TSO tunnel stacked over an interface with an
   insufficient MTU.

If so:
 - Consume the SKB and its segments.
 - Issue an ICMP packet with 'Packet Too Big' message containing the
   MTU, allowing the source host to reduce its Path MTU appropriately.

Note: These cases are handled in the same manner in IPv4 output finish.
This patch aligns the behavior of IPv6 and the one of IPv4.

Fixes: 9e50849054a4 ("netfilter: ipv6: move POSTROUTING invocation before 
fragmentation")
Signed-off-by: Aya Levin 
Reviewed-by: Tariq Toukan 
Link: 
https://lore.kernel.org/r/1610027418-30438-1-git-send-email-a...@nvidia.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv6/ip6_output.c |   41 -
 1 file changed, 40 insertions(+), 1 deletion(-)

--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -125,8 +125,43 @@ static int ip6_finish_output2(struct net
return -EINVAL;
 }
 
+static int
+ip6_finish_output_gso_slowpath_drop(struct net *net, struct sock *sk,
+   struct sk_buff *skb, unsigned int mtu)
+{
+   struct sk_buff *segs, *nskb;
+   netdev_features_t features;
+   int ret = 0;
+
+   /* Please see corresponding comment in ip_finish_output_gso
+* describing the cases where GSO segment length exceeds the
+* egress MTU.
+*/
+   features = netif_skb_features(skb);
+   segs = skb_gso_segment(skb, features & ~NETIF_F_GSO_MASK);
+   if (IS_ERR_OR_NULL(segs)) {
+   kfree_skb(skb);
+   return -ENOMEM;
+   }
+
+   consume_skb(skb);
+
+   skb_list_walk_safe(segs, segs, nskb) {
+   int err;
+
+   skb_mark_not_on_list(segs);
+   err = ip6_fragment(net, sk, segs, ip6_finish_output2);
+   if (err && ret == 0)
+   ret = err;
+   }
+
+   return ret;
+}
+
 static int __ip6_finish_output(struct net *net, struct sock *sk, struct 
sk_buff *skb)
 {
+   unsigned int mtu;
+
 #if defined(CONFIG_NETFILTER) && defined(CONFIG_XFRM)
/* Policy lookup after SNAT yielded a new policy */
if (skb_dst(skb)->xfrm) {
@@ -135,7 +170,11 @@ static int __ip6_finish_output(struct ne
}
 #endif
 
-   if ((skb->len > ip6_skb_dst_mtu(skb) && !skb_is_gso(skb)) ||
+   mtu = ip6_skb_dst_mtu(skb);
+   if (skb_is_gso(skb) && !skb_gso_validate_network_len(skb, mtu))
+   return ip6_finish_output_gso_slowpath_drop(net, sk, skb, mtu);
+
+   if ((skb->len > mtu && !skb_is_gso(skb)) ||
dst_allfrag(skb_dst(skb)) ||
(IP6CB(skb)->frag_max_size && skb->len > IP6CB(skb)->frag_max_size))
return ip6_fragment(net, sk, skb, ip6_finish_output2);

[PATCH 5.10 28/43] net: stmmac: fix taprio schedule configuration

[Greg Kroah-Hartman]

From: Yannick Vignon 

[ Upstream commit b76889ff51bfee318bea15891420e5aefd2833a0 ]

When configuring a 802.1Qbv schedule through the tc taprio qdisc on an NXP
i.MX8MPlus device, the effective cycle time differed from the requested one
by N*96ns, with N number of entries in the Qbv Gate Control List. This is
because the driver was adding a 96ns margin to each interval of the GCL,
apparently to account for the IPG. The problem was observed on NXP
i.MX8MPlus devices but likely affected all devices relying on the same
configuration callback (dwmac 4.00, 4.10, 5.10 variants).

Fix the issue by removing the margins, and simply setup the MAC with the
provided cycle time value. This is the behavior expected by the user-space
API, as altering the Qbv schedule timings would break standards conformance.
This is also the behavior of several other Ethernet MAC implementations
supporting taprio, including the dwxgmac variant of stmmac.

Fixes: 504723af0d85 ("net: stmmac: Add basic EST support for GMAC5+")
Signed-off-by: Yannick Vignon 
Link: 
https://lore.kernel.org/r/20210113131557.24651-1-yannick.vig...@oss.nxp.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/stmicro/stmmac/dwmac5.c |   52 ++-
 1 file changed, 4 insertions(+), 48 deletions(-)

--- a/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac5.c
@@ -572,68 +572,24 @@ static int dwmac5_est_write(void __iomem
 int dwmac5_est_configure(void __iomem *ioaddr, struct stmmac_est *cfg,
 unsigned int ptp_rate)
 {
-   u32 speed, total_offset, offset, ctrl, ctr_low;
-   u32 extcfg = readl(ioaddr + GMAC_EXT_CONFIG);
-   u32 mac_cfg = readl(ioaddr + GMAC_CONFIG);
int i, ret = 0x0;
-   u64 total_ctr;
-
-   if (extcfg & GMAC_CONFIG_EIPG_EN) {
-   offset = (extcfg & GMAC_CONFIG_EIPG) >> GMAC_CONFIG_EIPG_SHIFT;
-   offset = 104 + (offset * 8);
-   } else {
-   offset = (mac_cfg & GMAC_CONFIG_IPG) >> GMAC_CONFIG_IPG_SHIFT;
-   offset = 96 - (offset * 8);
-   }
-
-   speed = mac_cfg & (GMAC_CONFIG_PS | GMAC_CONFIG_FES);
-   speed = speed >> GMAC_CONFIG_FES_SHIFT;
-
-   switch (speed) {
-   case 0x0:
-   offset = offset * 1000; /* 1G */
-   break;
-   case 0x1:
-   offset = offset * 400; /* 2.5G */
-   break;
-   case 0x2:
-   offset = offset * 10; /* 10M */
-   break;
-   case 0x3:
-   offset = offset * 1; /* 100M */
-   break;
-   default:
-   return -EINVAL;
-   }
-
-   offset = offset / 1000;
+   u32 ctrl;
 
ret |= dwmac5_est_write(ioaddr, BTR_LOW, cfg->btr[0], false);
ret |= dwmac5_est_write(ioaddr, BTR_HIGH, cfg->btr[1], false);
ret |= dwmac5_est_write(ioaddr, TER, cfg->ter, false);
ret |= dwmac5_est_write(ioaddr, LLR, cfg->gcl_size, false);
+   ret |= dwmac5_est_write(ioaddr, CTR_LOW, cfg->ctr[0], false);
+   ret |= dwmac5_est_write(ioaddr, CTR_HIGH, cfg->ctr[1], false);
if (ret)
return ret;
 
-   total_offset = 0;
for (i = 0; i < cfg->gcl_size; i++) {
-   ret = dwmac5_est_write(ioaddr, i, cfg->gcl[i] + offset, true);
+   ret = dwmac5_est_write(ioaddr, i, cfg->gcl[i], true);
if (ret)
return ret;
-
-   total_offset += offset;
}
 
-   total_ctr = cfg->ctr[0] + cfg->ctr[1] * 10ULL;
-   total_ctr += total_offset;
-
-   ctr_low = do_div(total_ctr, 10);
-
-   ret |= dwmac5_est_write(ioaddr, CTR_LOW, ctr_low, false);
-   ret |= dwmac5_est_write(ioaddr, CTR_HIGH, total_ctr, false);
-   if (ret)
-   return ret;
-
ctrl = readl(ioaddr + MTL_EST_CONTROL);
ctrl &= ~PTOV;
ctrl |= ((10 / ptp_rate) * 6) << PTOV_SHIFT;

[PATCH 5.10 27/43] net: sit: unregister_netdevice on newlinks error path

[Greg Kroah-Hartman]

From: Jakub Kicinski 

[ Upstream commit 47e4bb147a96f1c9b4e7691e7e994e53838bfff8 ]

We need to unregister the netdevice if config failed.
.ndo_uninit takes care of most of the heavy lifting.

This was uncovered by recent commit c269a24ce057 ("net: make
free_netdev() more lenient with unregistering devices").
Previously the partially-initialized device would be left
in the system.

Reported-and-tested-by: syzbot+2393580080a2da190...@syzkaller.appspotmail.com
Fixes: e2f1f072db8d ("sit: allow to configure 6rd tunnels via netlink")
Acked-by: Nicolas Dichtel 
Link: https://lore.kernel.org/r/20210114012947.2515313-1-k...@kernel.org
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 net/ipv6/sit.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -1645,8 +1645,11 @@ static int ipip6_newlink(struct net *src
}
 
 #ifdef CONFIG_IPV6_SIT_6RD
-   if (ipip6_netlink_6rd_parms(data, &ip6rd))
+   if (ipip6_netlink_6rd_parms(data, &ip6rd)) {
err = ipip6_tunnel_update_6rd(nt, &ip6rd);
+   if (err < 0)
+   unregister_netdevice_queue(dev, NULL);
+   }
 #endif
 
return err;

[PATCH 5.10 18/43] mlxsw: core: Increase critical threshold for ASIC thermal zone

[Greg Kroah-Hartman]

From: Vadim Pasternak 

[ Upstream commit b06ca3d5a43ca2dd806f7688a17e8e7e0619a80a ]

Increase critical threshold for ASIC thermal zone from 110C to 140C
according to the system hardware requirements. All the supported ASICs
(Spectrum-1, Spectrum-2, Spectrum-3) could be still operational with ASIC
temperature below 140C. With the old critical threshold value system
can perform unjustified shutdown.

All the systems equipped with the above ASICs implement thermal
protection mechanism at firmware level and firmware could decide to
perform system thermal shutdown in case the temperature is below 140C.
So with the new threshold system will not meltdown, while thermal
operating range will be aligned with hardware abilities.

Fixes: 41e760841d26 ("mlxsw: core: Replace thermal temperature trips with 
defines")
Fixes: a50c1e35650b ("mlxsw: core: Implement thermal zone")
Signed-off-by: Vadim Pasternak 
Reviewed-by: Jiri Pirko 
Signed-off-by: Ido Schimmel 
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/mellanox/mlxsw/core_thermal.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
@@ -19,7 +19,7 @@
 #define MLXSW_THERMAL_ASIC_TEMP_NORM   75000   /* 75C */
 #define MLXSW_THERMAL_ASIC_TEMP_HIGH   85000   /* 85C */
 #define MLXSW_THERMAL_ASIC_TEMP_HOT105000  /* 105C */
-#define MLXSW_THERMAL_ASIC_TEMP_CRIT   11  /* 110C */
+#define MLXSW_THERMAL_ASIC_TEMP_CRIT   14  /* 140C */
 #define MLXSW_THERMAL_HYSTERESIS_TEMP  5000/* 5C */
 #define MLXSW_THERMAL_MODULE_TEMP_SHIFT(MLXSW_THERMAL_HYSTERESIS_TEMP 
* 2)
 #define MLXSW_THERMAL_ZONE_MAX_NAME16

[PATCH 5.10 24/43] rxrpc: Call state should be read with READ_ONCE() under some circumstances

[Greg Kroah-Hartman]

From: Baptiste Lepers 

[ Upstream commit a95d25dd7b94a5ba18246da09b4218f132fed60e ]

The call state may be changed at any time by the data-ready routine in
response to received packets, so if the call state is to be read and acted
upon several times in a function, READ_ONCE() must be used unless the call
state lock is held.

As it happens, we used READ_ONCE() to read the state a few lines above the
unmarked read in rxrpc_input_data(), so use that value rather than
re-reading it.

Fixes: a158bdd3247b ("rxrpc: Fix call timeouts")
Signed-off-by: Baptiste Lepers 
Signed-off-by: David Howells 
Link: 
https://lore.kernel.org/r/161046715522.2450566.488819910256264150.st...@warthog.procyon.org.uk
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 net/rxrpc/input.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -430,7 +430,7 @@ static void rxrpc_input_data(struct rxrp
return;
}
 
-   if (call->state == RXRPC_CALL_SERVER_RECV_REQUEST) {
+   if (state == RXRPC_CALL_SERVER_RECV_REQUEST) {
unsigned long timo = READ_ONCE(call->next_req_timo);
unsigned long now, expect_req_by;
 

[PATCH 5.10 23/43] net: dcb: Accept RTM_GETDCB messages carrying set-like DCB commands

[Greg Kroah-Hartman]

From: Petr Machata 

[ Upstream commit df85bc140a4d6cbaa78d8e9c35154e1a2f0622c7 ]

In commit 826f328e2b7e ("net: dcb: Validate netlink message in DCB
handler"), Linux started rejecting RTM_GETDCB netlink messages if they
contained a set-like DCB_CMD_ command.

The reason was that privileges were only verified for RTM_SETDCB messages,
but the value that determined the action to be taken is the command, not
the message type. And validation of message type against the DCB command
was the obvious missing piece.

Unfortunately it turns out that mlnx_qos, a somewhat widely deployed tool
for configuration of DCB, accesses the DCB set-like APIs through
RTM_GETDCB.

Therefore do not bounce the discrepancy between message type and command.
Instead, in addition to validating privileges based on the actual message
type, validate them also based on the expected message type. This closes
the loophole of allowing DCB configuration on non-admin accounts, while
maintaining backward compatibility.

Fixes: 2f90b8657ec9 ("ixgbe: this patch adds support for DCB to the kernel and 
ixgbe driver")
Fixes: 826f328e2b7e ("net: dcb: Validate netlink message in DCB handler")
Signed-off-by: Petr Machata 
Link: 
https://lore.kernel.org/r/a3edcfda0825f2aa2591801c5232f2bbf2d8a554.1610384801.git...@pmachata.org
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 net/dcb/dcbnl.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/dcb/dcbnl.c
+++ b/net/dcb/dcbnl.c
@@ -1765,7 +1765,7 @@ static int dcb_doit(struct sk_buff *skb,
fn = &reply_funcs[dcb->cmd];
if (!fn->cb)
return -EOPNOTSUPP;
-   if (fn->type != nlh->nlmsg_type)
+   if (fn->type == RTM_SETDCB && !netlink_capable(skb, CAP_NET_ADMIN))
return -EPERM;
 
if (!tb[DCB_ATTR_IFNAME])

[PATCH 5.10 26/43] net: stmmac: Fixed mtu channged by cache aligned

[Greg Kroah-Hartman]

From: David Wu 

[ Upstream commit 5b55299eed78538cc4746e50ee97103a1643249c ]

Since the original mtu is not used when the mtu is updated,
the mtu is aligned with cache, this will get an incorrect.
For example, if you want to configure the mtu to be 1500,
but mtu 1536 is configured in fact.

Fixed: eaf4fac478077 ("net: stmmac: Do not accept invalid MTU values")
Signed-off-by: David Wu 
Link: https://lore.kernel.org/r/20210113034109.27865-1-david...@rock-chips.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3996,6 +3996,7 @@ static int stmmac_change_mtu(struct net_
 {
struct stmmac_priv *priv = netdev_priv(dev);
int txfifosz = priv->plat->tx_fifo_size;
+   const int mtu = new_mtu;
 
if (txfifosz == 0)
txfifosz = priv->dma_cap.tx_fifo_size;
@@ -4013,7 +4014,7 @@ static int stmmac_change_mtu(struct net_
if ((txfifosz < new_mtu) || (new_mtu > BUF_SIZE_16KiB))
return -EINVAL;
 
-   dev->mtu = new_mtu;
+   dev->mtu = mtu;
 
netdev_update_features(dev);
 

[PATCH 5.10 25/43] i40e: fix potential NULL pointer dereferencing

[Greg Kroah-Hartman]

From: Cristian Dumitrescu 

[ Upstream commit 7128c834d30e6b2cf649f14d8fc274941786d0e1 ]

Currently, the function i40e_construct_skb_zc only frees the input xdp
buffer when the output skb is successfully built. On error, the
function i40e_clean_rx_irq_zc does not commit anything for the current
packet descriptor and simply exits the packet descriptor processing
loop, with the plan to restart the processing of this descriptor on
the next invocation. Therefore, on error the ring next-to-clean
pointer should not advance, the xdp i.e. *bi buffer should not be
freed and the current buffer info should not be invalidated by setting
*bi to NULL. Therefore, the *bi should only be set to NULL when the
function i40e_construct_skb_zc is successful, otherwise a NULL *bi
will be dereferenced when the work for the current descriptor is
eventually restarted.

Fixes: 3b4f0b66c2b3 ("i40e, xsk: Migrate to new MEM_TYPE_XSK_BUFF_POOL")
Signed-off-by: Cristian Dumitrescu 
Acked-by: Björn Töpel 
Link: 
https://lore.kernel.org/r/2021081138.49757-1-cristian.dumitre...@intel.com
Signed-off-by: Jakub Kicinski 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/intel/i40e/i40e_xsk.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/net/ethernet/intel/i40e/i40e_xsk.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
@@ -348,12 +348,12 @@ int i40e_clean_rx_irq_zc(struct i40e_rin
 * SBP is *not* set in PRT_SBPVSI (default not set).
 */
skb = i40e_construct_skb_zc(rx_ring, *bi);
-   *bi = NULL;
if (!skb) {
rx_ring->rx_stats.alloc_buff_failed++;
break;
}
 
+   *bi = NULL;
cleaned_count++;
i40e_inc_ntc(rx_ring);