Re: [PATCH v2] mtd: spinand: add support for Foresee FS35ND01G-S1Y2

[Miquel Raynal]

Hi Daniel,

Daniel Palmer  wrote on Wed, 7 Apr 2021 21:01:01 +0900:

> Hi Miquel,
> 
> On Wed, 7 Apr 2021 at 17:02, Miquel Raynal  wrote:
> > You may look at micron_8_ecc_get_status() helper to guide you. But
> > IMHO, if there are 0-3 bf, you should probably assume there were 3 bf
> > and return 3, if there were 4, return 4, if it's uncorrectable return
> > -EBADMSG otherwise -EINVAL.  
> 
> Understood.
> 
> > We should verify that this does not mess with UBI wear leveling
> > though. Please check that returning 3-bit errors no matter the
> > actual number of flipped bits does not lead UBI to move the data away
> > (I think it's fine but we need to be sure otherwise the implementation
> > proposal is not valid).  
> 
> Ok. I'm not sure how to check that yet but I'll look into it.
> 

You can probably check the threshold in sysfs
(/sys/class/mtd/mtdX/*threshold*).

Thanks,
Miquèl

Re: [PATCH v2 07/17] KVM: x86/mmu: Check PDPTRs before allocating PAE roots

[Paolo Bonzini]

On 08/04/21 17:48, Sean Christopherson wrote:

Freaking PDPTRs.  I was really hoping we could keep the lock and 
pages_available()
logic outside of the helpers.  What if kvm_mmu_load() reads the PDPTRs and
passes them into mmu_alloc_shadow_roots()?  Or is that too ugly?


The patch I have posted (though untested) tries to do that in a slightly 
less ugly way by pushing make_mmu_pages_available down to mmu_alloc_*_roots.


Paolo


diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
index efb41f31e80a..e3c4938cd665 100644
--- a/arch/x86/kvm/mmu/mmu.c
+++ b/arch/x86/kvm/mmu/mmu.c
@@ -3275,11 +3275,11 @@ static int mmu_alloc_direct_roots(struct kvm_vcpu *vcpu)
 return 0;
  }

-static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu)
+static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu, u64 pdptrs[4])
  {
 struct kvm_mmu *mmu = vcpu->arch.mmu;
-   u64 pdptrs[4], pm_mask;
 gfn_t root_gfn, root_pgd;
+   u64 pm_mask;
 hpa_t root;
 int i;

@@ -3291,11 +3291,8 @@ static int mmu_alloc_shadow_roots(struct kvm_vcpu *vcpu)

 if (mmu->root_level == PT32E_ROOT_LEVEL) {
 for (i = 0; i < 4; ++i) {
-   pdptrs[i] = mmu->get_pdptr(vcpu, i);
-   if (!(pdptrs[i] & PT_PRESENT_MASK))
-   continue;
-
-   if (mmu_check_root(vcpu, pdptrs[i] >> PAGE_SHIFT))
+   if ((pdptrs[i] & PT_PRESENT_MASK) &&
+   mmu_check_root(vcpu, pdptrs[i] >> PAGE_SHIFT))
 return 1;
 }
 }
@@ -4844,21 +4841,33 @@ EXPORT_SYMBOL_GPL(kvm_mmu_reset_context);

  int kvm_mmu_load(struct kvm_vcpu *vcpu)
  {
-   int r;
+   struct kvm_mmu *mmu = vcpu->arch.mmu;
+   u64 pdptrs[4];
+   int r, i;

-   r = mmu_topup_memory_caches(vcpu, !vcpu->arch.mmu->direct_map);
+   r = mmu_topup_memory_caches(vcpu, !mmu->direct_map);
 if (r)
 goto out;
 r = mmu_alloc_special_roots(vcpu);
 if (r)
 goto out;
+
+   /*
+* On SVM, reading PDPTRs might access guest memory, which might fault
+* and thus might sleep.  Grab the PDPTRs before acquiring mmu_lock.
+*/
+   if (!mmu->direct_map && mmu->root_level == PT32E_ROOT_LEVEL) {
+   for (i = 0; i < 4; ++i)
+   pdptrs[i] = mmu->get_pdptr(vcpu, i);
+   }
+
 write_lock(>kvm->mmu_lock);
 if (make_mmu_pages_available(vcpu))
 r = -ENOSPC;
 else if (vcpu->arch.mmu->direct_map)
 r = mmu_alloc_direct_roots(vcpu);
 else
-   r = mmu_alloc_shadow_roots(vcpu);
+   r = mmu_alloc_shadow_roots(vcpu, pdptrs);
 write_unlock(>kvm->mmu_lock);
 if (r)
 goto out;

RE: [PATCH v3 1/2] PCI: xilinx-nwl: Enable coherent PCIe DMA traffic using CCI

[Bharat Kumar Gogada]

Thanks Lorenzo.

> -Original Message-
> From: Lorenzo Pieralisi 
> Sent: Wednesday, April 7, 2021 9:32 PM
> To: linux-...@vger.kernel.org; Bharat Kumar Gogada ;
> linux-kernel@vger.kernel.org
> Cc: lorenzo.pieral...@arm.com; bhelg...@google.com
> Subject: Re: [PATCH v3 1/2] PCI: xilinx-nwl: Enable coherent PCIe DMA traffic
> using CCI
> 
> On Mon, 22 Feb 2021 14:17:31 +0530, Bharat Kumar Gogada wrote:
> > Add support for routing PCIe DMA traffic coherently when Cache
> > Coherent Interconnect (CCI) is enabled in the system.
> > The "dma-coherent" property is used to determine if CCI is enabled or
> > not.
> > Refer to https://developer.arm.com/documentation/ddi0470/k/preface
> > for the CCI specification.
> 
> Applied to pci/xilinx, thanks!
> 
> [1/2] PCI: xilinx-nwl: Enable coherent PCIe DMA traffic using CCI
>   https://git.kernel.org/lpieralisi/pci/c/213e122052
> [2/2] PCI: xilinx-nwl: Add optional "dma-coherent" property
>   https://git.kernel.org/lpieralisi/pci/c/1c4422f226
> 
> Thanks,
> Lorenzo

Re: [RFC PATCH 5/5] tracing: Add the osnoise tracer

[Jonathan Corbet]

Daniel Bristot de Oliveira  writes:

A quick nit:

>  Documentation/trace/osnoise_tracer.rst |  149 ++
>  include/linux/ftrace_irq.h |   16 +
>  include/trace/events/osnoise.h |  141 ++
>  kernel/trace/Kconfig   |   34 +
>  kernel/trace/Makefile  |1 +
>  kernel/trace/trace.h   |9 +-
>  kernel/trace/trace_entries.h   |   27 +
>  kernel/trace/trace_osnoise.c   | 1714 
>  kernel/trace/trace_output.c|   72 +-
>  9 files changed, 2159 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/trace/osnoise_tracer.rst
>  create mode 100644 include/trace/events/osnoise.h
>  create mode 100644 kernel/trace/trace_osnoise.c

When you create a new RST file, you need to add it to an index.rst (or
similar) file so that it gets incorporated into the docs build.

The document itself looks good on a quick read.  If you're making
another pass over it, you might consider reducing the ``markup noise`` a
bit; we try to keep that to a minimum in the kernel docs.  But otherwise
thanks for writing it!

jon

Re: [PATCH v5 4/6] dt-bindings: PCI: Add SiFive FU740 PCIe host controller

[Rob Herring]

On Tue, 06 Apr 2021 17:26:32 +0800, Greentime Hu wrote:
> Add PCIe host controller DT bindings of SiFive FU740.
> 
> Signed-off-by: Greentime Hu 
> ---
>  .../bindings/pci/sifive,fu740-pcie.yaml   | 113 ++
>  1 file changed, 113 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml
> 

Reviewed-by: Rob Herring 

Re: [PATCH v2] platform/x86: add Gigabyte WMI temperature driver

[Hans de Goede]

Hi Guenter,

On 4/8/21 5:08 PM, Guenter Roeck wrote:
> On Mon, Apr 05, 2021 at 10:48:10PM +0200, Thomas Weißschuh wrote:
>> Changes since v1:
>> * Incorporate feedback from Barnabás Pőcze
>>   * Use a WMI driver instead of a platform driver
>>   * Let the kernel manage the driver lifecycle
>>   * Fix errno/ACPI error confusion
>>   * Fix resource cleanup
>>   * Document reason for integer casting
>>
>> Thank you Barnabás for your review, it is much appreciated.
>>
>> -- >8 --
>>
>> Tested with a X570 I Aorus Pro Wifi.
>> The mainboard contains an ITE IT8688E chip for management.
>> This chips is also handled by drivers/hwmon/i87.c but as it is also used
>> by the firmware itself it needs an ACPI driver.
>>
>> Unfortunately not all sensor registers are handled by the firmware and even
>> less are exposed via WMI.
>>
>> Signed-off-by: Thomas Weißschuh 
>> ---
>>  drivers/platform/x86/Kconfig|  11 +++
>>  drivers/platform/x86/Makefile   |   1 +
>>  drivers/platform/x86/gigabyte-wmi.c | 138 
> 
> Originally drivers/platform was supposed to be used for platform specific
> code. Not that I have control over it, but I really dislike that more and
> more hwmon drivers end up there.
> 
> At least hwmon is in good company - I see drivers for various other subsystems
> there as well. I just wonder if that is such a good idea. That entire 
> directory
> is bypassing subsystem maintainer reviews.

In case you are not aware I've recent(ish) taken over the drivers/platform/x86
maintainership from Andy Shevchenko.

Yes it is a bit of an odd grab-bag it mostly deals with vendor specific
ACPI / WMI interfaces which often more or less require using a single
driver while offering multiple functionalities. These firmware interfaces
do not really lend themselves to demultiplexing through something like
MFD. These are mostly found on laptops where they deal with some or all of:

- Hotkeys for brightness adjust / wlan-on/off toggle, touchpad on/off toggle, 
etc.
  (input subsystem stuff)
- Mic. / Speaker mute LEDS (and other special LEDs) found on some laptops
  (LED subsystem stuff)
- Enabling/disabling radios
  (rfkill stuff)
- Controlling the DPTF performance profile
  (ACPI stuff)
- Various sensors, some hwmon, some IIO
- Backlight control (drm/kms subsys)
- Enabling/disabling of LCD-builtin privacy filters (requires KMS/DRM subsys 
integration, pending)
- Fan control (hwmon subsys)

And often all of this in a single driver. This is all "stuff" for which
there are no standard APIs shared between vendors, so it is a free for
all and often it is all stuffed behind a single WMI or ACPI object,
because that is how the vendor's drivers under Windows work.

It certainly is not my intention to bypass review by other subsystem
maintainers and when there are significant questions I do try to always
get other subsys maintainers involved. See e.g. this thread, but also the
"[PATCH 1/3] thinkpad_acpi: add support for force_discharge" thread
where I asked for input from sre for the power-supply aspects of that.

The WMI code was reworked a while back to make WMI be a bus and have
individual WMI objects be devices on that bus. version 2 of this
driver has been reworked to use this. Since this new driver is just a hwmon
driver and as this is for a desktop I expect it will stay that way,
I'm fine with moving this one over to drivers/hwmon if that has your
preference.

As for other cases then this driver, if you want to make sure you are at
least Cc-ed on all hwmon related changes I'm fine with adding you as a
reviewer to the pdx86 MAINTAINERS entry.

Regards,

Hans




> 
> Guenter
> 
>>  3 files changed, 150 insertions(+)
>>  create mode 100644 drivers/platform/x86/gigabyte-wmi.c
>>
>> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
>> index ad4e630e73e2..96622a2106f7 100644
>> --- a/drivers/platform/x86/Kconfig
>> +++ b/drivers/platform/x86/Kconfig
>> @@ -123,6 +123,17 @@ config XIAOMI_WMI
>>To compile this driver as a module, choose M here: the module will
>>be called xiaomi-wmi.
>>  
>> +config GIGABYTE_WMI
>> +tristate "Gigabyte WMI temperature driver"
>> +depends on ACPI_WMI
>> +depends on HWMON
>> +help
>> +  Say Y here if you want to support WMI-based temperature reporting on
>> +  Gigabyte mainboards.
>> +
>> +  To compile this driver as a module, choose M here: the module will
>> +  be called gigabyte-wmi.
>> +
>>  config ACERHDF
>>  tristate "Acer Aspire One temperature and fan driver"
>>  depends on ACPI && THERMAL
>> diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
>> index 60d554073749..1621ebfd04fd 100644
>> --- a/drivers/platform/x86/Makefile
>> +++ b/drivers/platform/x86/Makefile
>> @@ -15,6 +15,7 @@ obj-$(CONFIG_INTEL_WMI_THUNDERBOLT)+= 
>> intel-wmi-thunderbolt.o
>>  obj-$(CONFIG_MXM_WMI)   += mxm-wmi.o
>>  obj-$(CONFIG_PEAQ_WMI)  

Re: [PATCH v1 2/5] gpio: xilinx: Correct kernel doc for xgpio_probe()

[Michal Simek]

On 4/8/21 4:55 PM, Andy Shevchenko wrote:
> Kernel doc validator complains:
> 
> .../gpio-xilinx.c:556: warning: expecting prototype for xgpio_of_probe(). 
> Prototype was for xgpio_probe() instead
> 
> Correct as suggested by changing the name of the function in the doc..
> 
> Fixes: 749564ffd52d ("gpio/xilinx: Convert the driver to platform device 
> interface")
> Signed-off-by: Andy Shevchenko 
> ---
>  drivers/gpio/gpio-xilinx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> index b411d3156e0b..136557e7dd3c 100644
> --- a/drivers/gpio/gpio-xilinx.c
> +++ b/drivers/gpio/gpio-xilinx.c
> @@ -542,7 +542,7 @@ static void xgpio_irqhandler(struct irq_desc *desc)
>  }
>  
>  /**
> - * xgpio_of_probe - Probe method for the GPIO device.
> + * xgpio_probe - Probe method for the GPIO device.
>   * @pdev: pointer to the platform device
>   *
>   * Return:
> 

Reviewed-by: Michal Simek 

Thanks,
Michal

Re: [PATCH 0/4] Add support for XMM fast hypercalls

[Siddharth Chandrasekaran]

On Thu, Apr 08, 2021 at 03:38:13PM +, Wei Liu wrote:
> On Thu, Apr 08, 2021 at 05:30:26PM +0200, Paolo Bonzini wrote:
> > On 08/04/21 17:28, Wei Liu wrote:
> > > > Although the Hyper-v TLFS mentions that a guest cannot use this feature
> > > > unless the hypervisor advertises support for it, some hypercalls which
> > > > we plan on upstreaming in future uses them anyway.
> > >
> > > No, please don't do this. Check the feature bit(s) before you issue
> > > hypercalls which rely on the extended interface.
> >
> > Perhaps Siddharth should clarify this, but I read it as Hyper-V being buggy
> > and using XMM arguments unconditionally.
> >
> 
> There is no code in upstream Linux that uses the XMM fast hypercall
> interface at the moment.
> 
> If there is such code, it has bugs in it and should be fixed. :-)

None of the existing hypercalls are buggy. These are some hypercalls we
are working on (and planning on upstreaming in the near future). 

~ Sid.



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

Re: [PATCH v2 2/2] x86/sgx: Add sgx_nr_{all, free}_pages to the debugfs

[Jarkko Sakkinen]

On Thu, Apr 08, 2021 at 11:32:23AM +0200, Borislav Petkov wrote:
> On Thu, Apr 08, 2021 at 12:13:21PM +0300, Jarkko Sakkinen wrote:
> > Actually I think read-only sysctl attributes would be a better idea.
> 
> I still think debugfs is the right *start* for this: you play with them,
> see what makes sense and what not, tweak them, etc, and then you cast
> them in stone.

Yup. Also better to see what makes sense in the context of virtualization.
Too many (unknown) unknowns to make the right call.

> Not cast them in stone and see if anyone is even interested. So pls keep
> them in debugfs for now - you can always do whatever, later, when it
> turns out that those are useful.

I'll do that.

> Thx.
> 
> -- 
> Regards/Gruss,
> Boris.
> 
> https://people.kernel.org/tglx/notes-about-netiquette

/Jarkko

Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv

[Jason Gunthorpe]

On Thu, Apr 08, 2021 at 01:38:17PM +0200, Daniel Vetter wrote:

> If you want to change this, we need automatic conflict resolution like apt
> and other package managers have, with suggestions how to fix the config if
> you want to enable a driver, but some of its requirements are missing. The
> current approach of hiding driver symbols complete if any of their
> dependencies are off is really not great.

+1 to this.. 

Though Kconfig is basically already unusuable unless you have hours to
carefully craft the kconfig you need to get out.

I'm not sure trying to optimize this by abusing the existing language
rules is such a good idea.

I gave a very half hearted go at a simple heuristic solution solve for
kconfig a while ago. It is good enough to sometimes automate a kconfig
task, but it is not so nice.

I use it to do things like "turn on all RDMA drivers" which is quite
a hard to do by hand.

It looks liked heursitics need a lot of fine tuning as the
conditionals are complex enough that it is hard to guess which branch
is going to yield a success.

Jason

Re: [PATCH] KVM: x86: Remove unused function declaration

[Sean Christopherson]

On Tue, Apr 06, 2021, Keqian Zhu wrote:
> kvm_mmu_slot_largepage_remove_write_access() is decared but not used,
> just remove it.
> 
> Signed-off-by: Keqian Zhu 

Reviewed-by: Sean Christopherson 

Re: [RFC bpf-next 1/1] bpf: Introduce iter_pagecache

[Al Viro]

On Wed, Apr 07, 2021 at 02:46:11PM -0700, Daniel Xu wrote:

> +static void fini_seq_pagecache(void *priv_data)
> +{
> + struct bpf_iter_seq_pagecache_info *info = priv_data;
> + struct radix_tree_iter iter;
> + struct super_block *sb;
> + void **slot;
> +
> + radix_tree_for_each_slot(slot, >superblocks, , 0) {
> + sb = (struct super_block *)iter.index;
> + atomic_dec(>s_active);
> + radix_tree_delete(>superblocks, iter.index);
> + }

... and if in the meanwhile all other contributors to ->s_active have
gone away, that will result in...?

IOW, NAK.  The objects you are playing with have non-trivial lifecycle
and poking into the guts of data structures without bothering to
understand it is not a good idea.

Rule of the thumb: if your code ends up using fields that are otherwise
handled by a small part of codebase, the odds are that you need to be
bloody careful.  In particular, ->ns_lock has 3 users - all in
fs/namespace.c.  ->list/->mnt_list: all users in fs/namespace.c and
fs/pnode.c.  ->s_active: majority in fs/super.c, with several outliers
in filesystems and safety of those is not trivial.

Any time you see that kind of pattern, you are risking to reprise
a scene from The Modern Times - the one with Charlie taking a trip
through the guts of machinery.

Re: [PATCH -next] RDMA/srpt: Fix error return code in srpt_cm_req_recv()

[Bart Van Assche]

On 4/8/21 4:31 AM, Wang Wensheng wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
> 
> Fixes: db7683d7deb2 ("IB/srpt: Fix login-related race conditions")
> Reported-by: Hulk Robot 
> Signed-off-by: Wang Wensheng 
> ---
>  drivers/infiniband/ulp/srpt/ib_srpt.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/infiniband/ulp/srpt/ib_srpt.c 
> b/drivers/infiniband/ulp/srpt/ib_srpt.c
> index 98a393d..ea44780 100644
> --- a/drivers/infiniband/ulp/srpt/ib_srpt.c
> +++ b/drivers/infiniband/ulp/srpt/ib_srpt.c
> @@ -2382,6 +2382,7 @@ static int srpt_cm_req_recv(struct srpt_device *const 
> sdev,
>   pr_info("rejected SRP_LOGIN_REQ because target %s_%d is not 
> enabled\n",
>   dev_name(>device->dev), port_num);
>   mutex_unlock(>mutex);
> + ret = -EINVAL;
>   goto reject;
>   }

Please fix the Hulk Robot. The following code occurs three lines above
the modified code:

ret = -EINVAL;

Thanks,

Bart.

RE: [PATCH v2 net-next] net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)

[Haiyang Zhang]

> -Original Message-
> From: Stephen Hemminger 
> Sent: Thursday, April 8, 2021 12:52 PM
> To: Randy Dunlap 
> Cc: Dexuan Cui ; da...@davemloft.net;
> k...@kernel.org; KY Srinivasan ; Haiyang Zhang
> ; Stephen Hemminger
> ; wei@kernel.org; Wei Liu
> ; net...@vger.kernel.org; l...@kernel.org;
> and...@lunn.ch; be...@petrovitsch.priv.at; linux-kernel@vger.kernel.org;
> linux-hyp...@vger.kernel.org
> Subject: Re: [PATCH v2 net-next] net: mana: Add a driver for Microsoft Azure
> Network Adapter (MANA)
> 
> On Thu, 8 Apr 2021 09:22:57 -0700
> Randy Dunlap  wrote:
> 
> > On 4/8/21 2:15 AM, Dexuan Cui wrote:
> > > diff --git a/drivers/net/ethernet/microsoft/Kconfig
> > > b/drivers/net/ethernet/microsoft/Kconfig
> > > new file mode 100644
> > > index ..12ef6b581566
> > > --- /dev/null
> > > +++ b/drivers/net/ethernet/microsoft/Kconfig
> > > @@ -0,0 +1,30 @@
> > > +#
> > > +# Microsoft Azure network device configuration #
> > > +
> > > +config NET_VENDOR_MICROSOFT
> > > + bool "Microsoft Azure Network Device"
> >
> > Seems to me that should be generalized, more like:
> >
> > bool "Microsoft Network Devices"
> 
> Yes, that is what it should be at this level.
> 
> >
> >
> > > + default y
> 
> This follows the existing policy for network vendor level
> 
> > > + help
> > > +   If you have a network (Ethernet) device belonging to this class, say 
> > > Y.
> > > +
> > > +   Note that the answer to this question doesn't directly affect the
> > > +   kernel: saying N will just cause the configurator to skip the
> > > +   question about Microsoft Azure network device. If you say Y, you
> >
> >about Microsoft networking devices.
> >
> > > +   will be asked for your specific device in the following question.
> > > +
> > > +if NET_VENDOR_MICROSOFT
> > > +
> > > +config MICROSOFT_MANA
> > > + tristate "Microsoft Azure Network Adapter (MANA) support"
> > > + default m
> >
> > Please drop the default m. We don't randomly add drivers to be built.
> 
> Yes, it should be no (or no default which is the default for default)
> 
> > Or leave this as is and change NET_VENDOR_MICROSOFT to be default n.
> >
> >
> > > + depends on PCI_MSI && X86_64
> > > + select PCI_HYPERV
> > > + help
> > > +   This driver supports Microsoft Azure Network Adapter (MANA).
> > > +   So far, the driver is only validated on X86_64.
> >
> > validated how?
> 
> Maybe change validated to supported?

Sounds better. We will change it to "supported".
Also other suggested changes.

Thanks,
- Haiyang

Re: [PATCH] KVM: X86: Do not yield to self

[Sean Christopherson]

On Thu, Apr 08, 2021, Wanpeng Li wrote:
> From: Wanpeng Li 
> 
> If the target is self we do not need to yield, we can avoid malicious 
> guest to play this.
> 
> Signed-off-by: Wanpeng Li 
> ---
> Rebased on 
> https://lore.kernel.org/kvm/1617697935-4158-1-git-send-email-wanpen...@tencent.com/
> 
>  arch/x86/kvm/x86.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 43c9f9b..260650f 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -8230,6 +8230,10 @@ static void kvm_sched_yield(struct kvm_vcpu *vcpu, 
> unsigned long dest_id)
>   if (!target)
>   goto no_yield;
>  
> + /* yield to self */

If you're going to bother with a comment, maybe elaborate a bit, e.g.

/* Ignore requests to yield to self. */

> + if (vcpu->vcpu_id == target->vcpu_id)
> + goto no_yield;
> +
>   if (!READ_ONCE(target->ready))
>   goto no_yield;
>  
> -- 
> 2.7.4
> 

Re: [PATCH] PCI: tegra: Fix runtime PM imbalance in pex_ep_event_pex_rst_deassert

[Lorenzo Pieralisi]

On Thu, 8 Apr 2021 15:26:58 +0800, Dinghao Liu wrote:
> pm_runtime_get_sync() will increase the runtime PM counter
> even it returns an error. Thus a pairing decrement is needed
> to prevent refcount leak. Fix this by replacing this API with
> pm_runtime_resume_and_get(), which will not change the runtime
> PM counter on error.

Applied to pci/tegra, thanks!

[1/1] PCI: tegra: Fix runtime PM imbalance in pex_ep_event_pex_rst_deassert
  https://git.kernel.org/lpieralisi/pci/c/571cdd5294

Thanks,
Lorenzo

Re: [PATCH v2 3/3] perf-stat: introduce config stat.bpf-counter-events

[Song Liu]

> On Apr 8, 2021, at 10:20 AM, Jiri Olsa  wrote:
> 
> On Thu, Apr 08, 2021 at 04:39:33PM +, Song Liu wrote:
>> 
>> 
>>> On Apr 8, 2021, at 4:47 AM, Jiri Olsa  wrote:
>>> 
>>> On Tue, Apr 06, 2021 at 05:36:01PM -0700, Song Liu wrote:
 Currently, to use BPF to aggregate perf event counters, the user uses
 --bpf-counters option. Enable "use bpf by default" events with a config
 option, stat.bpf-counter-events. This is limited to hardware events in
 evsel__hw_names.
 
 This also enables mixed BPF event and regular event in the same sesssion.
 For example:
 
  perf config stat.bpf-counter-events=instructions
  perf stat -e instructions,cs
 
>>> 
>>> so if we are mixing events now, how about uing modifier for bpf counters,
>>> instead of configuring .perfconfig list we could use:
>>> 
>>> perf stat -e instructions:b,cs
>>> 
>>> thoughts?
>>> 
>>> the change below adds 'b' modifier and sets 'evsel::bpf_counter',
>>> feel free to use it
>> 
>> I think we will need both 'b' modifier and .perfconfig configuration. 
>> For systems with BPF-managed perf events running in the background, 
> 
> hum, I'm not sure I understand what that means.. you mean there
> are tools that run perf stat so you don't want to change them?

We have tools that do perf_event_open(). I will change them to use 
BPF managed perf events for "cycles" and "instructions". Since these 
tools are running 24/7, perf-stat on the system should use BPF managed
"cycles" and "instructions" by default. 

> 
>> .perfconfig makes sure perf-stat sessions will share PMCs with these 
>> background monitoring tools. 'b' modifier, on the other hand, is useful
>> when the user knows there is opportunity to share the PMCs. 
>> 
>> Does this make sense? 
> 
> if there's reason for that then sure.. but let's not limit that just
> on HARDWARE events only.. there are RAW events with the same demand
> for this feature.. why don't we let user define any event for this?

I haven't found a good way to config RAW events. I guess RAW events 
could use 'b' modifier? 

Thanks,
Song

Re: [PATCH 2/7] cxl/mem: Split creation from mapping in probe

[Jonathan Cameron]

On Wed, 7 Apr 2021 15:26:20 -0700
Ben Widawsky  wrote:

> Add a new function specifically for mapping the register blocks and
> offsets within. The new function can be used more generically for other
> register block identifiers.
> 
> No functional change is meant to be introduced in this patch with the
> exception of a dev_err printed when the device register block isn't
> found.
> 
> Signed-off-by: Ben Widawsky 
Agreed, this seems to be a noop refactor to me.

Reviewed-by: Jonathan Cameron 

> ---
>  drivers/cxl/mem.c | 64 +--
>  1 file changed, 40 insertions(+), 24 deletions(-)
> 
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index 99534260034e..520edaf233d4 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -925,22 +925,40 @@ static int cxl_mem_setup_mailbox(struct cxl_mem *cxlm)
>   return 0;
>  }
>  
> -static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev, u32 reg_lo,
> -   u32 reg_hi)
> +static struct cxl_mem *cxl_mem_create(struct pci_dev *pdev)
>  {
>   struct device *dev = >dev;
>   struct cxl_mem *cxlm;
> - void __iomem *regs;
> - u64 offset;
> - u8 bar;
> - int rc;
>  
>   cxlm = devm_kzalloc(dev, sizeof(*cxlm), GFP_KERNEL);
>   if (!cxlm) {
>   dev_err(dev, "No memory available\n");
> - return NULL;
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + mutex_init(>mbox_mutex);
> + cxlm->pdev = pdev;
> + cxlm->enabled_cmds =
> + devm_kmalloc_array(dev, BITS_TO_LONGS(cxl_cmd_count),
> +sizeof(unsigned long),
> +GFP_KERNEL | __GFP_ZERO);
> + if (!cxlm->enabled_cmds) {
> + dev_err(dev, "No memory available for bitmap\n");
> + return ERR_PTR(-ENOMEM);
>   }
>  
> + return cxlm;
> +}
> +
> +static int cxl_mem_map_regblock(struct cxl_mem *cxlm, u32 reg_lo, u32 reg_hi)
> +{
> + struct pci_dev *pdev = cxlm->pdev;
> + struct device *dev = >dev;
> + void __iomem *regs;
> + u64 offset;
> + u8 bar;
> + int rc;
> +
>   offset = ((u64)reg_hi << 32) | FIELD_GET(CXL_REGLOC_ADDR_MASK, reg_lo);
>   bar = FIELD_GET(CXL_REGLOC_BIR_MASK, reg_lo);
>  
> @@ -948,30 +966,20 @@ static struct cxl_mem *cxl_mem_create(struct pci_dev 
> *pdev, u32 reg_lo,
>   if (pci_resource_len(pdev, bar) < offset) {
>   dev_err(dev, "BAR%d: %pr: too small (offset: %#llx)\n", bar,
>   >resource[bar], (unsigned long long)offset);
> - return NULL;
> + return -ENXIO;
>   }
>  
>   rc = pcim_iomap_regions(pdev, BIT(bar), pci_name(pdev));
>   if (rc) {
>   dev_err(dev, "failed to map registers\n");
> - return NULL;
> + return rc;
>   }
>   regs = pcim_iomap_table(pdev)[bar];
>  
> - mutex_init(>mbox_mutex);
> - cxlm->pdev = pdev;
>   cxlm->base = regs + offset;
> - cxlm->enabled_cmds =
> - devm_kmalloc_array(dev, BITS_TO_LONGS(cxl_cmd_count),
> -sizeof(unsigned long),
> -GFP_KERNEL | __GFP_ZERO);
> - if (!cxlm->enabled_cmds) {
> - dev_err(dev, "No memory available for bitmap\n");
> - return NULL;
> - }
>  
>   dev_dbg(dev, "Mapped CXL Memory Device resource\n");
> - return cxlm;
> + return 0;
>  }
>  
>  static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> @@ -1403,14 +1411,18 @@ static int cxl_mem_identify(struct cxl_mem *cxlm)
>  static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id 
> *id)
>  {
>   struct device *dev = >dev;
> - struct cxl_mem *cxlm = NULL;
>   u32 regloc_size, regblocks;
> + struct cxl_mem *cxlm;
>   int rc, regloc, i;
>  
>   rc = pcim_enable_device(pdev);
>   if (rc)
>   return rc;
>  
> + cxlm = cxl_mem_create(pdev);
> + if (IS_ERR(cxlm))
> + return PTR_ERR(cxlm);
> +
>   regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC_OFFSET);
>   if (!regloc) {
>   dev_err(dev, "register location dvsec not found\n");
> @@ -1435,13 +1447,17 @@ static int cxl_mem_probe(struct pci_dev *pdev, const 
> struct pci_device_id *id)
>   reg_type = FIELD_GET(CXL_REGLOC_RBI_MASK, reg_lo);
>  
>   if (reg_type == CXL_REGLOC_RBI_MEMDEV) {
> - cxlm = cxl_mem_create(pdev, reg_lo, reg_hi);
> + rc = cxl_mem_map_regblock(cxlm, reg_lo, reg_hi);
> + if (rc)
> + return rc;
>   break;
>   }
>   }
>  
> - if (!cxlm)
> - return -ENODEV;
> + if (i == regblocks) {
> + dev_err(dev, "Missing register locator for device registers\n");
> + return -ENXIO;
> + }
>  
>   rc = 

Re: [PATCH 4/7] cxl/mem: Get rid of @cxlm.base

[Jonathan Cameron]

On Wed, 7 Apr 2021 15:26:22 -0700
Ben Widawsky  wrote:

> @cxlm.base only existed to support holding the base found in the
> register block mapping code, and pass it along to the register setup
> code. Now that the register setup function has all logic around managing
> the registers, from DVSEC to iomapping up to populating our CXL specific
> information, it is easy to turn the @base values into local variables
> and remove them from our device driver state.
> 
> Signed-off-by: Ben Widawsky 

Patch is basically fine, but I do wonder if you could avoid the
nasty casting in and out of __iomem in the error paths.

It's a common enough idiom though so I'm not htat fussed.

Acked-by: Jonathan Cameron 

> ---
>  drivers/cxl/mem.c | 24 +++-
>  drivers/cxl/mem.h |  2 --
>  2 files changed, 11 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index 04b4f7445083..60b95c524c3e 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -922,11 +922,10 @@ static struct cxl_mem *cxl_mem_create(struct pci_dev 
> *pdev)
>   return cxlm;
>  }
>  
> -static int cxl_mem_map_regblock(struct cxl_mem *cxlm, u32 reg_lo, u32 reg_hi)
> +static void __iomem *cxl_mem_map_regblock(struct cxl_mem *cxlm, u32 reg_lo, 
> u32 reg_hi)
>  {
>   struct pci_dev *pdev = cxlm->pdev;
>   struct device *dev = >dev;
> - void __iomem *regs;
>   u64 offset;
>   u8 bar;
>   int rc;
> @@ -938,20 +937,18 @@ static int cxl_mem_map_regblock(struct cxl_mem *cxlm, 
> u32 reg_lo, u32 reg_hi)
>   if (pci_resource_len(pdev, bar) < offset) {
>   dev_err(dev, "BAR%d: %pr: too small (offset: %#llx)\n", bar,
>   >resource[bar], (unsigned long long)offset);
> - return -ENXIO;
> + return (void __iomem *)ERR_PTR(-ENXIO);
>   }
>  
>   rc = pcim_iomap_regions(pdev, BIT(bar), pci_name(pdev));
>   if (rc) {
>   dev_err(dev, "failed to map registers\n");
> - return rc;
> + return (void __iomem *)ERR_PTR(rc);

The casting is fairly horrible, perhaps just pass in
a void __iomem ** and pass base back through that?

>   }
> - regs = pcim_iomap_table(pdev)[bar];
> -
> - cxlm->base = regs + offset;
>  
>   dev_dbg(dev, "Mapped CXL Memory Device resource\n");
> - return 0;
> +
> + return pcim_iomap_table(pdev)[bar] + offset;
>  }
>  
>  static int cxl_mem_dvsec(struct pci_dev *pdev, int dvsec)
> @@ -993,7 +990,8 @@ static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
>   struct pci_dev *pdev = cxlm->pdev;
>   struct device *dev = >dev;
>   u32 regloc_size, regblocks;
> - int rc, regloc, i;
> + void __iomem *base;
> + int regloc, i;
>  
>   regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC_OFFSET);
>   if (!regloc) {
> @@ -1019,9 +1017,9 @@ static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
>   reg_type = FIELD_GET(CXL_REGLOC_RBI_MASK, reg_lo);
>  
>   if (reg_type == CXL_REGLOC_RBI_MEMDEV) {
> - rc = cxl_mem_map_regblock(cxlm, reg_lo, reg_hi);
> - if (rc)
> - return rc;
> + base = cxl_mem_map_regblock(cxlm, reg_lo, reg_hi);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
>   break;
>   }
>   }
> @@ -1031,7 +1029,7 @@ static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
>   return -ENXIO;
>   }
>  
> - cxl_setup_device_regs(dev, cxlm->base, >device_regs);
> + cxl_setup_device_regs(dev, base, >device_regs);
>  
>   if (!regs->status || !regs->mbox || !regs->memdev) {
>   dev_err(dev, "registers not found: %s%s%s\n",
> diff --git a/drivers/cxl/mem.h b/drivers/cxl/mem.h
> index 8bad7166adba..bfcfef461b16 100644
> --- a/drivers/cxl/mem.h
> +++ b/drivers/cxl/mem.h
> @@ -49,7 +49,6 @@ struct cxl_memdev {
>  /**
>   * struct cxl_mem - A CXL memory device
>   * @pdev: The PCI device associated with this CXL device.
> - * @base: IO mappings to the device's MMIO
>   * @cxlmd: Logical memory device chardev / interface
>   * @regs: Parsed register blocks
>   * @payload_size: Size of space for payload
> @@ -62,7 +61,6 @@ struct cxl_memdev {
>   */
>  struct cxl_mem {
>   struct pci_dev *pdev;
> - void __iomem *base;
>   struct cxl_memdev *cxlmd;
>  
>   struct cxl_regs regs;

[PATCH 2/2] arch/x86: arch/sparc: tools/perf: fix typos in comments

[Thomas Tai]

s/insted/instead/
s/maintaing/maintaining/

Signed-off-by: Thomas Tai 
---
 arch/sparc/vdso/vdso2c.c | 2 +-
 arch/x86/entry/vdso/vdso2c.c | 2 +-
 arch/x86/kernel/cpu/intel.c  | 2 +-
 tools/perf/arch/x86/util/perf_regs.c | 4 ++--
 4 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/sparc/vdso/vdso2c.c b/arch/sparc/vdso/vdso2c.c
index ab75041..70df9a8 100644
--- a/arch/sparc/vdso/vdso2c.c
+++ b/arch/sparc/vdso/vdso2c.c
@@ -192,7 +192,7 @@ int main(int argc, char **argv)
 
/*
 * Figure out the struct name.  If we're writing to a .so file,
-* generate raw output insted.
+* generate raw output instead.
 */
name = strdup(argv[3]);
namelen = strlen(name);
diff --git a/arch/x86/entry/vdso/vdso2c.c b/arch/x86/entry/vdso/vdso2c.c
index 2d0f3d8..edfe978 100644
--- a/arch/x86/entry/vdso/vdso2c.c
+++ b/arch/x86/entry/vdso/vdso2c.c
@@ -218,7 +218,7 @@ int main(int argc, char **argv)
 
/*
 * Figure out the struct name.  If we're writing to a .so file,
-* generate raw output insted.
+* generate raw output instead.
 */
name = strdup(argv[3]);
namelen = strlen(name);
diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 0e422a5..63e381a 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -301,7 +301,7 @@ static void early_init_intel(struct cpuinfo_x86 *c)
 *  The operating system must reload CR3 to cause the TLB to be flushed"
 *
 * As a result, boot_cpu_has(X86_FEATURE_PGE) in 
arch/x86/include/asm/tlbflush.h
-* should be false so that __flush_tlb_all() causes CR3 insted of 
CR4.PGE
+* should be false so that __flush_tlb_all() causes CR3 instead of 
CR4.PGE
 * to be modified.
 */
if (c->x86 == 5 && c->x86_model == 9) {
diff --git a/tools/perf/arch/x86/util/perf_regs.c 
b/tools/perf/arch/x86/util/perf_regs.c
index fca81b3..207c568 100644
--- a/tools/perf/arch/x86/util/perf_regs.c
+++ b/tools/perf/arch/x86/util/perf_regs.c
@@ -165,7 +165,7 @@ static int sdt_init_op_regex(void)
 /*
  * Max x86 register name length is 5(ex: %r15d). So, 6th char
  * should always contain NULL. This helps to find register name
- * length using strlen, insted of maintaing one more variable.
+ * length using strlen, instead of maintaining one more variable.
  */
 #define SDT_REG_NAME_SIZE  6
 
@@ -207,7 +207,7 @@ int arch_sdt_arg_parse_op(char *old_op, char **new_op)
 * and displacement 0 (Both sign and displacement 0 are
 * optional so it may be empty). Use one more character
 * to hold last NULL so that strlen can be used to find
-* prefix length, instead of maintaing one more variable.
+* prefix length, instead of maintaining one more variable.
 */
char prefix[3] = {0};
 
-- 
1.8.3.1

[PATCH 1/2] x86/traps: call cond_local_irq_disable before returning from exc_general_protection and math_error

[Thomas Tai]

This fixes commit 334872a09198 ("x86/traps: Attempt to fixup exceptions
in vDSO before signaling") which added return statements without calling
cond_local_irq_disable(). According to commit ca4c6a9858c2
("x86/traps: Make interrupt enable/disable symmetric in C code"),
cond_local_irq_disable() is needed because the ASM return code no
longer disables interrupts. Follow the existing code as an example to
use "goto exit" instead of "return" statement.

Signed-off-by: Thomas Tai 
---
 arch/x86/kernel/traps.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index ac1874a..651e3e5 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -556,7 +556,7 @@ static enum kernel_gp_hint get_kernel_gp_address(struct 
pt_regs *regs,
tsk->thread.trap_nr = X86_TRAP_GP;
 
if (fixup_vdso_exception(regs, X86_TRAP_GP, error_code, 0))
-   return;
+   goto exit;
 
show_signal(tsk, SIGSEGV, "", desc, regs, error_code);
force_sig(SIGSEGV);
@@ -1057,7 +1057,7 @@ static void math_error(struct pt_regs *regs, int trapnr)
goto exit;
 
if (fixup_vdso_exception(regs, trapnr, 0, 0))
-   return;
+   goto exit;
 
force_sig_fault(SIGFPE, si_code,
(void __user *)uprobe_get_trap_addr(regs));
-- 
1.8.3.1

Re: [PATCH 3/7] cxl/mem: Move register locator logic into reg setup

[Jonathan Cameron]

On Wed, 7 Apr 2021 15:26:21 -0700
Ben Widawsky  wrote:

> Start moving code around to ultimately get rid of @cxlm.base. The
> @cxlm.base member serves no purpose other than intermediate storage of
> the offset found in cxl_mem_map_regblock() later used by
> cxl_mem_setup_regs(). Aside from wanting to get rid of this useless
> member, it will help later when adding new register block identifiers.
> 
> While @cxlm.base still exists, it will become trivial to remove it in a
> future patch.
> 
> No functional change is meant to be introduced in this patch.
> 
> Signed-off-by: Ben Widawsky 

Seems like a noop refactor to me as you say.

Reviewed-by: Jonathan Cameron 

> ---
>  drivers/cxl/mem.c | 135 +++---
>  1 file changed, 68 insertions(+), 67 deletions(-)
> 
> diff --git a/drivers/cxl/mem.c b/drivers/cxl/mem.c
> index 520edaf233d4..04b4f7445083 100644
> --- a/drivers/cxl/mem.c
> +++ b/drivers/cxl/mem.c
> @@ -870,34 +870,6 @@ static int cxl_mem_mbox_send_cmd(struct cxl_mem *cxlm, 
> u16 opcode,
>   return 0;
>  }
>  
> -/**
> - * cxl_mem_setup_regs() - Setup necessary MMIO.
> - * @cxlm: The CXL memory device to communicate with.
> - *
> - * Return: 0 if all necessary registers mapped.
> - *
> - * A memory device is required by spec to implement a certain set of MMIO
> - * regions. The purpose of this function is to enumerate and map those
> - * registers.
> - */
> -static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
> -{
> - struct device *dev = >pdev->dev;
> - struct cxl_regs *regs = >regs;
> -
> - cxl_setup_device_regs(dev, cxlm->base, >device_regs);
> -
> - if (!regs->status || !regs->mbox || !regs->memdev) {
> - dev_err(dev, "registers not found: %s%s%s\n",
> - !regs->status ? "status " : "",
> - !regs->mbox ? "mbox " : "",
> - !regs->memdev ? "memdev" : "");
> - return -ENXIO;
> - }
> -
> - return 0;
> -}
> -
>  static int cxl_mem_setup_mailbox(struct cxl_mem *cxlm)
>  {
>   const int cap = readl(cxlm->regs.mbox + CXLDEV_MBOX_CAPS_OFFSET);
> @@ -1005,6 +977,73 @@ static int cxl_mem_dvsec(struct pci_dev *pdev, int 
> dvsec)
>   return 0;
>  }
>  
> +/**
> + * cxl_mem_setup_regs() - Setup necessary MMIO.
> + * @cxlm: The CXL memory device to communicate with.
> + *
> + * Return: 0 if all necessary registers mapped.
> + *
> + * A memory device is required by spec to implement a certain set of MMIO
> + * regions. The purpose of this function is to enumerate and map those
> + * registers.
> + */
> +static int cxl_mem_setup_regs(struct cxl_mem *cxlm)
> +{
> + struct cxl_regs *regs = >regs;
> + struct pci_dev *pdev = cxlm->pdev;
> + struct device *dev = >dev;
> + u32 regloc_size, regblocks;
> + int rc, regloc, i;
> +
> + regloc = cxl_mem_dvsec(pdev, PCI_DVSEC_ID_CXL_REGLOC_OFFSET);
> + if (!regloc) {
> + dev_err(dev, "register location dvsec not found\n");
> + return -ENXIO;
> + }
> +
> + /* Get the size of the Register Locator DVSEC */
> + pci_read_config_dword(pdev, regloc + PCI_DVSEC_HEADER1, _size);
> + regloc_size = FIELD_GET(PCI_DVSEC_HEADER1_LENGTH_MASK, regloc_size);
> +
> + regloc += PCI_DVSEC_ID_CXL_REGLOC_BLOCK1_OFFSET;
> + regblocks = (regloc_size - PCI_DVSEC_ID_CXL_REGLOC_BLOCK1_OFFSET) / 8;
> +
> + for (i = 0; i < regblocks; i++, regloc += 8) {
> + u32 reg_lo, reg_hi;
> + u8 reg_type;
> +
> + /* "register low and high" contain other bits */
> + pci_read_config_dword(pdev, regloc, _lo);
> + pci_read_config_dword(pdev, regloc + 4, _hi);
> +
> + reg_type = FIELD_GET(CXL_REGLOC_RBI_MASK, reg_lo);
> +
> + if (reg_type == CXL_REGLOC_RBI_MEMDEV) {
> + rc = cxl_mem_map_regblock(cxlm, reg_lo, reg_hi);
> + if (rc)
> + return rc;
> + break;
> + }
> + }
> +
> + if (i == regblocks) {
> + dev_err(dev, "Missing register locator for device registers\n");
> + return -ENXIO;
> + }
> +
> + cxl_setup_device_regs(dev, cxlm->base, >device_regs);
> +
> + if (!regs->status || !regs->mbox || !regs->memdev) {
> + dev_err(dev, "registers not found: %s%s%s\n",
> + !regs->status ? "status " : "",
> + !regs->mbox ? "mbox " : "",
> + !regs->memdev ? "memdev" : "");
> + return -ENXIO;
> + }
> +
> + return 0;
> +}
> +
>  static struct cxl_memdev *to_cxl_memdev(struct device *dev)
>  {
>   return container_of(dev, struct cxl_memdev, dev);
> @@ -1410,10 +1449,8 @@ static int cxl_mem_identify(struct cxl_mem *cxlm)
>  
>  static int cxl_mem_probe(struct pci_dev *pdev, const struct pci_device_id 
> *id)
>  {
> - struct device *dev = >dev;
> - u32 regloc_size, regblocks;
> 

Re: [PATCH -next] PM: fix typos in comments

[Rafael J. Wysocki]

On Thu, Apr 8, 2021 at 10:14 AM Lu Jialin  wrote:
>
> Change occured to occurred in kernel/power/autosleep.c.
> Change consiting to consisting in kernel/power/snapshot.c.
> Change avaiable to available in kernel/power/swap.c.
> No functionality changed.
>
> Signed-off-by: Lu Jialin 
> ---
>  kernel/power/autosleep.c | 2 +-
>  kernel/power/snapshot.c  | 2 +-
>  kernel/power/swap.c  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/kernel/power/autosleep.c b/kernel/power/autosleep.c
> index 9af5a50d3489..b29c8aca7486 100644
> --- a/kernel/power/autosleep.c
> +++ b/kernel/power/autosleep.c
> @@ -54,7 +54,7 @@ static void try_to_suspend(struct work_struct *work)
> goto out;
>
> /*
> -* If the wakeup occured for an unknown reason, wait to prevent the
> +* If the wakeup occurred for an unknown reason, wait to prevent the
>  * system from trying to suspend and waking up in a tight loop.
>  */
> if (final_count == initial_count)
> diff --git a/kernel/power/snapshot.c b/kernel/power/snapshot.c
> index 64b7aab9aee4..27cb4e7086b7 100644
> --- a/kernel/power/snapshot.c
> +++ b/kernel/power/snapshot.c
> @@ -329,7 +329,7 @@ static void *chain_alloc(struct chain_allocator *ca, 
> unsigned int size)
>  /**
>   * Data types related to memory bitmaps.
>   *
> - * Memory bitmap is a structure consiting of many linked lists of
> + * Memory bitmap is a structure consisting of many linked lists of
>   * objects.  The main list's elements are of type struct zone_bitmap
>   * and each of them corresonds to one zone.  For each zone bitmap
>   * object there is a list of objects of type struct bm_block that
> diff --git a/kernel/power/swap.c b/kernel/power/swap.c
> index 72e33054a2e1..bea3cb8afa11 100644
> --- a/kernel/power/swap.c
> +++ b/kernel/power/swap.c
> @@ -884,7 +884,7 @@ static int save_image_lzo(struct swap_map_handle *handle,
>   * enough_swap - Make sure we have enough swap to save the image.
>   *
>   * Returns TRUE or FALSE after checking the total amount of swap
> - * space avaiable from the resume partition.
> + * space available from the resume partition.
>   */
>
>  static int enough_swap(unsigned int nr_pages)
> --

Applied as 5.13 material, thanks!

Re: [PATCH -next] clk: samsung: Remove redundant dev_err calls

[Sylwester Nawrocki]

On 08.04.2021 18:21, Krzysztof Kozlowski wrote:
> On 08/04/2021 15:48, Chen Hui wrote:
>> There is error message within devm_ioremap_resource
>> already, so remove the dev_err calls to avoid redundant
>> error messages.
>>
>> Signed-off-by: Chen Hui 
>> ---
>>  drivers/clk/samsung/clk-exynos4412-isp.c | 4 +---
>>  drivers/clk/samsung/clk-s5pv210-audss.c  | 4 +---
>>  2 files changed, 2 insertions(+), 6 deletions(-)
> 
> Reviewed-by: Krzysztof Kozlowski 

Thank you, patch applied.

Re: [PATCH v2] KVM: SVM: Make sure GHCB is mapped before updating

[Sean Christopherson]

On Thu, Apr 08, 2021, Tom Lendacky wrote:
> On 4/8/21 12:10 PM, Sean Christopherson wrote:
> > On Thu, Apr 08, 2021, Tom Lendacky wrote:
> >> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> >> index 83e00e524513..7ac67615c070 100644
> >> --- a/arch/x86/kvm/svm/sev.c
> >> +++ b/arch/x86/kvm/svm/sev.c
> >> @@ -2105,5 +2105,8 @@ void sev_vcpu_deliver_sipi_vector(struct kvm_vcpu 
> >> *vcpu, u8 vector)
> >> * the guest will set the CS and RIP. Set SW_EXIT_INFO_2 to a
> >> * non-zero value.
> >> */
> >> +  if (WARN_ON_ONCE(!svm->ghcb))
> > 
> > Isn't this guest triggerable?  I.e. send a SIPI without doing the reset 
> > hold?
> > If so, this should not WARN.
> 
> Yes, it is a guest triggerable event. But a guest shouldn't be doing that,
> so I thought adding the WARN_ON_ONCE() just to detect it wasn't bad.
> Definitely wouldn't want a WARN_ON().

WARNs are intended only for host issues, e.g. a malicious guest shouldn't be
able to crash the host when running with panic_on_warn.

RE: [PATCH net-next v3 1/2] mfd: Add Renesas Synchronization Management Unit (SMU) support

[Min Li]

> 
> If this is v3, there should be a changelog here.
> 
Hi Lee

There is no change in v3 for MFD part of code, v3 is only for misc part. 
But I have to format 2 patches together and that is why mfd part got v3 as well.
But it is actually identical to v2

Re: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb endpoint device voltage regulators

[Rob Herring]

On Tue, Apr 06, 2021 at 05:47:08PM +0100, Mark Brown wrote:
> On Thu, Apr 01, 2021 at 05:21:42PM -0400, Jim Quinlan wrote:
> > Similar to the regulator bindings found in "rockchip-pcie-host.txt", this
> > allows optional regulators to be attached and controlled by the PCIe RC
> > driver.  That being said, this driver searches in the DT subnode (the EP
> > node, eg pci@0,0) for the regulator property.
> 
> > The use of a regulator property in the pcie EP subnode such as
> > "vpcie12v-supply" depends on a pending pullreq to the pci-bus.yaml
> > file at
> > 
> > https://github.com/devicetree-org/dt-schema/pull/54
> > 
> > Signed-off-by: Jim Quinlan 
> > ---
> >  Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml | 4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml 
> > b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > index f90557f6deb8..f2caa5b3b281 100644
> > --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml
> > @@ -64,6 +64,9 @@ properties:
> >  
> >aspm-no-l0s: true
> >  
> > +  vpcie12v-supply: true
> > +  vpcie3v3-supply: true
> > +
> 
> No great problem with having these in the controller node (assming it
> accurately describes the hardware) but I do think we ought to also be
> able to describe these per slot.

My hesistancy here is child nodes are already defined to be devices, not 
slots. That's generally the same thing though. However, 'reg' is a bit 
problematic as it includes the bus number which is dynamically 
assigned. (This is a mismatch between true OpenFirmware and FDT as OF 
was designed to populate the DT with what was discovered and that 
includes some runtime config such as bus number assignments.) Maybe we 
just say for FDT, the bus number is always 0 and ignored. In any case, 
there needs to be some thought on this as well as the more complicated 
case of devices needing device specific setup to be enumerated.

Rob

Re: [PATCH 1/6] PM: runtime: enable wake irq after runtime_suspend hook called

[Rafael J. Wysocki]

On Thu, Apr 8, 2021 at 11:35 AM Chunfeng Yun  wrote:
>
> When the dedicated wake irq is level trigger, enable it before
> calling runtime_suspend, will trigger an interrupt.
>
> e.g.
> for a low level trigger type, it's low level at running time (0),
> and becomes high level when enters suspend (runtime_suspend (1) is
> called), a wakeup signal at (2) make it become low level, wake irq
> will be triggered.
>
> --
>|   ^ ^|
>    | | --
>  |<---(0)--->|<--(1)--|   (3)   (2)(4)
>
> if we enable the wake irq before calling runtime_suspend during (0),
> an interrupt will arise, it causes resume immediately;

But that's necessary to avoid missing a wakeup interrupt, isn't it?

> enable wake irq after calling runtime_suspend, e.g. at (3) or (4),
> will works.
>
> This patch seems no side effect on edge trigger wake irq.
>
> Signed-off-by: Chunfeng Yun 
> ---
>  drivers/base/power/runtime.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> index a46a7e30881b..796739a015a5 100644
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -619,12 +619,12 @@ static int rpm_suspend(struct device *dev, int rpmflags)
> __update_runtime_status(dev, RPM_SUSPENDING);
>
> callback = RPM_GET_CALLBACK(dev, runtime_suspend);
> -
> -   dev_pm_enable_wake_irq_check(dev, true);
> retval = rpm_callback(callback, dev);
> if (retval)
> goto fail;
>
> +   dev_pm_enable_wake_irq_check(dev, true);
> +
>   no_callback:
> __update_runtime_status(dev, RPM_SUSPENDED);
> pm_runtime_deactivate_timer(dev);
> @@ -659,7 +659,6 @@ static int rpm_suspend(struct device *dev, int rpmflags)
> return retval;
>
>   fail:
> -   dev_pm_disable_wake_irq_check(dev);
> __update_runtime_status(dev, RPM_ACTIVE);
> dev->power.deferred_resume = false;
> wake_up_all(>power.wait_queue);
> --
> 2.18.0
>

Re: [PATCH 1/2 v2] staging: media: hantro: Align line break to the open parenthesis in file hantro_hw.h

[ascordeiro]

Em qui, 2021-04-08 às 13:20 -0300, Ezequiel Garcia escreveu:
> Ola Aline,
Ola Ezequiel,

> Welcome to the kernel community. Hope you enjoy some of this
> Outreachy adventures.
Thank you!

> Normally, when you submit a v2, we want to know what changed
> between the first submission and v2.
> 
> If you are subscribed to linux-media, you can read some
> of the series with a vN+1 and look how it's done. Examples:
> 
> https://www.spinics.net/lists/linux-media/msg190043.html
> 
> https://www.spinics.net/lists/linux-media/msg189923.html
> 
> I'm sure your Outreachy mentors can tell you more.
Thank you for the examples, it won't happen again.

The reason for sending a v2 is that I sent my very first patchset
yesterday and I sent the cover-letter together, but (I think) I wasn't
supposed to, and as the patches weren't marked as [PATCH 1/2] and
[PATCH 2/2] in the email - since I commited all the files with the same
message - I tought it was wrong and sent again today.

However, I just realized that I've changed just the subject of the e-
mail, but I would've to change the commit message, right? And then, it
would be a second version, am I right? 

Thank you in advance,

> On Thu, 2021-04-08 at 11:07 -0300, Aline Santana Cordeiro wrote:
> > Aligns line break with the remaining function arguments
> > to the open parenthesis. Issue found by checkpatch.
> > 
> > Signed-off-by: Aline Santana Cordeiro <   
> > alinesantanacorde...@gmail.com>
> > ---
> >  drivers/staging/media/hantro/hantro_hw.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/staging/media/hantro/hantro_hw.h
> > b/drivers/staging/media/hantro/hantro_hw.h
> > index 34c9e46..a650b9c 100644
> > --- a/drivers/staging/media/hantro/hantro_hw.h
> > +++ b/drivers/staging/media/hantro/hantro_hw.h
> > @@ -207,7 +207,7 @@ hantro_h264_mv_size(unsigned int width,
> > unsigned int height)
> >  void hantro_g1_mpeg2_dec_run(struct hantro_ctx *ctx);
> >  void rk3399_vpu_mpeg2_dec_run(struct hantro_ctx *ctx);
> >  void hantro_mpeg2_dec_copy_qtable(u8 *qtable,
> > -   const struct v4l2_ctrl_mpeg2_quantization *ctrl);
> > + const struct
> > v4l2_ctrl_mpeg2_quantization *ctrl);
> >  int hantro_mpeg2_dec_init(struct hantro_ctx *ctx);
> >  void hantro_mpeg2_dec_exit(struct hantro_ctx *ctx);
> >  
> 
> 

Re: [PATCH] tools: Fix a typo in kernel-chktaint

[Jonathan Corbet]

Masanari Iida  writes:

> This patch fixes a spelling typo in kernel-chktaint
>
> Signed-off-by: Masanari Iida 
> ---
>  tools/debugging/kernel-chktaint | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/debugging/kernel-chktaint b/tools/debugging/kernel-chktaint
> index 607b2b280945..719f18b1edf0 100755
> --- a/tools/debugging/kernel-chktaint
> +++ b/tools/debugging/kernel-chktaint
> @@ -25,7 +25,7 @@ if [ "$1"x != "x" ]; then
>   elif  [ $1 -ge 0 ] 2>/dev/null ; then
>   taint=$1
>   else
> - echo "Error: Parameter '$1' not a positive interger. Aborting." 
> >&2
> + echo "Error: Parameter '$1' not a positive integer. Aborting." 
> >&2
>   exit 1

Applied, thanks.

jon

Re: [PATCH net-next v3 2/2] misc: Add Renesas Synchronization Management Unit (SMU) support

[Greg KH]

On Thu, Apr 08, 2021 at 05:26:40PM +, Min Li wrote:
> > 
> > Again, please make this only one file.
> > 
> Hi Greg, the 2 boards have some same named registers in idt82p33_reg.h and 
> idt8a340_reg.h
> so if I put them all in the same file, there will be name conflicts. 

That does not make sense, this is only one kernel module, with one .h
file in this patch, I do not see those other files you are talking
about...

And if you have named registers that are identical, and yet you only
work on one device, that feels like a design flaw somewhere :)

thanks,

greg k-h

Re: [RFC PATCH v1 00/11] Manage the top tier memory in a tiered memory

[Yang Shi]

On Thu, Apr 8, 2021 at 10:19 AM Shakeel Butt  wrote:
>
> Hi Tim,
>
> On Mon, Apr 5, 2021 at 11:08 AM Tim Chen  wrote:
> >
> > Traditionally, all memory is DRAM.  Some DRAM might be closer/faster than
> > others NUMA wise, but a byte of media has about the same cost whether it
> > is close or far.  But, with new memory tiers such as Persistent Memory
> > (PMEM).  there is a choice between fast/expensive DRAM and slow/cheap
> > PMEM.
> >
> > The fast/expensive memory lives in the top tier of the memory hierachy.
> >
> > Previously, the patchset
> > [PATCH 00/10] [v7] Migrate Pages in lieu of discard
> > https://lore.kernel.org/linux-mm/20210401183216.443c4...@viggo.jf.intel.com/
> > provides a mechanism to demote cold pages from DRAM node into PMEM.
> >
> > And the patchset
> > [PATCH 0/6] [RFC v6] NUMA balancing: optimize memory placement for memory 
> > tiering system
> > https://lore.kernel.org/linux-mm/20210311081821.138467-1-ying.hu...@intel.com/
> > provides a mechanism to promote hot pages in PMEM to the DRAM node
> > leveraging autonuma.
> >
> > The two patchsets together keep the hot pages in DRAM and colder pages
> > in PMEM.
>
> Thanks for working on this as this is becoming more and more important
> particularly in the data centers where memory is a big portion of the
> cost.
>
> I see you have responded to Michal and I will add my more specific
> response there. Here I wanted to give my high level concern regarding
> using v1's soft limit like semantics for top tier memory.
>
> This patch series aims to distribute/partition top tier memory between
> jobs of different priorities. We want high priority jobs to have
> preferential access to the top tier memory and we don't want low
> priority jobs to hog the top tier memory.
>
> Using v1's soft limit like behavior can potentially cause high
> priority jobs to stall to make enough space on top tier memory on
> their allocation path and I think this patchset is aiming to reduce
> that impact by making kswapd do that work. However I think the more
> concerning issue is the low priority job hogging the top tier memory.
>
> The possible ways the low priority job can hog the top tier memory are
> by allocating non-movable memory or by mlocking the memory. (Oh there
> is also pinning the memory but I don't know if there is a user api to
> pin memory?) For the mlocked memory, you need to either modify the
> reclaim code or use a different mechanism for demoting cold memory.

Do you mean long term pin? RDMA should be able to simply pin the
memory for weeks. A lot of transient pins come from Direct I/O. They
should be less concerned.

The low priority jobs should be able to be restricted by cpuset, for
example, just keep them on second tier memory nodes. Then all the
above problems are gone.

>
> Basically I am saying we should put the upfront control (limit) on the
> usage of top tier memory by the jobs.

This sounds similar to what I talked about in LSFMM 2019
(https://lwn.net/Articles/787418/). We used to have some potential
usecase which divides DRAM:PMEM ratio for different jobs or memcgs
when I was with Alibaba.

In the first place I thought about per NUMA node limit, but it was
very hard to configure it correctly for users unless you know exactly
about your memory usage and hot/cold memory distribution.

I'm wondering, just off the top of my head, if we could extend the
semantic of low and min limit. For example, just redefine low and min
to "the limit on top tier memory". Then we could have low priority
jobs have 0 low/min limit.

>

[PATCH] export: Make CRCs robust to symbol trimming

[Quentin Perret]

The CRC calculation done by genksyms is triggered when the parser hits
EXPORT_SYMBOL*() macros. At this point, genksyms recursively expands the
types, and uses that as the input for the CRC calculation. In the case
of forward-declared structs, the type expands to 'UNKNOWN'. Next, the
result of the expansion of each type is cached, and is re-used when/if
the same type is seen again for another exported symbol in the file.

Unfortunately, this can cause CRC 'stability' issues when a struct
definition becomes visible in the middle of a C file. For example, let's
assume code with the following pattern:

struct foo;

int bar(struct foo *arg)
{
/* Do work ... */
}
EXPORT_SYMBOL_GPL(bar);

/* This contains struct foo's definition */
#include "foo.h"

int baz(struct foo *arg)
{
/* Do more work ... */
}
EXPORT_SYMBOL_GPL(baz);

Here, baz's CRC will be computed using the expansion of struct foo that
was cached after bar's CRC calculation ('UNKOWN' here). But if
EXPORT_SYMBOL_GPL(bar) is removed from the file (because of e.g. symbol
trimming using CONFIG_TRIM_UNUSED_KSYMS), struct foo will be expanded
late, during baz's CRC calculation, which now has visibility over the
full struct definition, hence resulting in a different CRC for baz.

This can cause annoying issues for distro kernel (such as the Android
Generic Kernel Image) which use CONFIG_UNUSED_KSYMS_WHITELIST. Indeed,
as per the above, adding a symbol to the whitelist can change the CRC of
symbols that are already kept exported. As such, modules built against a
kernel with a trimmed ABI may not load against the same kernel built
with an extended whitelist, even though they are still strictly binary
compatible. While rebuilding the modules would obviously solve the
issue, I believe this classifies as an odd genksyms corner case, and it
gets in the way of kernel updates in the GKI context.

To work around the issue, make sure to keep issuing the
__GENKSYMS_EXPORT_SYMBOL macros for all trimmed symbols, hence making
the genksyms parsing insensitive to symbol trimming.

Signed-off-by: Quentin Perret 
---
 include/linux/export.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/export.h b/include/linux/export.h
index 6271a5d9c988..27d848712b90 100644
--- a/include/linux/export.h
+++ b/include/linux/export.h
@@ -140,7 +140,12 @@ struct kernel_symbol {
 #define ___cond_export_sym(sym, sec, ns, enabled)  \
__cond_export_sym_##enabled(sym, sec, ns)
 #define __cond_export_sym_1(sym, sec, ns) ___EXPORT_SYMBOL(sym, sec, ns)
+
+#ifdef __GENKSYMS__
+#define __cond_export_sym_0(sym, sec, ns) __GENKSYMS_EXPORT_SYMBOL(sym)
+#else
 #define __cond_export_sym_0(sym, sec, ns) /* nothing */
+#endif
 
 #else
 
-- 
2.31.0.208.g409f899ff0-goog

Re: [PATCH 00/13] tty.h cleanups

[Greg Kroah-Hartman]

On Thu, Apr 08, 2021 at 04:25:22PM +0200, Johan Hovold wrote:
> On Thu, Apr 08, 2021 at 02:51:21PM +0200, Greg Kroah-Hartman wrote:
> > Turns out there is a lot of tty-internal stuff in include/linux/tty.h
> > that do not belong there.  Create a internal-to-the-tty-layer .h file
> > for these types of things and move function prototypes to it instead of
> > being in the system-wide header file.
> > 
> > Along the way clean up the use of some old tty-only debugging macros and
> > use the in-kernel dev_*() calls instead.
> 
> I'm afraid that's not a good idea since not all ttys have a
> corresponding class device. Notable exception include pseudo terminals
> and serdev.
> 
> While dev_printk() can handle a NULL device argument without crashing,
> we'll actually lose log information by removing the tty printk helpers.

I think the same info will be printed here as before, just some NULL
information at the beginning, right?  And the benifits overall (for real
tty devices), should outweigh the few devices that do not have this
information.

But let me run some tests, on those devices to see just how this
looks...

thanks,

greg k-h

RE: [PATCH net-next v3 2/2] misc: Add Renesas Synchronization Management Unit (SMU) support

[Min Li]

> 
> That does not make sense, this is only one kernel module, with one .h file in
> this patch, I do not see those other files you are talking about...
> 
> And if you have named registers that are identical, and yet you only work on
> one device, that feels like a design flaw somewhere :)
> 

Hi Greg, the register files are in the 1/2 patch for the mfd part of the 
change. 
The reason they have same named register is because they are all 
synchronization 
devices and they share some similar features

[PATCH v6 09/18] treewide: Change list_sort to use const pointers

[Sami Tolvanen]

list_sort() internally casts the comparison function passed to it
to a different type with constant struct list_head pointers, and
uses this pointer to call the functions, which trips indirect call
Control-Flow Integrity (CFI) checking.

Instead of removing the consts, this change defines the
list_cmp_func_t type and changes the comparison function types of
all list_sort() callers to use const pointers, thus avoiding type
mismatches.

Suggested-by: Nick Desaulniers 
Signed-off-by: Sami Tolvanen 
Reviewed-by: Nick Desaulniers 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Kees Cook 
Tested-by: Nick Desaulniers 
Tested-by: Nathan Chancellor 
---
 arch/arm64/kvm/vgic/vgic-its.c  |  8 
 arch/arm64/kvm/vgic/vgic.c  |  3 ++-
 block/blk-mq-sched.c|  3 ++-
 block/blk-mq.c  |  3 ++-
 drivers/acpi/nfit/core.c|  3 ++-
 drivers/acpi/numa/hmat.c|  3 ++-
 drivers/clk/keystone/sci-clk.c  |  4 ++--
 drivers/gpu/drm/drm_modes.c |  3 ++-
 drivers/gpu/drm/i915/gt/intel_engine_user.c |  3 ++-
 drivers/gpu/drm/i915/gvt/debugfs.c  |  2 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c   |  3 ++-
 drivers/gpu/drm/radeon/radeon_cs.c  |  4 ++--
 .../hw/usnic/usnic_uiom_interval_tree.c |  3 ++-
 drivers/interconnect/qcom/bcm-voter.c   |  2 +-
 drivers/md/raid5.c  |  3 ++-
 drivers/misc/sram.c |  4 ++--
 drivers/nvme/host/core.c|  3 ++-
 .../pci/controller/cadence/pcie-cadence-host.c  |  3 ++-
 drivers/spi/spi-loopback-test.c |  3 ++-
 fs/btrfs/raid56.c   |  3 ++-
 fs/btrfs/tree-log.c |  3 ++-
 fs/btrfs/volumes.c  |  3 ++-
 fs/ext4/fsmap.c |  4 ++--
 fs/gfs2/glock.c |  3 ++-
 fs/gfs2/log.c   |  2 +-
 fs/gfs2/lops.c  |  3 ++-
 fs/iomap/buffered-io.c  |  3 ++-
 fs/ubifs/gc.c   |  7 ---
 fs/ubifs/replay.c   |  4 ++--
 fs/xfs/scrub/bitmap.c   |  4 ++--
 fs/xfs/xfs_bmap_item.c  |  4 ++--
 fs/xfs/xfs_buf.c|  6 +++---
 fs/xfs/xfs_extent_busy.c|  4 ++--
 fs/xfs/xfs_extent_busy.h|  3 ++-
 fs/xfs/xfs_extfree_item.c   |  4 ++--
 fs/xfs/xfs_refcount_item.c  |  4 ++--
 fs/xfs/xfs_rmap_item.c  |  4 ++--
 include/linux/list_sort.h   |  7 ---
 lib/list_sort.c | 17 ++---
 lib/test_list_sort.c|  3 ++-
 net/tipc/name_table.c   |  4 ++--
 41 files changed, 90 insertions(+), 72 deletions(-)

diff --git a/arch/arm64/kvm/vgic/vgic-its.c b/arch/arm64/kvm/vgic/vgic-its.c
index 40cbaca81333..b9518f94bd43 100644
--- a/arch/arm64/kvm/vgic/vgic-its.c
+++ b/arch/arm64/kvm/vgic/vgic-its.c
@@ -2190,8 +2190,8 @@ static int vgic_its_restore_ite(struct vgic_its *its, u32 
event_id,
return offset;
 }
 
-static int vgic_its_ite_cmp(void *priv, struct list_head *a,
-   struct list_head *b)
+static int vgic_its_ite_cmp(void *priv, const struct list_head *a,
+   const struct list_head *b)
 {
struct its_ite *itea = container_of(a, struct its_ite, ite_list);
struct its_ite *iteb = container_of(b, struct its_ite, ite_list);
@@ -2329,8 +2329,8 @@ static int vgic_its_restore_dte(struct vgic_its *its, u32 
id,
return offset;
 }
 
-static int vgic_its_device_cmp(void *priv, struct list_head *a,
-  struct list_head *b)
+static int vgic_its_device_cmp(void *priv, const struct list_head *a,
+  const struct list_head *b)
 {
struct its_device *deva = container_of(a, struct its_device, dev_list);
struct its_device *devb = container_of(b, struct its_device, dev_list);
diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
index 1c597c9885fa..15b666200f0b 100644
--- a/arch/arm64/kvm/vgic/vgic.c
+++ b/arch/arm64/kvm/vgic/vgic.c
@@ -255,7 +255,8 @@ static struct kvm_vcpu *vgic_target_oracle(struct vgic_irq 
*irq)
  * Return negative if "a" sorts before "b", 0 to preserve order, and positive
  * to sort "b" before "a".
  */
-static int vgic_irq_cmp(void *priv, struct list_head *a, struct list_head *b)
+static int vgic_irq_cmp(void *priv, const struct list_head *a,
+   const struct list_head *b)
 {
struct vgic_irq *irqa = container_of(a, struct vgic_irq, ap_list);
struct 

[PATCH v6 07/18] kallsyms: strip ThinLTO hashes from static functions

[Sami Tolvanen]

With CONFIG_CFI_CLANG and ThinLTO, Clang appends a hash to the names
of all static functions not marked __used. This can break userspace
tools that don't expect the function name to change, so strip out the
hash from the output.

Suggested-by: Jack Pham 
Signed-off-by: Sami Tolvanen 
Reviewed-by: Kees Cook 
Tested-by: Nathan Chancellor 
---
 kernel/kallsyms.c | 55 ++-
 1 file changed, 50 insertions(+), 5 deletions(-)

diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 8043a90aa50e..c851ca0ed357 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -161,6 +161,27 @@ static unsigned long kallsyms_sym_address(int idx)
return kallsyms_relative_base - 1 - kallsyms_offsets[idx];
 }
 
+#if defined(CONFIG_CFI_CLANG) && defined(CONFIG_LTO_CLANG_THIN)
+/*
+ * LLVM appends a hash to static function names when ThinLTO and CFI are
+ * both enabled, i.e. foo() becomes foo$707af9a22804d33c81801f27dcfe489b.
+ * This causes confusion and potentially breaks user space tools, so we
+ * strip the suffix from expanded symbol names.
+ */
+static inline bool cleanup_symbol_name(char *s)
+{
+   char *res;
+
+   res = strrchr(s, '$');
+   if (res)
+   *res = '\0';
+
+   return res != NULL;
+}
+#else
+static inline bool cleanup_symbol_name(char *s) { return false; }
+#endif
+
 /* Lookup the address for this symbol. Returns 0 if not found. */
 unsigned long kallsyms_lookup_name(const char *name)
 {
@@ -173,6 +194,9 @@ unsigned long kallsyms_lookup_name(const char *name)
 
if (strcmp(namebuf, name) == 0)
return kallsyms_sym_address(i);
+
+   if (cleanup_symbol_name(namebuf) && strcmp(namebuf, name) == 0)
+   return kallsyms_sym_address(i);
}
return module_kallsyms_lookup_name(name);
 }
@@ -303,7 +327,9 @@ const char *kallsyms_lookup(unsigned long addr,
   namebuf, KSYM_NAME_LEN);
if (modname)
*modname = NULL;
-   return namebuf;
+
+   ret = namebuf;
+   goto found;
}
 
/* See if it's in a module or a BPF JITed image. */
@@ -316,11 +342,16 @@ const char *kallsyms_lookup(unsigned long addr,
if (!ret)
ret = ftrace_mod_address_lookup(addr, symbolsize,
offset, modname, namebuf);
+
+found:
+   cleanup_symbol_name(namebuf);
return ret;
 }
 
 int lookup_symbol_name(unsigned long addr, char *symname)
 {
+   int res;
+
symname[0] = '\0';
symname[KSYM_NAME_LEN - 1] = '\0';
 
@@ -331,15 +362,23 @@ int lookup_symbol_name(unsigned long addr, char *symname)
/* Grab name */
kallsyms_expand_symbol(get_symbol_offset(pos),
   symname, KSYM_NAME_LEN);
-   return 0;
+   goto found;
}
/* See if it's in a module. */
-   return lookup_module_symbol_name(addr, symname);
+   res = lookup_module_symbol_name(addr, symname);
+   if (res)
+   return res;
+
+found:
+   cleanup_symbol_name(symname);
+   return 0;
 }
 
 int lookup_symbol_attrs(unsigned long addr, unsigned long *size,
unsigned long *offset, char *modname, char *name)
 {
+   int res;
+
name[0] = '\0';
name[KSYM_NAME_LEN - 1] = '\0';
 
@@ -351,10 +390,16 @@ int lookup_symbol_attrs(unsigned long addr, unsigned long 
*size,
kallsyms_expand_symbol(get_symbol_offset(pos),
   name, KSYM_NAME_LEN);
modname[0] = '\0';
-   return 0;
+   goto found;
}
/* See if it's in a module. */
-   return lookup_module_symbol_attrs(addr, size, offset, modname, name);
+   res = lookup_module_symbol_attrs(addr, size, offset, modname, name);
+   if (res)
+   return res;
+
+found:
+   cleanup_symbol_name(name);
+   return 0;
 }
 
 /* Look up a kernel symbol and return it in a text buffer. */
-- 
2.31.1.295.g9ea45b61b8-goog

[PATCH v6 08/18] bpf: disable CFI in dispatcher functions

[Sami Tolvanen]

BPF dispatcher functions are patched at runtime to perform direct
instead of indirect calls. Disable CFI for the dispatcher functions to
avoid conflicts.

Signed-off-by: Sami Tolvanen 
Reviewed-by: Kees Cook 
Tested-by: Nathan Chancellor 
---
 include/linux/bpf.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 3625f019767d..2f46f98479e1 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -650,7 +650,7 @@ struct bpf_dispatcher {
struct bpf_ksym ksym;
 };
 
-static __always_inline unsigned int bpf_dispatcher_nop_func(
+static __always_inline __nocfi unsigned int bpf_dispatcher_nop_func(
const void *ctx,
const struct bpf_insn *insnsi,
unsigned int (*bpf_func)(const void *,
@@ -678,7 +678,7 @@ void bpf_trampoline_put(struct bpf_trampoline *tr);
 }
 
 #define DEFINE_BPF_DISPATCHER(name)\
-   noinline unsigned int bpf_dispatcher_##name##_func( \
+   noinline __nocfi unsigned int bpf_dispatcher_##name##_func( \
const void *ctx,\
const struct bpf_insn *insnsi,  \
unsigned int (*bpf_func)(const void *,  \
-- 
2.31.1.295.g9ea45b61b8-goog

[PATCH v6 12/18] arm64: implement function_nocfi

[Sami Tolvanen]

With CONFIG_CFI_CLANG, the compiler replaces function addresses in
instrumented C code with jump table addresses. This change implements
the function_nocfi() macro, which returns the actual function address
instead.

Signed-off-by: Sami Tolvanen 
Reviewed-by: Kees Cook 
Acked-by: Mark Rutland 
Tested-by: Nathan Chancellor 
---
 arch/arm64/include/asm/memory.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
index 0aabc3be9a75..3a6f9df63606 100644
--- a/arch/arm64/include/asm/memory.h
+++ b/arch/arm64/include/asm/memory.h
@@ -321,6 +321,22 @@ static inline void *phys_to_virt(phys_addr_t x)
 #define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys((unsigned 
long)(x)))
 #define sym_to_pfn(x)  __phys_to_pfn(__pa_symbol(x))
 
+#ifdef CONFIG_CFI_CLANG
+/*
+ * With CONFIG_CFI_CLANG, the compiler replaces function address
+ * references with the address of the function's CFI jump table
+ * entry. The function_nocfi macro always returns the address of the
+ * actual function instead.
+ */
+#define function_nocfi(x) ({   \
+   void *addr; \
+   asm("adrp %0, " __stringify(x) "\n\t"   \
+   "add  %0, %0, :lo12:" __stringify(x)\
+   : "=r" (addr)); \
+   addr;   \
+})
+#endif
+
 /*
  *  virt_to_page(x)convert a _valid_ virtual address to struct page *
  *  virt_addr_valid(x) indicates whether a virtual address is valid
-- 
2.31.1.295.g9ea45b61b8-goog

[PATCH v6 11/18] psci: use function_nocfi for cpu_resume

[Sami Tolvanen]

With CONFIG_CFI_CLANG, the compiler replaces function pointers with
jump table addresses, which results in __pa_symbol returning the
physical address of the jump table entry. As the jump table contains
an immediate jump to an EL1 virtual address, this typically won't
work as intended. Use function_nocfi to get the actual address of
cpu_resume.

Signed-off-by: Sami Tolvanen 
Reviewed-by: Kees Cook 
Acked-by: Mark Rutland 
Tested-by: Nathan Chancellor 
---
 drivers/firmware/psci/psci.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/psci/psci.c b/drivers/firmware/psci/psci.c
index f5fc429cae3f..64344e84bd63 100644
--- a/drivers/firmware/psci/psci.c
+++ b/drivers/firmware/psci/psci.c
@@ -325,8 +325,9 @@ static int __init psci_features(u32 psci_func_id)
 static int psci_suspend_finisher(unsigned long state)
 {
u32 power_state = state;
+   phys_addr_t pa_cpu_resume = __pa_symbol(function_nocfi(cpu_resume));
 
-   return psci_ops.cpu_suspend(power_state, __pa_symbol(cpu_resume));
+   return psci_ops.cpu_suspend(power_state, pa_cpu_resume);
 }
 
 int psci_cpu_suspend_enter(u32 state)
@@ -344,8 +345,10 @@ int psci_cpu_suspend_enter(u32 state)
 
 static int psci_system_suspend(unsigned long unused)
 {
+   phys_addr_t pa_cpu_resume = __pa_symbol(function_nocfi(cpu_resume));
+
return invoke_psci_fn(PSCI_FN_NATIVE(1_0, SYSTEM_SUSPEND),
- __pa_symbol(cpu_resume), 0, 0);
+ pa_cpu_resume, 0, 0);
 }
 
 static int psci_system_suspend_enter(suspend_state_t state)
-- 
2.31.1.295.g9ea45b61b8-goog

[PATCH v6 13/18] arm64: use function_nocfi with __pa_symbol

[Sami Tolvanen]

With CONFIG_CFI_CLANG, the compiler replaces function address
references with the address of the function's CFI jump table
entry. This means that __pa_symbol(function) returns the physical
address of the jump table entry, which can lead to address space
confusion as the jump table points to the function's virtual
address. Therefore, use the function_nocfi() macro to ensure we are
always taking the address of the actual function instead.

Signed-off-by: Sami Tolvanen 
Reviewed-by: Kees Cook 
Acked-by: Mark Rutland 
Tested-by: Nathan Chancellor 
---
 arch/arm64/include/asm/mmu_context.h  | 2 +-
 arch/arm64/kernel/acpi_parking_protocol.c | 3 ++-
 arch/arm64/kernel/cpu-reset.h | 2 +-
 arch/arm64/kernel/cpufeature.c| 2 +-
 arch/arm64/kernel/psci.c  | 3 ++-
 arch/arm64/kernel/smp_spin_table.c| 3 ++-
 6 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/mmu_context.h 
b/arch/arm64/include/asm/mmu_context.h
index bd02e99b1a4c..386b96400a57 100644
--- a/arch/arm64/include/asm/mmu_context.h
+++ b/arch/arm64/include/asm/mmu_context.h
@@ -140,7 +140,7 @@ static inline void cpu_replace_ttbr1(pgd_t *pgdp)
ttbr1 |= TTBR_CNP_BIT;
}
 
-   replace_phys = (void *)__pa_symbol(idmap_cpu_replace_ttbr1);
+   replace_phys = (void 
*)__pa_symbol(function_nocfi(idmap_cpu_replace_ttbr1));
 
cpu_install_idmap();
replace_phys(ttbr1);
diff --git a/arch/arm64/kernel/acpi_parking_protocol.c 
b/arch/arm64/kernel/acpi_parking_protocol.c
index e7c941d8340d..bfeeb5319abf 100644
--- a/arch/arm64/kernel/acpi_parking_protocol.c
+++ b/arch/arm64/kernel/acpi_parking_protocol.c
@@ -99,7 +99,8 @@ static int acpi_parking_protocol_cpu_boot(unsigned int cpu)
 * that read this address need to convert this address to the
 * Boot-Loader's endianness before jumping.
 */
-   writeq_relaxed(__pa_symbol(secondary_entry), >entry_point);
+   writeq_relaxed(__pa_symbol(function_nocfi(secondary_entry)),
+  >entry_point);
writel_relaxed(cpu_entry->gic_cpu_id, >cpu_id);
 
arch_send_wakeup_ipi_mask(cpumask_of(cpu));
diff --git a/arch/arm64/kernel/cpu-reset.h b/arch/arm64/kernel/cpu-reset.h
index ed50e9587ad8..f3adc574f969 100644
--- a/arch/arm64/kernel/cpu-reset.h
+++ b/arch/arm64/kernel/cpu-reset.h
@@ -22,7 +22,7 @@ static inline void __noreturn cpu_soft_restart(unsigned long 
entry,
 
unsigned long el2_switch = !is_kernel_in_hyp_mode() &&
is_hyp_mode_available();
-   restart = (void *)__pa_symbol(__cpu_soft_restart);
+   restart = (void *)__pa_symbol(function_nocfi(__cpu_soft_restart));
 
cpu_install_idmap();
restart(el2_switch, entry, arg0, arg1, arg2);
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index e5281e1c8f1d..0b2e0d7b13ec 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -1462,7 +1462,7 @@ kpti_install_ng_mappings(const struct 
arm64_cpu_capabilities *__unused)
if (arm64_use_ng_mappings)
return;
 
-   remap_fn = (void *)__pa_symbol(idmap_kpti_install_ng_mappings);
+   remap_fn = (void 
*)__pa_symbol(function_nocfi(idmap_kpti_install_ng_mappings));
 
cpu_install_idmap();
remap_fn(cpu, num_online_cpus(), __pa_symbol(swapper_pg_dir));
diff --git a/arch/arm64/kernel/psci.c b/arch/arm64/kernel/psci.c
index 62d2bda7adb8..ab7f4c476104 100644
--- a/arch/arm64/kernel/psci.c
+++ b/arch/arm64/kernel/psci.c
@@ -38,7 +38,8 @@ static int __init cpu_psci_cpu_prepare(unsigned int cpu)
 
 static int cpu_psci_cpu_boot(unsigned int cpu)
 {
-   int err = psci_ops.cpu_on(cpu_logical_map(cpu), 
__pa_symbol(secondary_entry));
+   phys_addr_t pa_secondary_entry = 
__pa_symbol(function_nocfi(secondary_entry));
+   int err = psci_ops.cpu_on(cpu_logical_map(cpu), pa_secondary_entry);
if (err)
pr_err("failed to boot CPU%d (%d)\n", cpu, err);
 
diff --git a/arch/arm64/kernel/smp_spin_table.c 
b/arch/arm64/kernel/smp_spin_table.c
index 056772c26098..c45a83512805 100644
--- a/arch/arm64/kernel/smp_spin_table.c
+++ b/arch/arm64/kernel/smp_spin_table.c
@@ -66,6 +66,7 @@ static int smp_spin_table_cpu_init(unsigned int cpu)
 static int smp_spin_table_cpu_prepare(unsigned int cpu)
 {
__le64 __iomem *release_addr;
+   phys_addr_t pa_holding_pen = 
__pa_symbol(function_nocfi(secondary_holding_pen));
 
if (!cpu_release_addr[cpu])
return -ENODEV;
@@ -88,7 +89,7 @@ static int smp_spin_table_cpu_prepare(unsigned int cpu)
 * boot-loader's endianness before jumping. This is mandated by
 * the boot protocol.
 */
-   writeq_relaxed(__pa_symbol(secondary_holding_pen), release_addr);
+   writeq_relaxed(pa_holding_pen, release_addr);
__flush_dcache_area((__force void *)release_addr,
sizeof(*release_addr));
 

[PATCH v6 10/18] lkdtm: use function_nocfi

[Sami Tolvanen]

To ensure we take the actual address of a function in kernel text,
use function_nocfi. Otherwise, with CONFIG_CFI_CLANG, the compiler
replaces the address with a pointer to the CFI jump table, which is
actually in the module when compiled with CONFIG_LKDTM=m.

Signed-off-by: Sami Tolvanen 
Acked-by: Kees Cook 
Tested-by: Nathan Chancellor 
---
 drivers/misc/lkdtm/usercopy.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/lkdtm/usercopy.c b/drivers/misc/lkdtm/usercopy.c
index 109e8d4302c1..15d220ef35a5 100644
--- a/drivers/misc/lkdtm/usercopy.c
+++ b/drivers/misc/lkdtm/usercopy.c
@@ -314,7 +314,7 @@ void lkdtm_USERCOPY_KERNEL(void)
 
pr_info("attempting bad copy_to_user from kernel text: %px\n",
vm_mmap);
-   if (copy_to_user((void __user *)user_addr, vm_mmap,
+   if (copy_to_user((void __user *)user_addr, function_nocfi(vm_mmap),
 unconst + PAGE_SIZE)) {
pr_warn("copy_to_user failed, but lacked Oops\n");
goto free_user;
-- 
2.31.1.295.g9ea45b61b8-goog

[PATCH net v2 1/2] net: dsa: lantiq_gswip: Don't use PHY auto polling

[Martin Blumenstingl]

PHY auto polling on the GSWIP hardware can be used so link changes
(speed, link up/down, etc.) can be detected automatically. Internally
GSWIP reads the PHY's registers for this functionality. Based on this
automatic detection GSWIP can also automatically re-configure it's port
settings. Unfortunately this auto polling (and configuration) mechanism
seems to cause various issues observed by different people on different
devices:
- FritzBox 7360v2: the two Gbit/s ports (connected to the two internal
  PHY11G instances) are working fine but the two Fast Ethernet ports
  (using an AR8030 RMII PHY) are completely dead (neither RX nor TX are
  received). It turns out that the AR8030 PHY sets the BMSR_ESTATEN bit
  as well as the ESTATUS_1000_TFULL and ESTATUS_1000_XFULL bits. This
  makes the PHY auto polling state machine (rightfully?) think that the
  established link speed (when the other side is Gbit/s capable) is
  1Gbit/s.
- None of the Ethernet ports on the Zyxel P-2812HNU-F1 (two are
  connected to the internal PHY11G GPHYs while the other three are
  external RGMII PHYs) are working. Neither RX nor TX traffic was
  observed. It is not clear which part of the PHY auto polling state-
  machine caused this.
- FritzBox 7412 (only one LAN port which is connected to one of the
  internal GPHYs running in PHY22F / Fast Ethernet mode) was seeing
  random disconnects (link down events could be seen). Sometimes all
  traffic would stop after such disconnect. It is not clear which part
  of the PHY auto polling state-machine cauased this.
- TP-Link TD-W9980 (two ports are connected to the internal GPHYs
  running in PHY11G / Gbit/s mode, the other two are external RGMII
  PHYs) was affected by similar issues as the FritzBox 7412 just without
  the "link down" events

Switch to software based configuration instead of PHY auto polling (and
letting the GSWIP hardware configure the ports automatically) for the
following link parameters:
- link up/down
- link speed
- full/half duplex
- flow control (RX / TX pause)

After a big round of manual testing by various people (who helped test
this on OpenWrt) it turns out that this fixes all reported issues.

Additionally it can be considered more future proof because any
"quirk" which is implemented for a PHY on the driver side can now be
used with the GSWIP hardware as well because Linux is in control of the
link parameters.

As a nice side-effect this also solves a problem where fixed-links were
not supported previously because we were relying on the PHY auto polling
mechanism, which cannot work for fixed-links as there's no PHY from
where it can read the registers. Configuring the link settings on the
GSWIP ports means that we now use the settings from device-tree also for
ports with fixed-links.

Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Fixes: 3e6fdeb28f4c33 ("net: dsa: lantiq_gswip: Let GSWIP automatically set the 
xMII clock")
Cc: sta...@vger.kernel.org
Acked-by: Hauke Mehrtens 
Reviewed-by: Andrew Lunn 
Signed-off-by: Martin Blumenstingl 
---
 drivers/net/dsa/lantiq_gswip.c | 185 -
 1 file changed, 159 insertions(+), 26 deletions(-)

diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 809dfa3be6bb..126d4ea868ba 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -190,6 +190,23 @@
 #define GSWIP_PCE_DEFPVID(p)   (0x486 + ((p) * 0xA))
 
 #define GSWIP_MAC_FLEN 0x8C5
+#define GSWIP_MAC_CTRL_0p(p)   (0x903 + ((p) * 0xC))
+#define  GSWIP_MAC_CTRL_0_PADENBIT(8)
+#define  GSWIP_MAC_CTRL_0_FCS_EN   BIT(7)
+#define  GSWIP_MAC_CTRL_0_FCON_MASK0x0070
+#define  GSWIP_MAC_CTRL_0_FCON_AUTO0x
+#define  GSWIP_MAC_CTRL_0_FCON_RX  0x0010
+#define  GSWIP_MAC_CTRL_0_FCON_TX  0x0020
+#define  GSWIP_MAC_CTRL_0_FCON_RXTX0x0030
+#define  GSWIP_MAC_CTRL_0_FCON_NONE0x0040
+#define  GSWIP_MAC_CTRL_0_FDUP_MASK0x000C
+#define  GSWIP_MAC_CTRL_0_FDUP_AUTO0x
+#define  GSWIP_MAC_CTRL_0_FDUP_EN  0x0004
+#define  GSWIP_MAC_CTRL_0_FDUP_DIS 0x000C
+#define  GSWIP_MAC_CTRL_0_GMII_MASK0x0003
+#define  GSWIP_MAC_CTRL_0_GMII_AUTO0x
+#define  GSWIP_MAC_CTRL_0_GMII_MII 0x0001
+#define  GSWIP_MAC_CTRL_0_GMII_RGMII   0x0002
 #define GSWIP_MAC_CTRL_2p(p)   (0x905 + ((p) * 0xC))
 #define GSWIP_MAC_CTRL_2_MLEN  BIT(3) /* Maximum Untagged Frame Lnegth 
*/
 
@@ -653,16 +670,13 @@ static int gswip_port_enable(struct dsa_switch *ds, int 
port,
  GSWIP_SDMA_PCTRLp(port));
 
if (!dsa_is_cpu_port(ds, port)) {
-   u32 macconf = GSWIP_MDIO_PHY_LINK_AUTO |
- GSWIP_MDIO_PHY_SPEED_AUTO |
- GSWIP_MDIO_PHY_FDUP_AUTO |
- GSWIP_MDIO_PHY_FCONTX_AUTO |
- GSWIP_MDIO_PHY_FCONRX_AUTO |
- 

[PATCH net v2 2/2] net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits

[Martin Blumenstingl]

There are a few more bits in the GSWIP_MII_CFG register for which we
did rely on the boot-loader (or the hardware defaults) to set them up
properly.

For some external RMII PHYs we need to select the GSWIP_MII_CFG_RMII_CLK
bit and also we should un-set it for non-RMII PHYs. The
GSWIP_MII_CFG_RMII_CLK bit is ignored for other PHY connection modes.

The GSWIP IP also supports in-band auto-negotiation for RGMII PHYs when
the GSWIP_MII_CFG_RGMII_IBS bit is set. Clear this bit always as there's
no known hardware which uses this (so it is not tested yet).

Clear the xMII isolation bit when set at initialization time if it was
previously set by the bootloader. Not doing so could lead to no traffic
(neither RX nor TX) on a port with this bit set.

While here, also add the GSWIP_MII_CFG_RESET bit. We don't need to
manage it because this bit is self-clearning when set. We still add it
here to get a better overview of the GSWIP_MII_CFG register.

Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Cc: sta...@vger.kernel.org
Suggested-by: Hauke Mehrtens 
Acked-by: Hauke Mehrtens 
Signed-off-by: Martin Blumenstingl 
---
 drivers/net/dsa/lantiq_gswip.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 126d4ea868ba..bf5c62e5c0b0 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -93,8 +93,12 @@
 
 /* GSWIP MII Registers */
 #define GSWIP_MII_CFGp(p)  (0x2 * (p))
+#define  GSWIP_MII_CFG_RESET   BIT(15)
 #define  GSWIP_MII_CFG_EN  BIT(14)
+#define  GSWIP_MII_CFG_ISOLATE BIT(13)
 #define  GSWIP_MII_CFG_LDCLKDISBIT(12)
+#define  GSWIP_MII_CFG_RGMII_IBS   BIT(8)
+#define  GSWIP_MII_CFG_RMII_CLKBIT(7)
 #define  GSWIP_MII_CFG_MODE_MIIP   0x0
 #define  GSWIP_MII_CFG_MODE_MIIM   0x1
 #define  GSWIP_MII_CFG_MODE_RMIIP  0x2
@@ -821,9 +825,11 @@ static int gswip_setup(struct dsa_switch *ds)
/* Configure the MDIO Clock 2.5 MHz */
gswip_mdio_mask(priv, 0xff, 0x09, GSWIP_MDIO_MDC_CFG1);
 
-   /* Disable the xMII link */
+   /* Disable the xMII interface and clear it's isolation bit */
for (i = 0; i < priv->hw_info->max_ports; i++)
-   gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_EN, 0, i);
+   gswip_mii_mask_cfg(priv,
+  GSWIP_MII_CFG_EN | GSWIP_MII_CFG_ISOLATE,
+  0, i);
 
/* enable special tag insertion on cpu port */
gswip_switch_mask(priv, 0, GSWIP_FDMA_PCTRL_STEN,
@@ -1597,6 +1603,9 @@ static void gswip_phylink_mac_config(struct dsa_switch 
*ds, int port,
break;
case PHY_INTERFACE_MODE_RMII:
miicfg |= GSWIP_MII_CFG_MODE_RMIIM;
+
+   /* Configure the RMII clock as output: */
+   miicfg |= GSWIP_MII_CFG_RMII_CLK;
break;
case PHY_INTERFACE_MODE_RGMII:
case PHY_INTERFACE_MODE_RGMII_ID:
@@ -1609,7 +1618,11 @@ static void gswip_phylink_mac_config(struct dsa_switch 
*ds, int port,
"Unsupported interface: %d\n", state->interface);
return;
}
-   gswip_mii_mask_cfg(priv, GSWIP_MII_CFG_MODE_MASK, miicfg, port);
+
+   gswip_mii_mask_cfg(priv,
+  GSWIP_MII_CFG_MODE_MASK | GSWIP_MII_CFG_RMII_CLK |
+  GSWIP_MII_CFG_RGMII_IBS | GSWIP_MII_CFG_LDCLKDIS,
+  miicfg, port);
 
switch (state->interface) {
case PHY_INTERFACE_MODE_RGMII_ID:
-- 
2.31.1

Re: [PATCH v6 02/10] arm64: perf: Enable PMU counter direct access for perf event

[Rob Herring]

On Thu, Apr 8, 2021 at 6:08 AM Mark Rutland  wrote:
>
> On Wed, Apr 07, 2021 at 01:44:37PM +0100, Will Deacon wrote:
> > [Moving Mark to To: since I'd like his view on this]
> >
> > On Thu, Apr 01, 2021 at 02:45:21PM -0500, Rob Herring wrote:
> > > On Wed, Mar 31, 2021 at 11:01 AM Will Deacon  wrote:
> > > >
> > > > On Tue, Mar 30, 2021 at 12:09:38PM -0500, Rob Herring wrote:
> > > > > On Tue, Mar 30, 2021 at 10:31 AM Will Deacon  wrote:
> > > > > >
> > > > > > On Wed, Mar 10, 2021 at 05:08:29PM -0700, Rob Herring wrote:
> > > > > > > From: Raphael Gault 
>
> > > > > > > +static void armv8pmu_event_unmapped(struct perf_event *event, 
> > > > > > > struct mm_struct *mm)
> > > > > > > +{
> > > > > > > + struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
> > > > > > > +
> > > > > > > + if (!(event->hw.flags & ARMPMU_EL0_RD_CNTR))
> > > > > > > + return;
> > > > > > > +
> > > > > > > + if (atomic_dec_and_test(>context.pmu_direct_access))
> > > > > > > + on_each_cpu_mask(>supported_cpus, 
> > > > > > > refresh_pmuserenr, mm, 1);
> > > > > >
> > > > > > Given that the pmu_direct_access field is global per-mm, won't this 
> > > > > > go
> > > > > > wrong if multiple PMUs are opened by the same process but only a 
> > > > > > subset
> > > > > > are exposed to EL0? Perhaps pmu_direct_access should be treated as 
> > > > > > a mask
> > > > > > rather than a counter, so that we can 'and' it with the 
> > > > > > supported_cpus for
> > > > > > the PMU we're dealing with.
> > > > >
> > > > > It needs to be a count to support multiple events on the same PMU. If
> > > > > the event is not enabled for EL0, then we'd exit out on the
> > > > > ARMPMU_EL0_RD_CNTR check. So I think we're fine.
> > > >
> > > > I'm still not convinced; pmu_direct_access is shared between PMUs, so
> > > > testing the result of atomic_dec_and_test() just doesn't make sense to
> > > > me, as another PMU could be playing with the count.
> > >
> > > How is that a problem? Let's make a concrete example:
> > >
> > > map PMU1:event2 -> pmu_direct_access = 1 -> enable access
> > > map PMU2:event3 -> pmu_direct_access = 2
> > > map PMU1:event4 -> pmu_direct_access = 3
> > > unmap PMU2:event3 -> pmu_direct_access = 2
> > > unmap PMU1:event2 -> pmu_direct_access = 1
> > > unmap PMU1:event4 -> pmu_direct_access = 0 -> disable access
> > >
> > > The only issue I can see is PMU2 remains enabled for user access until
> > > the last unmap. But we're sharing the mm, so who cares? Also, in this
> > > scenario it is the user's problem to pin themselves to cores sharing a
> > > PMU. If the user doesn't do that, they get to keep the pieces.
> >
> > I guess I'm just worried about exposing the counters to userspace after
> > the PMU driver (or perf core?) thinks that they're no longer exposed in
> > case we leak other events.
>
> IMO that's not practically different from the single-PMU case (i.e.
> multi-PMU isn't material, either we have a concern with leaking or we
> don't); more on that below.
>
> While it looks odd to place this on the mm, I don't think it's the end
> of the world.
>
> > However, I'm not sure how this is supposed to work normally: what
> > happens if e.g. a privileged user has a per-cpu counter for a kernel
> > event while a task has a counter with direct access -- can that task
> > read the kernel event out of the PMU registers from userspace?
>
> Yes -- userspace could go read any counters even though it isn't
> supposed to, and could potentially infer information from those. It
> won't have access to the config registers or kernel data structures, so
> it isn't guaranteed to know what the even is or when it is
> context-switched/reprogrammed/etc.
>
> If we believe that's a problem, then it's difficult to do anything
> robust other than denying userspace access entirely, since disabling
> userspace access while in use would surprise applications, and denying
> privileged events would need some global state that we consult at event
> creation time (in addition to being an inversion of privilege).
>
> IIRC there was some fuss about this a while back on x86; I'll go dig and
> see what I can find, unless Peter has a memory...

Maybe this one[1].

Rob

[1] 
https://lore.kernel.org/lkml/20200730123815.18518-1-kan.li...@linux.intel.com/

Re: [PATCH] PCI: merge slot and bus reset implementations

[Raphael Norwitz]

On Wed, Apr 07, 2021 at 04:37:23PM +0300, Leon Romanovsky wrote:
> On Wed, Apr 07, 2021 at 06:36:01PM +0530, ameynarkhed...@gmail.com wrote:
> > On 21/04/07 03:30PM, Leon Romanovsky wrote:
> > > On Wed, Apr 07, 2021 at 01:53:56PM +0530, ameynarkhed...@gmail.com wrote:
> > > > On 21/04/07 10:23AM, Leon Romanovsky wrote:
> > > > > On Tue, Apr 06, 2021 at 08:16:26AM -0600, Alex Williamson wrote:
> > > > > > On Sun, 4 Apr 2021 11:04:32 +0300
> > > > > > Leon Romanovsky  wrote:
> > > > > >
> > > > > > > On Thu, Apr 01, 2021 at 10:56:16AM -0600, Alex Williamson wrote:
> > > > > > > > On Thu, 1 Apr 2021 15:27:37 +0300
> > > > > > > > Leon Romanovsky  wrote:
> > > > > > > >
> > > > > > > > > On Thu, Apr 01, 2021 at 05:37:16AM +, Raphael Norwitz 
> > > > > > > > > wrote:
> > > > > > > > > > Slot resets are bus resets with additional logic to prevent 
> > > > > > > > > > a device
> > > > > > > > > > from being removed during the reset. Currently slot and bus 
> > > > > > > > > > resets have
> > > > > > > > > > separate implementations in pci.c, complicating higher 
> > > > > > > > > > level logic. As
> > > > > > > > > > discussed on the mailing list, they should be combined into 
> > > > > > > > > > a generic
> > > > > > > > > > function which performs an SBR. This change adds a function,
> > > > > > > > > > pci_reset_bus_function(), which first attempts a slot reset 
> > > > > > > > > > and then
> > > > > > > > > > attempts a bus reset if -ENOTTY is returned, such that 
> > > > > > > > > > there is now a
> > > > > > > > > > single device agnostic function to perform an SBR.
> > > > > > > > > >
> > > > > > > > > > This new function is also needed to add SBR reset quirks 
> > > > > > > > > > and therefore
> > > > > > > > > > is exposed in pci.h.
> > > > > > > > > >
> > > > > > > > > > Link: 
> > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__lkml.org_lkml_2021_3_23_911=DwIBAg=s883GpUCOChKOHiocYtGcg=In4gmR1pGzKB8G5p6LUrWqkSMec2L5EtXZow_FZNJZk=dn12ruIb9lwgcFMNKBZzri1m3zoTBFlkHnrF48PChs4=iEm1FGjLlWUpKJQYMwCHc1crraEzAgN10pCzyEzbrWI=
> > > > > > > > > >  
> > > > > > > > > >
> > > > > > > > > > Suggested-by: Alex Williamson 
> > > > > > > > > > Signed-off-by: Amey Narkhede 
> > > > > > > > > > Signed-off-by: Raphael Norwitz 
> > > > > > > > > > ---
> > > > > > > > > >  drivers/pci/pci.c   | 17 +
> > > > > > > > > >  include/linux/pci.h |  1 +
> > > > > > > > > >  2 files changed, 10 insertions(+), 8 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > > > > > > > > > index 16a17215f633..12a91af2ade4 100644
> > > > > > > > > > --- a/drivers/pci/pci.c
> > > > > > > > > > +++ b/drivers/pci/pci.c
> > > > > > > > > > @@ -4982,6 +4982,13 @@ static int 
> > > > > > > > > > pci_dev_reset_slot_function(struct pci_dev *dev, int probe)
> > > > > > > > > > return pci_reset_hotplug_slot(dev->slot->hotplug, 
> > > > > > > > > > probe);
> > > > > > > > > >  }
> > > > > > > > > >
> > > > > > > > > > +int pci_reset_bus_function(struct pci_dev *dev, int probe)
> > > > > > > > > > +{
> > > > > > > > > > +   int rc = pci_dev_reset_slot_function(dev, probe);
> > > > > > > > > > +
> > > > > > > > > > +   return (rc == -ENOTTY) ? pci_parent_bus_reset(dev, 
> > > > > > > > > > probe) : rc;
> > > > > > > > >
> > > > > > > > > The previous coding style is preferable one in the Linux 
> > > > > > > > > kernel.
> > > > > > > > > int rc = pci_dev_reset_slot_function(dev, probe);
> > > > > > > > > if (rc != -ENOTTY)
> > > > > > > > >   return rc;
> > > > > > > > > return pci_parent_bus_reset(dev, probe);
> > > > > > > >
> > > > > > > >
> > > > > > > > That'd be news to me, do you have a reference?  I've never seen
> > > > > > > > complaints for ternaries previously.  Thanks,
> > > > > > >
> > > > > > > The complaint is not to ternaries, but to the function call as 
> > > > > > > one of
> > > > > > > the parameters, that makes it harder to read.
> > > > > >
> > > > > > Sorry, I don't find a function call as a parameter to a ternary to 
> > > > > > be
> > > > > > extraordinary, nor do I find it to be a discouraged usage model 
> > > > > > within
> > > > > > the kernel.  This seems like a pretty low bar for hard to read code.
> > > > >
> > > > > It is up to us where this bar is set.
> > > > >
> > > > > Thanks
> > > > On the side note there are plenty of places where this pattern is used
> > > > though
> > > > for example -
> > > > kernel/time/clockevents.c:328:
> > > > return force ? clockevents_program_min_delta(dev) : -ETIME;
> > > >
> > > > kernel/trace/trace_kprobe.c:233:
> > > > return tk ? within_error_injection_list(trace_kprobe_address(tk)) :
> > > >false;
> > > >
> > > > kernel/signal.c:3104:
> > > > return oset ? put_compat_sigset(oset, _set, sizeof(*oset)) : 0;
> > > > etc
> > >
> > > Did you look when they were introduced?
> > >
> > > Thanks
> > >
> > that code trace_kprobe in 2 years old.
> > If you want more recent example checkout

[PATCH net v2 0/2] lantiq: GSWIP: two more fixes

[Martin Blumenstingl]

Hello,

after my last patch got accepted and is now in net as commit
3e6fdeb28f4c33 ("net: dsa: lantiq_gswip: Let GSWIP automatically set
the xMII clock") [0] some more people from the OpenWrt community
(many thanks to everyone involved) helped test the GSWIP driver: [1]

It turns out that the previous fix does not work for all boards.
There's no regression, but it doesn't fix as many problems as I
thought. This is why two more fixes are needed:
- the first one solves many (four known but probably there are
  a few extra hidden ones) reported bugs with the GSWIP where no
  traffic would flow. Not all circumstances are fully understood
  but testing shows that switching away from PHY auto polling
  solves all of them
- while investigating the different problems which are addressed
  by the first patch some small issues with the existing code were
  found. These are addressed by the second patch


Changes since v1 at [0]:
- Don't configure the link parameters in gswip_phylink_mac_config
  (as we're using the "modern" way in gswip_phylink_mac_link_up).
  Thanks to Andrew for the hint with the phylink documentation.
- Clarify that GSWIP_MII_CFG_RMII_CLK is ignored by the hardware in
  the description of the second patch as suggested by Hauke
- Don't set GSWIP_MII_CFG_RGMII_IBS in the second patch as we don't
  have any hardware available for testing this. The patch
  description now also reflects this.
- Added Andrew's Reviewed-by to the first patch (thank you!)


Best regards,
Martin


[0] 
https://patchwork.kernel.org/project/netdevbpf/cover/20210406203508.476122-1-martin.blumensti...@googlemail.com/


Martin Blumenstingl (2):
  net: dsa: lantiq_gswip: Don't use PHY auto polling
  net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits

 drivers/net/dsa/lantiq_gswip.c | 202 -
 1 file changed, 174 insertions(+), 28 deletions(-)

-- 
2.31.1

[PATCH v2] gcov: re-fix clang-11+ support

[Nick Desaulniers]

LLVM changed the expected function signature for
llvm_gcda_emit_function() in the clang-11 release.  Users of clang-11 or
newer may have noticed their kernels producing invalid coverage
information:

$ llvm-cov gcov -a -c -u -f -b .gcda -- gcno=.gcno
1 : checksum mismatch, \
  (, ) != (, )
2 Invalid .gcda File!
...

Fix up the function signatures so calling this function interprets its
parameters correctly and computes the correct cfg checksum. In
particular, in clang-11, the additional checksum is no longer optional.

Link: https://reviews.llvm.org/rG25544ce2df0daa4304c07e64b9c8b0f7df60c11d
Cc: sta...@vger.kernel.org #5.4+
Reported-by: Prasad Sodagudi 
Tested-by: Prasad Sodagudi 
Signed-off-by: Nick Desaulniers 
Reviewed-by: Nathan Chancellor 
---
Changes V1 -> V2:
* Carried Nathan's reviewed-by tag.
* Rebased on mainline, as per Andrew.
* Left off patch 2/2 from the series
https://lore.kernel.org/lkml/20210407185456.41943-1-ndesaulni...@google.com/
  I assume that dropping support for clang-10+GCOV will be held
  separately for -next for 5.13, while this will be sent for 5.12?

 kernel/gcov/clang.c | 29 +++--
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/kernel/gcov/clang.c b/kernel/gcov/clang.c
index 8743150db2ac..c466c7fbdece 100644
--- a/kernel/gcov/clang.c
+++ b/kernel/gcov/clang.c
@@ -70,7 +70,9 @@ struct gcov_fn_info {
 
u32 ident;
u32 checksum;
+#if CONFIG_CLANG_VERSION < 11
u8 use_extra_checksum;
+#endif
u32 cfg_checksum;
 
u32 num_counters;
@@ -145,10 +147,8 @@ void llvm_gcda_emit_function(u32 ident, const char 
*function_name,
 
list_add_tail(>head, _info->functions);
 }
-EXPORT_SYMBOL(llvm_gcda_emit_function);
 #else
-void llvm_gcda_emit_function(u32 ident, u32 func_checksum,
-   u8 use_extra_checksum, u32 cfg_checksum)
+void llvm_gcda_emit_function(u32 ident, u32 func_checksum, u32 cfg_checksum)
 {
struct gcov_fn_info *info = kzalloc(sizeof(*info), GFP_KERNEL);
 
@@ -158,12 +158,11 @@ void llvm_gcda_emit_function(u32 ident, u32 func_checksum,
INIT_LIST_HEAD(>head);
info->ident = ident;
info->checksum = func_checksum;
-   info->use_extra_checksum = use_extra_checksum;
info->cfg_checksum = cfg_checksum;
list_add_tail(>head, _info->functions);
 }
-EXPORT_SYMBOL(llvm_gcda_emit_function);
 #endif
+EXPORT_SYMBOL(llvm_gcda_emit_function);
 
 void llvm_gcda_emit_arcs(u32 num_counters, u64 *counters)
 {
@@ -293,11 +292,16 @@ int gcov_info_is_compatible(struct gcov_info *info1, 
struct gcov_info *info2)
!list_is_last(_ptr2->head, >functions)) {
if (fn_ptr1->checksum != fn_ptr2->checksum)
return false;
+#if CONFIG_CLANG_VERSION < 11
if (fn_ptr1->use_extra_checksum != fn_ptr2->use_extra_checksum)
return false;
if (fn_ptr1->use_extra_checksum &&
fn_ptr1->cfg_checksum != fn_ptr2->cfg_checksum)
return false;
+#else
+   if (fn_ptr1->cfg_checksum != fn_ptr2->cfg_checksum)
+   return false;
+#endif
fn_ptr1 = list_next_entry(fn_ptr1, head);
fn_ptr2 = list_next_entry(fn_ptr2, head);
}
@@ -529,17 +533,22 @@ static size_t convert_to_gcda(char *buffer, struct 
gcov_info *info)
 
list_for_each_entry(fi_ptr, >functions, head) {
u32 i;
-   u32 len = 2;
-
-   if (fi_ptr->use_extra_checksum)
-   len++;
 
pos += store_gcov_u32(buffer, pos, GCOV_TAG_FUNCTION);
-   pos += store_gcov_u32(buffer, pos, len);
+#if CONFIG_CLANG_VERSION < 11
+   pos += store_gcov_u32(buffer, pos,
+   fi_ptr->use_extra_checksum ? 3 : 2);
+#else
+   pos += store_gcov_u32(buffer, pos, 3);
+#endif
pos += store_gcov_u32(buffer, pos, fi_ptr->ident);
pos += store_gcov_u32(buffer, pos, fi_ptr->checksum);
+#if CONFIG_CLANG_VERSION < 11
if (fi_ptr->use_extra_checksum)
pos += store_gcov_u32(buffer, pos, 
fi_ptr->cfg_checksum);
+#else
+   pos += store_gcov_u32(buffer, pos, fi_ptr->cfg_checksum);
+#endif
 
pos += store_gcov_u32(buffer, pos, GCOV_TAG_COUNTER_BASE);
pos += store_gcov_u32(buffer, pos, fi_ptr->num_counters * 2);

base-commit: 3fb4f979b4fa1f92a02b538ae86e725b73e703d0
-- 
2.31.1.295.g9ea45b61b8-goog

Re: memory leak in bpf

[Rustam Kovhaev]

On Wed, Apr 07, 2021 at 04:35:34PM -0700, Andrii Nakryiko wrote:
> On Wed, Apr 7, 2021 at 4:24 PM Rustam Kovhaev  wrote:
> >
> > On Mon, Mar 01, 2021 at 09:43:00PM +0100, Dmitry Vyukov wrote:
> > > On Mon, Mar 1, 2021 at 9:39 PM Rustam Kovhaev  wrote:
> > > >
> > > > On Mon, Mar 01, 2021 at 08:05:42PM +0100, Dmitry Vyukov wrote:
> > > > > On Mon, Mar 1, 2021 at 5:21 PM Rustam Kovhaev  
> > > > > wrote:
> > > > > >
> > > > > > On Wed, Dec 09, 2020 at 10:58:10PM -0800, syzbot wrote:
> > > > > > > syzbot has found a reproducer for the following issue on:
> > > > > > >
> > > > > > > HEAD commit:a68a0262 mm/madvise: remove racy mm ownership 
> > > > > > > check
> > > > > > > git tree:   upstream
> > > > > > > console output: 
> > > > > > > https://syzkaller.appspot.com/x/log.txt?x=11facf1750
> > > > > > > kernel config:  
> > > > > > > https://syzkaller.appspot.com/x/.config?x=4305fa9ea70c7a9f
> > > > > > > dashboard link: 
> > > > > > > https://syzkaller.appspot.com/bug?extid=f3694595248708227d35
> > > > > > > compiler:   gcc (GCC) 10.1.0-syz 20200507
> > > > > > > syz repro:  
> > > > > > > https://syzkaller.appspot.com/x/repro.syz?x=159a961350
> > > > > > > C reproducer:   
> > > > > > > https://syzkaller.appspot.com/x/repro.c?x=11bf712350
> > > > > > >
> > > > > > > IMPORTANT: if you fix the issue, please add the following tag to 
> > > > > > > the commit:
> > > > > > > Reported-by: syzbot+f3694595248708227...@syzkaller.appspotmail.com
> > > > > > >
> > > > > > > Debian GNU/Linux 9 syzkaller ttyS0
> > > > > > > Warning: Permanently added '10.128.0.9' (ECDSA) to the list of 
> > > > > > > known hosts.
> > > > > > > executing program
> > > > > > > executing program
> > > > > > > executing program
> > > > > > > BUG: memory leak
> > > > > > > unreferenced object 0x88810efccc80 (size 64):
> > > > > > >   comm "syz-executor334", pid 8460, jiffies 4294945724 (age 
> > > > > > > 13.850s)
> > > > > > >   hex dump (first 32 bytes):
> > > > > > > c0 cb 14 04 00 ea ff ff c0 c2 11 04 00 ea ff ff  
> > > > > > > 
> > > > > > > c0 56 3f 04 00 ea ff ff 40 18 38 04 00 ea ff ff  
> > > > > > > .V?.@.8.
> > > > > > >   backtrace:
> > > > > > > [<36ae98a7>] kmalloc_node include/linux/slab.h:575 
> > > > > > > [inline]
> > > > > > > [<36ae98a7>] bpf_ringbuf_area_alloc 
> > > > > > > kernel/bpf/ringbuf.c:94 [inline]
> > > > > > > [<36ae98a7>] bpf_ringbuf_alloc 
> > > > > > > kernel/bpf/ringbuf.c:135 [inline]
> > > > > > > [<36ae98a7>] ringbuf_map_alloc 
> > > > > > > kernel/bpf/ringbuf.c:183 [inline]
> > > > > > > [<36ae98a7>] ringbuf_map_alloc+0x1be/0x410 
> > > > > > > kernel/bpf/ringbuf.c:150
> > > > > > > [] find_and_alloc_map 
> > > > > > > kernel/bpf/syscall.c:122 [inline]
> > > > > > > [] map_create kernel/bpf/syscall.c:825 
> > > > > > > [inline]
> > > > > > > [] __do_sys_bpf+0x7d0/0x30a0 
> > > > > > > kernel/bpf/syscall.c:4381
> > > > > > > [<8feaf393>] do_syscall_64+0x2d/0x70 
> > > > > > > arch/x86/entry/common.c:46
> > > > > > > [] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > i am pretty sure that this one is a false positive
> > > > > > the problem with reproducer is that it does not terminate all of the
> > > > > > child processes that it spawns
> > > > > >
> > > > > > i confirmed that it is a false positive by tracing __fput() and
> > > > > > bpf_map_release(), i ran reproducer, got kmemleak report, then i
> > > > > > manually killed those running leftover processes from reproducer and
> > > > > > then both functions were executed and memory was freed
> > > > > >
> > > > > > i am marking this one as:
> > > > > > #syz invalid
> > > > >
> > > > > Hi Rustam,
> > > > >
> > > > > Thanks for looking into this.
> > > > >
> > > > > I wonder how/where are these objects referenced? If they are not
> > > > > leaked and referenced somewhere, KMEMLEAK should not report them as
> > > > > leaks.
> > > > > So even if this is a false positive for BPF, this is a true positive
> > > > > bug and something to fix for KMEMLEAK ;)
> > > > > And syzbot will probably re-create this bug report soon as this still
> > > > > happens and is not a one-off thing.
> > > >
> > > > hi Dmitry, i haven't thought of it this way, but i guess you are right,
> > > > it is a kmemleak bug, ideally kmemleak should be aware that there are
> > > > still running processes holding references to bpf fd/anonymous inodes
> > > > which in their turn hold references to allocated bpf maps
> > >
> > > KMEMLEAK scans whole memory, so if there are pointers to the object
> > > anywhere in memory, KMEMLEAK should not report them as leaked. Running
> > > processes have no direct effect on KMEMLEAK logic.
> > > So the question is: where are these pointers to these objects? If we
> > > answer this, we can 

Re: [PATCH v7 4/4] fs: unicode: Add utf8 module and a unicode layer

[Gabriel Krisman Bertazi]

Shreeya Patel  writes:

> utf8data.h_shipped has a large database table which is an auto-generated
> decodification trie for the unicode normalization functions.
> It is not necessary to load this large table in the kernel if no
> filesystem is using it, hence make UTF-8 encoding loadable by converting
> it into a module.
>
> Modify the file called unicode-core which will act as a layer for
> unicode subsystem. It will load the UTF-8 module and access it's functions
> whenever any filesystem that needs unicode is mounted.
> Currently, only UTF-8 encoding is supported but if any other encodings
> are supported in future then the layer file would be responsible for
> loading the desired encoding module.
>
> Also, indirect calls using function pointers are slow, use static calls to
> avoid overhead caused in case of repeated indirect calls. Static calls
> improves the performance by directly calling the functions as opposed to
> indirect calls.
>
> Signed-off-by: Shreeya Patel 
> ---
> Changes in v7
>   - Update the help text in Kconfig
>   - Handle the unicode_load_static_call function failure by decrementing
> the reference.
>   - Correct the code for handling built-in utf8 option as well.
>   - Correct the synchronization for accessing utf8mod.
>   - Make changes to unicode_unload() for handling the situation where
> utf8mod != NULL and um == NULL.
>
> Changes in v6
>   - Add spinlock to protect utf8mod and avoid NULL pointer
> dereference.
>   - Change the static call function names for being consistent with
> kernel coding style.
>   - Merge the unicode_load_module function with unicode_load as it is
> not really needed to have a separate function.
>   - Use try_then_module_get instead of module_get to avoid loading the
> module even when it is already loaded.
>   - Improve the commit message.
>
> Changes in v5
>   - Rename global variables and default static call functions for better
> understanding
>   - Make only config UNICODE_UTF8 visible and config UNICODE to be always
> enabled provided UNICODE_UTF8 is enabled.  
>   - Improve the documentation for Kconfig
>   - Improve the commit message.
>  
> Changes in v4
>   - Return error from the static calls instead of doing nothing and
> succeeding even without loading the module.
>   - Remove the complete usage of utf8_ops and use static calls at all
> places.
>   - Restore the static calls to default values when module is unloaded.
>   - Decrement the reference of module after calling the unload function.
>   - Remove spinlock as there will be no race conditions after removing
> utf8_ops.
>
> Changes in v3
>   - Add a patch which checks if utf8 is loaded before calling utf8_unload()
> in ext4 and f2fs filesystems
>   - Return error if strscpy() returns value < 0
>   - Correct the conditions to prevent NULL pointer dereference while
> accessing functions via utf8_ops variable.
>   - Add spinlock to avoid race conditions.
>   - Use static_call() for preventing speculative execution attacks.
>
> Changes in v2
>   - Remove the duplicate file from the last patch.
>   - Make the wrapper functions inline.
>   - Remove msleep and use try_module_get() and module_put()
> for ensuring that module is loaded correctly and also
> doesn't get unloaded while in use.
>   - Resolve the warning reported by kernel test robot.
>   - Resolve all the checkpatch.pl warnings.
>
>  fs/unicode/Kconfig|  26 +++-
>  fs/unicode/Makefile   |   5 +-
>  fs/unicode/unicode-core.c | 297 ++
>  fs/unicode/unicode-utf8.c | 264 +
>  include/linux/unicode.h   |  96 ++--
>  5 files changed, 483 insertions(+), 205 deletions(-)
>  create mode 100644 fs/unicode/unicode-utf8.c
>
> diff --git a/fs/unicode/Kconfig b/fs/unicode/Kconfig
> index 2c27b9a5cd6c..0c69800a2a37 100644
> --- a/fs/unicode/Kconfig
> +++ b/fs/unicode/Kconfig
> @@ -2,13 +2,31 @@
>  #
>  # UTF-8 normalization
>  #
> +# CONFIG_UNICODE will be automatically enabled if CONFIG_UNICODE_UTF8
> +# is enabled. This config option adds the unicode subsystem layer which loads
> +# the UTF-8 module whenever any filesystem needs it.
>  config UNICODE
> - bool "UTF-8 normalization and casefolding support"
> + bool
> +
> +config UNICODE_UTF8
> + tristate "UTF-8 module"

"UTF-8 module" is the text that will appear in menuconfig and other
configuration utilities.  This string not very helpful to describe what
this code is about or why it is different from NLS_utf8.  People come to
this option looking for the case-insensitive feature in ext4, so I'd
prefer to keep the mention to 'casefolding'. or even improve the
original a bit to say:

tristate: "UTF-8 support for native Case-Insensitive filesystems"

Other than these and what Eric mentioned, the code looks good to me.  I
gave this series a try and it seems to work fine.

It does raise a new warning, though

Re: [PATCH v2] bus: mhi: core: Fix shadow declarations

[kernel test robot]

Hi Manivannan,

I love your patch! Perhaps something to improve:

[auto build test WARNING on linus/master]
[also build test WARNING on v5.12-rc6 next-20210408]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Manivannan-Sadhasivam/bus-mhi-core-Fix-shadow-declarations/20210408-213242
base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
454859c552da78b0f587205d308401922b56863e
config: um-randconfig-c024-20210408 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0

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


cocci warnings: (new ones prefixed by >>)
>> drivers/bus/mhi/core/main.c:599:2-19: ERROR: nested lock+irqsave that reuses 
>> flags from line 521.

vim +599 drivers/bus/mhi/core/main.c

1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  496  
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  497  static int 
parse_xfer_event(struct mhi_controller *mhi_cntrl,
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  498
struct mhi_tre *event,
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  499
struct mhi_chan *mhi_chan)
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  500  {
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  501struct mhi_ring 
*buf_ring, *tre_ring;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  502struct device *dev = 
_cntrl->mhi_dev->dev;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  503struct mhi_result 
result;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  504unsigned long flags = 0;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  505u32 ev_code;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  506  
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  507ev_code = 
MHI_TRE_GET_EV_CODE(event);
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  508buf_ring = 
_chan->buf_ring;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  509tre_ring = 
_chan->tre_ring;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  510  
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  511
result.transaction_status = (ev_code == MHI_EV_CC_OVERFLOW) ?
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  512-EOVERFLOW : 0;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  513  
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  514/*
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  515 * If it's a DB Event 
then we need to grab the lock
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  516 * with preemption 
disabled and as a write because we
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  517 * have to update db 
register and there are chances that
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  518 * another thread could 
be doing the same.
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  519 */
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  520if (ev_code >= 
MHI_EV_CC_OOB)
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20 @521
write_lock_irqsave(_chan->lock, flags);
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  522else
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  523
read_lock_bh(_chan->lock);
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  524  
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  525if (mhi_chan->ch_state 
!= MHI_CH_STATE_ENABLED)
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  526goto 
end_process_tx_event;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  527  
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  528switch (ev_code) {
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  529case MHI_EV_CC_OVERFLOW:
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  530case MHI_EV_CC_EOB:
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  531case MHI_EV_CC_EOT:
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  532{
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  533dma_addr_t ptr 
= MHI_TRE_GET_EV_PTR(event);
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  534struct mhi_tre 
*local_rp, *ev_tre;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  535void *dev_rp;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  536struct 
mhi_buf_info *buf_info;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  537u16 xfer_len;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  538  
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  539/* Get the TRB 
this event points to */
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  540ev_tre = 
mhi_to_virtual(tre_ring, ptr);
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  541  
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  542dev_rp = ev_tre 
+ 1;
1d3173a3bae703 Manivannan Sadhasivam 2020-02-20  543

Re: [PATCH] MIPS: uaccess: Reduce number of nested macros

[Christoph Hellwig]

> +#define put_user(x, ptr) \
> +({   \
> + __typeof__(*(ptr)) __user *__p = (ptr); \
> + \
> + might_fault();  \
> + access_ok(__p, sizeof(*__p)) ?  \
> + __put_user((x), __p) :  \
> + -EFAULT;\

Why not merge this into a single line, which seems a little more
readable:

access_ok(__p, sizeof(*__p)) ? __put_user((x), __p) : -EFAULT;  \

Same for the get_user side.

Otherwise looks great:

Reviewed-by: Christoph Hellwig 

[PATCH] block: Disable -Walign-mismatch for blk-mq.c

[Nathan Chancellor]

LLVM 13 adds a new warning, -Walign-mismatch, which has an instance in
blk_mq_complete_send_ipi():

block/blk-mq.c:630:39: warning: passing 8-byte aligned argument to
32-byte aligned parameter 2 of 'smp_call_function_single_async' may
result in an unaligned pointer access [-Walign-mismatch]
smp_call_function_single_async(cpu, >csd);
^
1 warning generated.

This is expected after commit 4ccafe032005 ("block: unalign
call_single_data in struct request"), which purposefully unaligned the
structure to save space. Given that there is no real alignment
requirement and there have been no reports of issues since that change,
it should be safe to disable the warning for this one translation unit.

Link: https://github.com/ClangBuiltLinux/linux/issues/1328
Link: https://lore.kernel.org/r/20210310182307.zzcbi5w5jrmveld4@archlinux-ax161/
Link: https://lore.kernel.org/r/20210330230249.709221-1-jian...@google.com/
Signed-off-by: Nathan Chancellor 
---
 block/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/block/Makefile b/block/Makefile
index 8d841f5f986f..d69ac0bd8e61 100644
--- a/block/Makefile
+++ b/block/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_BLOCK) := bio.o elevator.o blk-core.o 
blk-sysfs.o \
blk-mq-sysfs.o blk-mq-cpumap.o blk-mq-sched.o ioctl.o \
genhd.o ioprio.o badblocks.o partitions/ blk-rq-qos.o
 
+CFLAGS_blk-mq.o := $(call cc-disable-warning, align-mismatch)
 obj-$(CONFIG_BOUNCE)   += bounce.o
 obj-$(CONFIG_BLK_SCSI_REQUEST) += scsi_ioctl.o
 obj-$(CONFIG_BLK_DEV_BSG)  += bsg.o

base-commit: e49d033bddf5b565044e2abe4241353959bc9120
-- 
2.31.1.189.g2e36527f23

RE: [PATCH next v2] mfd: Add Renesas Synchronization Management Unit (SMU) support

[Min Li]

Hi Lee

I just withdraw the misc driver review and sent you a new patch for mfd change 
alone. 
I will focus on mfd for now. Please take a look. Thanks

Min

Re: [PATCH v1] ata: ahci_tegra: call tegra_powergate_power_off only when PM domain is not present

[Dmitry Osipenko]

08.04.2021 19:40, Sowjanya Komatineni пишет:
> This patch adds a check on present of PM domain and calls legacy power
> domain API tegra_powergate_power_off() only when PM domain is not present.
> 
> This is a follow-up patch to Tegra186 AHCI support patch series
> https://lore.kernel.org/patchwork/cover/1408752/
> 
> Signed-off-by: Sowjanya Komatineni 
> 
> ---
>  drivers/ata/ahci_tegra.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/ata/ahci_tegra.c b/drivers/ata/ahci_tegra.c
> index 56612af..bd484dd 100644
> --- a/drivers/ata/ahci_tegra.c
> +++ b/drivers/ata/ahci_tegra.c
> @@ -287,7 +287,8 @@ static void tegra_ahci_power_off(struct ahci_host_priv 
> *hpriv)
>   reset_control_assert(tegra->sata_cold_rst);
>  
>   clk_disable_unprepare(tegra->sata_clk);
> - tegra_powergate_power_off(TEGRA_POWERGATE_SATA);
> + if (!tegra->pdev->dev.pm_domain)
> + tegra_powergate_power_off(TEGRA_POWERGATE_SATA);
>  
>   regulator_bulk_disable(tegra->soc->num_supplies, tegra->supplies);
>  }
> 

There are two instances of tegra_powergate_power_off() in the driver.

[PATCH 1/3] staging: rtl8712: remove struct rtl_ieee80211_ht_cap and ieee80211_ht_addt_info

[Christophe JAILLET]

struct 'ieee80211_ht_addt_info' is unused and can be removed.

struct 'rtl_ieee80211_ht_cap' can be replaced by 'ieee80211_ht_cap'
defined in  which has the same layout.

Signed-off-by: Christophe JAILLET 
---
 drivers/staging/rtl8712/rtl871x_ht.h  |  2 +-
 drivers/staging/rtl8712/rtl871x_ioctl_linux.c |  6 ++--
 drivers/staging/rtl8712/rtl871x_mlme.c| 10 +++---
 drivers/staging/rtl8712/wifi.h| 35 ---
 4 files changed, 9 insertions(+), 44 deletions(-)

diff --git a/drivers/staging/rtl8712/rtl871x_ht.h 
b/drivers/staging/rtl8712/rtl871x_ht.h
index 4bcf5591c44d..ebd78665775d 100644
--- a/drivers/staging/rtl8712/rtl871x_ht.h
+++ b/drivers/staging/rtl8712/rtl871x_ht.h
@@ -26,7 +26,7 @@ struct ht_priv {
unsigned intrx_ampdu_maxlen; /* for rx reordering ctrl win_sz,
  * updated when join_callback.
  */
-   struct rtl_ieee80211_ht_cap ht_cap;
+   struct ieee80211_ht_cap ht_cap;
 };
 
 #endif /*_RTL871X_HT_H_ */
diff --git a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c 
b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
index 14fe12eb930c..3b6926613257 100644
--- a/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
+++ b/drivers/staging/rtl8712/rtl871x_ioctl_linux.c
@@ -1389,7 +1389,7 @@ static int r8711_wx_get_rate(struct net_device *dev,
struct _adapter *padapter = netdev_priv(dev);
struct mlme_priv *pmlmepriv = >mlmepriv;
struct wlan_bssid_ex *pcur_bss = >cur_network.network;
-   struct rtl_ieee80211_ht_cap *pht_capie;
+   struct ieee80211_ht_cap *pht_capie;
unsigned char rf_type = padapter->registrypriv.rf_config;
int i;
u8 *p;
@@ -1405,8 +1405,8 @@ static int r8711_wx_get_rate(struct net_device *dev,
 pcur_bss->IELength - 12);
if (p && ht_ielen > 0) {
ht_cap = true;
-   pht_capie = (struct rtl_ieee80211_ht_cap *)(p + 2);
-   memcpy(_rate, pht_capie->supp_mcs_set, 2);
+   pht_capie = (struct ieee80211_ht_cap *)(p + 2);
+   memcpy(_rate, _capie->mcs, 2);
bw_40MHz = (le16_to_cpu(pht_capie->cap_info) &
IEEE80211_HT_CAP_SUP_WIDTH_20_40) ? 1 : 0;
short_GI = (le16_to_cpu(pht_capie->cap_info) &
diff --git a/drivers/staging/rtl8712/rtl871x_mlme.c 
b/drivers/staging/rtl8712/rtl871x_mlme.c
index b377c0b94cfb..6328da8a498e 100644
--- a/drivers/staging/rtl8712/rtl871x_mlme.c
+++ b/drivers/staging/rtl8712/rtl871x_mlme.c
@@ -1640,7 +1640,7 @@ unsigned int r8712_restructure_ht_ie(struct _adapter 
*padapter, u8 *in_ie,
 {
u32 ielen, out_len;
unsigned char *p;
-   struct rtl_ieee80211_ht_cap ht_capie;
+   struct ieee80211_ht_cap ht_capie;
unsigned char WMM_IE[] = {0x00, 0x50, 0xf2, 0x02, 0x00, 0x01, 0x00};
struct mlme_priv *pmlmepriv = >mlmepriv;
struct qos_priv *pqospriv = >qospriv;
@@ -1656,7 +1656,7 @@ unsigned int r8712_restructure_ht_ie(struct _adapter 
*padapter, u8 *in_ie,
pqospriv->qos_option = 1;
}
out_len = *pout_len;
-   memset(_capie, 0, sizeof(struct rtl_ieee80211_ht_cap));
+   memset(_capie, 0, sizeof(struct ieee80211_ht_cap));
ht_capie.cap_info = 
cpu_to_le16(IEEE80211_HT_CAP_SUP_WIDTH_20_40 |
IEEE80211_HT_CAP_SGI_20 |
IEEE80211_HT_CAP_SGI_40 |
@@ -1666,7 +1666,7 @@ unsigned int r8712_restructure_ht_ie(struct _adapter 
*padapter, u8 *in_ie,
ht_capie.ampdu_params_info = (IEEE80211_HT_AMPDU_PARM_FACTOR &
0x03) | (IEEE80211_HT_AMPDU_PARM_DENSITY & 
0x00);
r8712_set_ie(out_ie + out_len, WLAN_EID_HT_CAPABILITY,
-sizeof(struct rtl_ieee80211_ht_cap),
+sizeof(struct ieee80211_ht_cap),
 (unsigned char *)_capie, pout_len);
phtpriv->ht_option = 1;
}
@@ -1680,7 +1680,7 @@ static void update_ht_cap(struct _adapter *padapter, u8 
*pie, uint ie_len)
int i;
uint len;
struct sta_info *bmc_sta, *psta;
-   struct rtl_ieee80211_ht_cap *pht_capie;
+   struct ieee80211_ht_cap *pht_capie;
struct recv_reorder_ctrl *preorder_ctrl;
struct mlme_priv *pmlmepriv = >mlmepriv;
struct ht_priv *phtpriv = >htpriv;
@@ -1700,7 +1700,7 @@ static void update_ht_cap(struct _adapter *padapter, u8 
*pie, uint ie_len)
, ie_len -
sizeof(struct NDIS_802_11_FIXED_IEs));
if (p && len > 0) {
-   pht_capie = (struct rtl_ieee80211_ht_cap *)(p + 2);
+   pht_capie = (struct ieee80211_ht_cap *)(p + 2);
max_ampdu_sz = (pht_capie->ampdu_params_info &
   

Re: [PATCH v3 12/12] kdump: Use vmlinux_build_id to simplify

[Stephen Boyd]

Quoting Baoquan He (2021-04-08 03:17:43)
> On 04/07/21 at 07:03pm, Petr Mladek wrote:
> > On Tue 2021-03-30 20:05:20, Stephen Boyd wrote:
> > > We can use the vmlinux_build_id array here now instead of open coding
> > > it. This mostly consolidates code.
> > > 
> > > Cc: Jiri Olsa 
> > > Cc: Alexei Starovoitov 
> > > Cc: Jessica Yu 
> > > Cc: Evan Green 
> > > Cc: Hsin-Yi Wang 
> > > Cc: Dave Young 
> > > Cc: Baoquan He 
> > > Cc: Vivek Goyal 
> > > Cc: 
> > > Signed-off-by: Stephen Boyd 
> > > ---
> > >  include/linux/crash_core.h |  6 +-
> > >  kernel/crash_core.c| 41 ++
> > >  2 files changed, 3 insertions(+), 44 deletions(-)
> > > 
> > > diff --git a/include/linux/crash_core.h b/include/linux/crash_core.h
> > > index 206bde8308b2..fb8ab99bb2ee 100644
> > > --- a/include/linux/crash_core.h
> > > +++ b/include/linux/crash_core.h
> > > @@ -39,7 +39,7 @@ phys_addr_t paddr_vmcoreinfo_note(void);
> > >  #define VMCOREINFO_OSRELEASE(value) \
> > > vmcoreinfo_append_str("OSRELEASE=%s\n", value)
> > >  #define VMCOREINFO_BUILD_ID(value) \
> > > -   vmcoreinfo_append_str("BUILD-ID=%s\n", value)
> > > +   vmcoreinfo_append_str("BUILD-ID=%20phN\n", value)
> 
> I may miss something, wondering why we need add '20' here.

The build ID is an array of 20 bytes and this format is to print 20
bytes in hex.

Re: [PATCH 0/4] Add support for XMM fast hypercalls

[Paolo Bonzini]

On 08/04/21 17:40, Siddharth Chandrasekaran wrote:

Although the Hyper-v TLFS mentions that a guest cannot use this feature
unless the hypervisor advertises support for it, some hypercalls which
we plan on upstreaming in future uses them anyway.

No, please don't do this. Check the feature bit(s) before you issue
hypercalls which rely on the extended interface.

Perhaps Siddharth should clarify this, but I read it as Hyper-V being
buggy and using XMM arguments unconditionally.

The guest is at fault here as it expects Hyper-V to consume arguments
from XMM registers for certain hypercalls (that we are working) even if
we didn't expose the feature via CPUID bits.


What guest is that?

Paolo

Re: [PATCH 0/4] Add support for XMM fast hypercalls

[Siddharth Chandrasekaran]

On Thu, Apr 08, 2021 at 05:48:19PM +0200, Paolo Bonzini wrote:
> On 08/04/21 17:40, Siddharth Chandrasekaran wrote:
> > > > > Although the Hyper-v TLFS mentions that a guest cannot use this 
> > > > > feature
> > > > > unless the hypervisor advertises support for it, some hypercalls which
> > > > > we plan on upstreaming in future uses them anyway.
> > > > No, please don't do this. Check the feature bit(s) before you issue
> > > > hypercalls which rely on the extended interface.
> > > Perhaps Siddharth should clarify this, but I read it as Hyper-V being
> > > buggy and using XMM arguments unconditionally.
> > The guest is at fault here as it expects Hyper-V to consume arguments
> > from XMM registers for certain hypercalls (that we are working) even if
> > we didn't expose the feature via CPUID bits.
>
> What guest is that?

It is a Windows Server 2016.



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879

Re: [PATCH RESEND 0/3] x86/sgx: eextend ioctl

[Dave Hansen]

On 4/8/21 8:27 AM, Jethro Beekman wrote:
> But the native “executable format” for SGX is very clearly defined in
> the Intel SDM as a specific sequence of ECREATE, EADD, EEXTEND and
> EINIT calls. It's that sequence that's used for loading the enclave
> and it's that sequence that's used for code signing. So when I say
> save space I mean save space in the native format.
> 
> Not EEXTENDing unnecessarily also reduces enclave load time if
> you're looking for additional arguments.
I look forward to all of this being clearly explained in your resubmission.

> SGX defines lots of things and you may not see the use case for all
> of this immediately. No one has a usecase for creating enclaves with
> SECS.SSAFRAMESIZE = 1000 or TCS.NSSA = 3. Why did you not demand
> checks for this in the ECREATE/EADD ioctls?
There's a difference between adding code to support a feature and adding
code to *RESTRICT* use of a feature.

[PATCH v1 1/1] defconfig: enable GPIO_SIM

[Andy Shevchenko]

Signed-off-by: Andy Shevchenko 
---
 arch/x86/configs/i386_defconfig   | 1 +
 arch/x86/configs/x86_64_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig
index d696336674b0..e36dc940a83c 100644
--- a/arch/x86/configs/i386_defconfig
+++ b/arch/x86/configs/i386_defconfig
@@ -309,6 +309,7 @@ CONFIG_GPIO_PCA953X=y
 CONFIG_GPIO_PCA953X_IRQ=y
 CONFIG_GPIO_PCH=m
 CONFIG_GPIO_SCH=m
+CONFIG_GPIO_SIM=m
 CONFIG_GPIO_XILINX=m
 CONFIG_X86_EXTENDED_PLATFORM=y
 CONFIG_X86_INTEL_MID=y
diff --git a/arch/x86/configs/x86_64_defconfig 
b/arch/x86/configs/x86_64_defconfig
index 20a955acf775..97d42dd67c8a 100644
--- a/arch/x86/configs/x86_64_defconfig
+++ b/arch/x86/configs/x86_64_defconfig
@@ -305,6 +305,7 @@ CONFIG_GPIO_PCA953X=y
 CONFIG_GPIO_PCA953X_IRQ=y
 CONFIG_GPIO_PCH=m
 CONFIG_GPIO_SCH=m
+CONFIG_GPIO_SIM=m
 CONFIG_GPIO_XILINX=m
 CONFIG_X86_EXTENDED_PLATFORM=y
 CONFIG_X86_INTEL_MID=y
-- 
2.30.2

Re: [PATCH -next] clk: samsung: Remove redundant dev_err calls

[Krzysztof Kozlowski]

On 08/04/2021 15:48, Chen Hui wrote:
> There is error message within devm_ioremap_resource
> already, so remove the dev_err calls to avoid redundant
> error messages.
> 
> Signed-off-by: Chen Hui 
> ---
>  drivers/clk/samsung/clk-exynos4412-isp.c | 4 +---
>  drivers/clk/samsung/clk-s5pv210-audss.c  | 4 +---
>  2 files changed, 2 insertions(+), 6 deletions(-)


Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

[PATCH v2 1/3] arm64: dts: qcom: sm8150: add other QUP nodes and iommus

[Caleb Connolly]

Add the first and third qupv3 nodes used to hook
up peripherals on some devices, as well as the iommus properties for all
of them.

Signed-off-by: Caleb Connolly 
---
 arch/arm64/boot/dts/qcom/sm8150.dtsi | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi 
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index e5bb17bc2f46..543417d74216 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -577,12 +577,26 @@ gcc: clock-controller@10 {
 <_clk>;
};
 
+   qupv3_id_0: geniqup@8c {
+   compatible = "qcom,geni-se-qup";
+   reg = <0x0 0x008c 0x0 0x6000>;
+   clock-names = "m-ahb", "s-ahb";
+   clocks = < GCC_QUPV3_WRAP_0_M_AHB_CLK>,
+< GCC_QUPV3_WRAP_0_S_AHB_CLK>;
+   iommus = <_smmu 0xc3 0x0>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "disabled";
+   };
+
qupv3_id_1: geniqup@ac {
compatible = "qcom,geni-se-qup";
reg = <0x0 0x00ac 0x0 0x6000>;
clock-names = "m-ahb", "s-ahb";
clocks = < GCC_QUPV3_WRAP_1_M_AHB_CLK>,
 < GCC_QUPV3_WRAP_1_S_AHB_CLK>;
+   iommus = <_smmu 0x603 0x0>;
#address-cells = <2>;
#size-cells = <2>;
ranges;
@@ -598,6 +612,20 @@ uart2: serial@a9 {
};
};
 
+   qupv3_id_2: geniqup@cc {
+   compatible = "qcom,geni-se-qup";
+   reg = <0x0 0x00cc 0x0 0x6000>;
+
+   clock-names = "m-ahb", "s-ahb";
+   clocks = < GCC_QUPV3_WRAP_2_M_AHB_CLK>,
+< GCC_QUPV3_WRAP_2_S_AHB_CLK>;
+   iommus = <_smmu 0x7a3 0x0>;
+   #address-cells = <2>;
+   #size-cells = <2>;
+   ranges;
+   status = "disabled";
+   };
+
config_noc: interconnect@150 {
compatible = "qcom,sm8150-config-noc";
reg = <0 0x0150 0 0x7400>;
-- 
2.30.2

[PATCH v2 3/3] dt-bindings: qcom: geni-se: document iommus

[Caleb Connolly]

Document the iommus property for QCOM Geni SE.

Signed-off-by: Caleb Connolly 
---
 Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml 
b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
index 84671950ca0d..6a3b001bf01c 100644
--- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml
@@ -51,6 +51,9 @@ properties:
   interconnect-names:
 const: qup-core
 
+  iommus:
+maxItems: 1
+
 required:
   - compatible
   - reg
-- 
2.30.2

[PATCH v2 2/3] arm64: dts: qcom: sm8150: add i2c nodes

[Caleb Connolly]

Tested on the OnePlus 7 Pro (including DMA).

Signed-off-by: Caleb Connolly 
Reviewed-by: Vinod Koul 
Reviewed-by: Bhupesh Sharma 
---
 arch/arm64/boot/dts/qcom/sm8150.dtsi | 521 +++
 1 file changed, 521 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm8150.dtsi 
b/arch/arm64/boot/dts/qcom/sm8150.dtsi
index 543417d74216..7207a3689d9d 100644
--- a/arch/arm64/boot/dts/qcom/sm8150.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8150.dtsi
@@ -588,6 +588,111 @@ qupv3_id_0: geniqup@8c {
#size-cells = <2>;
ranges;
status = "disabled";
+
+   i2c0: i2c@88 {
+   compatible = "qcom,geni-i2c";
+   reg = <0 0x0088 0 0x4000>;
+   clock-names = "se";
+   clocks = < GCC_QUPV3_WRAP0_S0_CLK>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c0_default>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c1: i2c@884000 {
+   compatible = "qcom,geni-i2c";
+   reg = <0 0x00884000 0 0x4000>;
+   clock-names = "se";
+   clocks = < GCC_QUPV3_WRAP0_S1_CLK>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c1_default>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c2: i2c@888000 {
+   compatible = "qcom,geni-i2c";
+   reg = <0 0x00888000 0 0x4000>;
+   clock-names = "se";
+   clocks = < GCC_QUPV3_WRAP0_S2_CLK>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c2_default>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c3: i2c@88c000 {
+   compatible = "qcom,geni-i2c";
+   reg = <0 0x0088c000 0 0x4000>;
+   clock-names = "se";
+   clocks = < GCC_QUPV3_WRAP0_S3_CLK>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c3_default>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c4: i2c@89 {
+   compatible = "qcom,geni-i2c";
+   reg = <0 0x0089 0 0x4000>;
+   clock-names = "se";
+   clocks = < GCC_QUPV3_WRAP0_S4_CLK>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c4_default>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c5: i2c@894000 {
+   compatible = "qcom,geni-i2c";
+   reg = <0 0x00894000 0 0x4000>;
+   clock-names = "se";
+   clocks = < GCC_QUPV3_WRAP0_S5_CLK>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c5_default>;
+   interrupts = ;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   status = "disabled";
+   };
+
+   i2c6: i2c@898000 {
+   compatible = "qcom,geni-i2c";
+   reg = <0 0x00898000 0 0x4000>;
+   clock-names = "se";
+   clocks = < GCC_QUPV3_WRAP0_S6_CLK>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_i2c6_default>;
+   interrupts = ;
+   #address-cells = <1>;
+ 

Re: [PATCH] char: tpm: fix error return code in tpm_cr50_i2c_tis_recv()

[Jarkko Sakkinen]

On Thu, Apr 08, 2021 at 07:26:08PM +0800, Zhihao Cheng wrote:
> Fix to return a negative error code from the error handling
> case instead of 0, as done elsewhere in this function.
> 
> Fixes: 3a253caaad11 ("char: tpm: add i2c driver for cr50")
> Reported-by: Hulk Robot 
> Signed-off-by: Zhihao Cheng 
> ---
>  drivers/char/tpm/tpm_tis_i2c_cr50.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/char/tpm/tpm_tis_i2c_cr50.c 
> b/drivers/char/tpm/tpm_tis_i2c_cr50.c
> index ec9a65e7887d..e908da78fbf4 100644
> --- a/drivers/char/tpm/tpm_tis_i2c_cr50.c
> +++ b/drivers/char/tpm/tpm_tis_i2c_cr50.c
> @@ -483,6 +483,7 @@ static int tpm_cr50_i2c_tis_recv(struct tpm_chip *chip, 
> u8 *buf, size_t buf_len)
>   expected = be32_to_cpup((__be32 *)(buf + 2));
>   if (expected > buf_len) {
>   dev_err(>dev, "Buffer too small to receive i2c data\n");
> + rc = -EIO;
>   goto out_err;
>   }
>  
> -- 
> 2.25.4
> 

We are using E2BIG in similar situations in a few places:

❯ git grep E2BIG drivers/char/tpm
drivers/char/tpm/tpm-dev-common.c:  return -E2BIG;
drivers/char/tpm/tpm-interface.c:   return -E2BIG;
drivers/char/tpm/tpm_crb.c: return -E2BIG;
drivers/char/tpm/tpm_i2c_atmel.c:   return -E2BIG;
drivers/char/tpm/tpm_i2c_infineon.c:return -E2BIG;

So, I tend to think that also in here it'd be better to use E2BIG.

/Jarkko

Re: [RFC v3 net-next 0/4] MT7530 interrupt support

[Andrew Lunn]

On Thu, Apr 08, 2021 at 11:00:08PM +0800, DENG Qingfang wrote:
> Hi René,
> 
> On Thu, Apr 8, 2021 at 10:02 PM René van Dorst  wrote:
> >
> > Tested on Ubiquiti ER-X-SFP (MT7621) with 1 external phy which uses 
> > irq=POLL.
> >
> 
> I wonder if the external PHY's IRQ can be registered in the devicetree.
> Change MT7530_NUM_PHYS to 6, and add the following to ER-X-SFP dts PHY node:

I don't know this platform. What is the PHYs interrupt pin connected
to? A SoC GPIO? There is a generic mechanism to describe PHY
interrupts in DT. That should be used, if it is a GPIO.

   Andrew

Re: [PATCH v1 1/5] bitmap: Make bitmap_remap() and bitmap_bitremap() available to users

[Yury Norov]

On Thu, Apr 08, 2021 at 05:55:57PM +0300, Andy Shevchenko wrote:
> Currently the bitmap_remap() and bitmap_bitremap() are available
> only for CONFIG_NUMA=y case, while some users may benefit out of it
> and being independent to NUMA code. Make them available to users
> by moving out of ifdeffery and exporting for modules.
> 
> Signed-off-by: Andy Shevchenko 
> ---
>  lib/bitmap.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/bitmap.c b/lib/bitmap.c
> index 74ceb02f45e3..7b6b2a67a6a6 100644
> --- a/lib/bitmap.c
> +++ b/lib/bitmap.c
> @@ -784,8 +784,6 @@ int bitmap_parse(const char *start, unsigned int buflen,
>  }
>  EXPORT_SYMBOL(bitmap_parse);
>  
> -
> -#ifdef CONFIG_NUMA
>  /**
>   * bitmap_pos_to_ord - find ordinal of set bit at given position in bitmap
>   *   @buf: pointer to a bitmap
> @@ -894,6 +892,7 @@ void bitmap_remap(unsigned long *dst, const unsigned long 
> *src,
>   set_bit(bitmap_ord_to_pos(new, n % w, nbits), dst);
>   }
>  }
> +EXPORT_SYMBOL(bitmap_remap);
>  
>  /**
>   * bitmap_bitremap - Apply map defined by a pair of bitmaps to a single bit
> @@ -931,7 +930,9 @@ int bitmap_bitremap(int oldbit, const unsigned long *old,
>   else
>   return bitmap_ord_to_pos(new, n % w, bits);
>  }
> +EXPORT_SYMBOL(bitmap_bitremap);
>  
> +#ifdef CONFIG_NUMA
>  /**
>   * bitmap_onto - translate one bitmap relative to another
>   *   @dst: resulting translated bitmap
> -- 
> 2.30.2

Acked-by: Yury Norov 

Re: [PATCH v2 net-next] net: mana: Add a driver for Microsoft Azure Network Adapter (MANA)

[Stephen Hemminger]

On Thu, 8 Apr 2021 09:22:57 -0700
Randy Dunlap  wrote:

> On 4/8/21 2:15 AM, Dexuan Cui wrote:
> > diff --git a/drivers/net/ethernet/microsoft/Kconfig 
> > b/drivers/net/ethernet/microsoft/Kconfig
> > new file mode 100644
> > index ..12ef6b581566
> > --- /dev/null
> > +++ b/drivers/net/ethernet/microsoft/Kconfig
> > @@ -0,0 +1,30 @@
> > +#
> > +# Microsoft Azure network device configuration
> > +#
> > +
> > +config NET_VENDOR_MICROSOFT
> > +   bool "Microsoft Azure Network Device"  
> 
> Seems to me that should be generalized, more like:
> 
>   bool "Microsoft Network Devices"

Yes, that is what it should be at this level.

> 
> 
> > +   default y

This follows the existing policy for network vendor level

> > +   help
> > + If you have a network (Ethernet) device belonging to this class, say 
> > Y.
> > +
> > + Note that the answer to this question doesn't directly affect the
> > + kernel: saying N will just cause the configurator to skip the
> > + question about Microsoft Azure network device. If you say Y, you  
> 
>  about Microsoft networking devices.
> 
> > + will be asked for your specific device in the following question.
> > +
> > +if NET_VENDOR_MICROSOFT
> > +
> > +config MICROSOFT_MANA
> > +   tristate "Microsoft Azure Network Adapter (MANA) support"
> > +   default m  
> 
> Please drop the default m. We don't randomly add drivers to be built.

Yes, it should be no (or no default which is the default for default)

> Or leave this as is and change NET_VENDOR_MICROSOFT to be default n.
> 
> 
> > +   depends on PCI_MSI && X86_64
> > +   select PCI_HYPERV
> > +   help
> > + This driver supports Microsoft Azure Network Adapter (MANA).
> > + So far, the driver is only validated on X86_64.  
> 
> validated how?

Maybe change validated to supported?

Re: [PATCH] arm64: mte: Move MTE TCF0 check in entry-common

[Will Deacon]

On Thu, Apr 08, 2021 at 04:06:23PM +0100, Mark Rutland wrote:
> On Thu, Apr 08, 2021 at 03:56:04PM +0100, Will Deacon wrote:
> > On Thu, Apr 08, 2021 at 03:37:23PM +0100, Vincenzo Frascino wrote:
> > > diff --git a/arch/arm64/kernel/entry-common.c 
> > > b/arch/arm64/kernel/entry-common.c
> > > index 9d3588450473..837d3624a1d5 100644
> > > --- a/arch/arm64/kernel/entry-common.c
> > > +++ b/arch/arm64/kernel/entry-common.c
> > > @@ -289,10 +289,16 @@ asmlinkage void noinstr enter_from_user_mode(void)
> > >   CT_WARN_ON(ct_state() != CONTEXT_USER);
> > >   user_exit_irqoff();
> > >   trace_hardirqs_off_finish();
> > > +
> > > + /* Check for asynchronous tag check faults in user space */
> > > + check_mte_async_tcf0();
> > >  }
> > 
> > Is enter_from_user_mode() always called when we enter the kernel from EL0?
> > afaict, some paths (e.g. el0_irq()) only end up calling it if
> > CONTEXT_TRACKING or TRACE_IRQFLAGS are enabled.
> 
> Currently everything that's in {enter,exit}_from_user_mode() only
> matters when either CONTEXT_TRACKING or TRACE_IRQFLAGS is selected (and
> expands to an empty stub otherwise).
> 
> We could drop the ifdeffery in user_{enter,exit}_irqoff() to have them
> called regardless, or add CONFIG_MTE to the list.

I'm always in favour of dropping ifdeffery if it's getting in the way.

> > >  asmlinkage void noinstr exit_to_user_mode(void)
> > >  {
> > > + /* Ignore asynchronous tag check faults in the uaccess routines */
> > > + clear_mte_async_tcf0();
> > > +
> > 
> > and this one seems to be called even less often.
> 
> This is always done in ret_to_user, so (modulo ifdeferry above) all
> returns to EL0 call this.

Right, I was just saying that if you disabled those CONFIG options then this
isn't called _at all_ whereas I think enter_from_user_mode() still is on
some paths.

Will

Re: [PATCH -next] freezer: Remove unused inline function try_to_freeze_nowarn()

[Rafael J. Wysocki]

On Thu, Apr 1, 2021 at 7:58 PM YueHaibing  wrote:
>
> There is no caller in tree, so can remove it.
>
> Signed-off-by: YueHaibing 
> ---
>  include/linux/freezer.h | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/include/linux/freezer.h b/include/linux/freezer.h
> index 27828145ca09..0621c5f86c39 100644
> --- a/include/linux/freezer.h
> +++ b/include/linux/freezer.h
> @@ -279,7 +279,6 @@ static inline int freeze_kernel_threads(void) { return 
> -ENOSYS; }
>  static inline void thaw_processes(void) {}
>  static inline void thaw_kernel_threads(void) {}
>
> -static inline bool try_to_freeze_nowarn(void) { return false; }
>  static inline bool try_to_freeze(void) { return false; }
>
>  static inline void freezer_do_not_count(void) {}
> --

Applied as 5.13 material, thanks!

Re: [RFC PATCH v1 00/11] Manage the top tier memory in a tiered memory

[Shakeel Butt]

Hi Tim,

On Mon, Apr 5, 2021 at 11:08 AM Tim Chen  wrote:
>
> Traditionally, all memory is DRAM.  Some DRAM might be closer/faster than
> others NUMA wise, but a byte of media has about the same cost whether it
> is close or far.  But, with new memory tiers such as Persistent Memory
> (PMEM).  there is a choice between fast/expensive DRAM and slow/cheap
> PMEM.
>
> The fast/expensive memory lives in the top tier of the memory hierachy.
>
> Previously, the patchset
> [PATCH 00/10] [v7] Migrate Pages in lieu of discard
> https://lore.kernel.org/linux-mm/20210401183216.443c4...@viggo.jf.intel.com/
> provides a mechanism to demote cold pages from DRAM node into PMEM.
>
> And the patchset
> [PATCH 0/6] [RFC v6] NUMA balancing: optimize memory placement for memory 
> tiering system
> https://lore.kernel.org/linux-mm/20210311081821.138467-1-ying.hu...@intel.com/
> provides a mechanism to promote hot pages in PMEM to the DRAM node
> leveraging autonuma.
>
> The two patchsets together keep the hot pages in DRAM and colder pages
> in PMEM.

Thanks for working on this as this is becoming more and more important
particularly in the data centers where memory is a big portion of the
cost.

I see you have responded to Michal and I will add my more specific
response there. Here I wanted to give my high level concern regarding
using v1's soft limit like semantics for top tier memory.

This patch series aims to distribute/partition top tier memory between
jobs of different priorities. We want high priority jobs to have
preferential access to the top tier memory and we don't want low
priority jobs to hog the top tier memory.

Using v1's soft limit like behavior can potentially cause high
priority jobs to stall to make enough space on top tier memory on
their allocation path and I think this patchset is aiming to reduce
that impact by making kswapd do that work. However I think the more
concerning issue is the low priority job hogging the top tier memory.

The possible ways the low priority job can hog the top tier memory are
by allocating non-movable memory or by mlocking the memory. (Oh there
is also pinning the memory but I don't know if there is a user api to
pin memory?) For the mlocked memory, you need to either modify the
reclaim code or use a different mechanism for demoting cold memory.

Basically I am saying we should put the upfront control (limit) on the
usage of top tier memory by the jobs.

Re: [PATCH v2 3/3] perf-stat: introduce config stat.bpf-counter-events

[Arnaldo Carvalho de Melo]

Em Thu, Apr 08, 2021 at 04:39:33PM +, Song Liu escreveu:
> > On Apr 8, 2021, at 4:47 AM, Jiri Olsa  wrote:
> > On Tue, Apr 06, 2021 at 05:36:01PM -0700, Song Liu wrote:
> >> Currently, to use BPF to aggregate perf event counters, the user uses
> >> --bpf-counters option. Enable "use bpf by default" events with a config
> >> option, stat.bpf-counter-events. This is limited to hardware events in
> >> evsel__hw_names.
> >> 
> >> This also enables mixed BPF event and regular event in the same sesssion.
> >> For example:
> >> 
> >>   perf config stat.bpf-counter-events=instructions
> >>   perf stat -e instructions,cs
> >> 
> > 
> > so if we are mixing events now, how about uing modifier for bpf counters,
> > instead of configuring .perfconfig list we could use:
> > 
> >  perf stat -e instructions:b,cs
> > 
> > thoughts?
> > 
> > the change below adds 'b' modifier and sets 'evsel::bpf_counter',
> > feel free to use it
> 
> I think we will need both 'b' modifier and .perfconfig configuration. 

Agreed, maximum flexibility.

> For systems with BPF-managed perf events running in the background, 
> .perfconfig makes sure perf-stat sessions will share PMCs with these 
> background monitoring tools. 'b' modifier, on the other hand, is useful
> when the user knows there is opportunity to share the PMCs. 
> 
> Does this make sense? 

I think so.

- Arnaldo
 
> Thanks,
> Song
> 
> > 
> > jirka
> > 
> > 
> > ---
> > diff --git a/tools/perf/util/evsel.h b/tools/perf/util/evsel.h
> > index ca52581f1b17..c55e4e58d1dc 100644
> > --- a/tools/perf/util/evsel.h
> > +++ b/tools/perf/util/evsel.h
> > @@ -82,6 +82,7 @@ struct evsel {
> > boolauto_merge_stats;
> > boolcollect_stat;
> > boolweak_group;
> > +   boolbpf_counter;
> > int bpf_fd;
> > struct bpf_object   *bpf_obj;
> > };
> > diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
> > index 9ecb45bea948..b5850f1ea90b 100644
> > --- a/tools/perf/util/parse-events.c
> > +++ b/tools/perf/util/parse-events.c
> > @@ -1801,6 +1801,7 @@ struct event_modifier {
> > int pinned;
> > int weak;
> > int exclusive;
> > +   int bpf_counter;
> > };
> > 
> > static int get_event_modifier(struct event_modifier *mod, char *str,
> > @@ -1821,6 +1822,7 @@ static int get_event_modifier(struct event_modifier 
> > *mod, char *str,
> > int exclude = eu | ek | eh;
> > int exclude_GH = evsel ? evsel->exclude_GH : 0;
> > int weak = 0;
> > +   int bpf_counter = 0;
> > 
> > memset(mod, 0, sizeof(*mod));
> > 
> > @@ -1864,6 +1866,8 @@ static int get_event_modifier(struct event_modifier 
> > *mod, char *str,
> > exclusive = 1;
> > } else if (*str == 'W') {
> > weak = 1;
> > +   } else if (*str == 'b') {
> > +   bpf_counter = 1;
> > } else
> > break;
> > 
> > @@ -1895,6 +1899,7 @@ static int get_event_modifier(struct event_modifier 
> > *mod, char *str,
> > mod->sample_read = sample_read;
> > mod->pinned = pinned;
> > mod->weak = weak;
> > +   mod->bpf_counter = bpf_counter;
> > mod->exclusive = exclusive;
> > 
> > return 0;
> > @@ -1909,7 +1914,7 @@ static int check_modifier(char *str)
> > char *p = str;
> > 
> > /* The sizeof includes 0 byte as well. */
> > -   if (strlen(str) > (sizeof("ukhGHpppPSDIWe") - 1))
> > +   if (strlen(str) > (sizeof("ukhGHpppPSDIWeb") - 1))
> > return -1;
> > 
> > while (*p) {
> > @@ -1950,6 +1955,7 @@ int parse_events__modifier_event(struct list_head 
> > *list, char *str, bool add)
> > evsel->sample_read = mod.sample_read;
> > evsel->precise_max = mod.precise_max;
> > evsel->weak_group  = mod.weak;
> > +   evsel->bpf_counter = mod.bpf_counter;
> > 
> > if (evsel__is_group_leader(evsel)) {
> > evsel->core.attr.pinned = mod.pinned;
> > diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
> > index 0b36285a9435..fb8646cc3e83 100644
> > --- a/tools/perf/util/parse-events.l
> > +++ b/tools/perf/util/parse-events.l
> > @@ -210,7 +210,7 @@ name_tag
> > [\'][a-zA-Z_*?\[\]][a-zA-Z0-9_*?\-,\.\[\]:=]*[\']
> > name_minus  [a-zA-Z_*?][a-zA-Z0-9\-_*?.:]*
> > drv_cfg_term[a-zA-Z0-9_\.]+(=[a-zA-Z0-9_*?\.:]+)?
> > /* If you add a modifier you need to update check_modifier() */
> > -modifier_event [ukhpPGHSDIWe]+
> > +modifier_event [ukhpPGHSDIWeb]+
> > modifier_bp [rwx]{1,3}
> > 
> > %%
> > 
> 

-- 

- Arnaldo

Re: [GIT PULL] cpuidle for v5.13-rc1

[Daniel Lezcano]

On 08/04/2021 19:24, Rafael J. Wysocki wrote:
> On Thu, Apr 8, 2021 at 5:10 PM Daniel Lezcano  
> wrote:
>>
>>
>> Hi Rafael,
>>
>> please consider pulling the following change for cpuidle on ARM for
>> v5.13-rc1
>>
>> Thanks
>>
>>   -- Daniel
>>
>>
>> The following changes since commit dde8740bd9b505c58ec8b2277d5d55c6951b7e42:
>>
>>   Merge branch 'acpi-processor-fixes' into linux-next (2021-04-07
>> 19:02:56 +0200)
> 
> Can you please rebase this on 5.12-rc6?  My linux-next branch is
> re-merged on a regular basis.
> 
> Generally speaking, if you want me to pull from a branch, please make
> sure that this branch is based on a commit present in the Linus' tree,
> preferably one of the commits tagged as -rc or a specific merge.
> 

Sure, here is the pull request based on v5.12-rc6 with the signed tag
cpuidle-v5.13-rc1

Thanks

  -- Daniel


The following changes since commit e49d033bddf5b565044e2abe4241353959bc9120:

  Linux 5.12-rc6 (2021-04-04 14:15:36 -0700)

are available in the Git repository at:

  https://git.linaro.org/people/daniel.lezcano/linux tags/cpuidle-v5.13-rc1

for you to fetch changes up to 498ba2a8a2756694b6f357426dbc8a5e6b6c:

  cpuidle: Fix ARM_QCOM_SPM_CPUIDLE configuration (2021-04-08 19:54:14
+0200)


- Fix the C7 state on the tegra114 by setting the L2-no-flush flag
  unconditionally (Dmitry Osipenko)

- Remove the do_idle firmware call as it is not supported by the ATF
  on tegra SoC (Dmitry Osipenko)

- Add a missing dependency on CONFIG_MMU to prevent linkage error (He
  Ying)


Dmitry Osipenko (2):
  cpuidle: tegra: Fix C7 idling state on Tegra114
  cpuidle: tegra: Remove do_idle firmware call

He Ying (1):
  cpuidle: Fix ARM_QCOM_SPM_CPUIDLE configuration

 drivers/cpuidle/Kconfig.arm |  2 +-
 drivers/cpuidle/cpuidle-tegra.c | 19 ---
 2 files changed, 5 insertions(+), 16 deletions(-)

-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH net-next v3 2/2] misc: Add Renesas Synchronization Management Unit (SMU) support

[Greg KH]

On Thu, Apr 08, 2021 at 06:01:42PM +, Min Li wrote:
> > 
> > That does not make sense, this is only one kernel module, with one .h file 
> > in
> > this patch, I do not see those other files you are talking about...
> > 
> > And if you have named registers that are identical, and yet you only work on
> > one device, that feels like a design flaw somewhere :)
> > 
> 
> Hi Greg, the register files are in the 1/2 patch for the mfd part of the 
> change. 
> The reason they have same named register is because they are all 
> synchronization 
> devices and they share some similar features

But what does that have to do with the misc device?

totally confused,

greg k-h

Re: [PATCH net v1] Revert "lan743x: trim all 4 bytes of the FCS; not just 2"

[Heiner Kallweit]

On 08.04.2021 20:00, George McCollister wrote:
> On Thu, Apr 8, 2021 at 12:46 PM Sven Van Asbroeck  wrote:
>>
>> Hi George,
>>
>> On Thu, Apr 8, 2021 at 1:36 PM George McCollister
>>  wrote:
>>>
>>> Can you explain the difference in behavior with what I was observing
>>> on the LAN7431?
>>
>> I'm not using DSA in my application, so I cannot test or replicate
>> what you were observing. It would be great if we could work together
>> and settle on a solution that is acceptable to both of us.
> 
> Sounds good.
> 
>>
>>> I'll retest but if this is reverted I'm going to start
>>> seeing 2 extra bytes on the end of frames and it's going to break DSA
>>> with the LAN7431 again.
>>>
>>
>> Seen from my point of view, your patch is a regression. But perhaps my
>> patch set is a regression for you? Catch 22...
>>
>> Would you be able to identify which patch broke your DSA behaviour?
>> Was it one of mine? Perhaps we can start from there.
> 
> Yes, first I'm going to confirm that what is in the net branch still
> works (unlikely but perhaps something else could have broken it since
> last I tried it).
> Then I'll confirm the patch which I believe broke it actually did and
> report back.
> 
>>
>> Sven

Just an idea:
RX_HEAD_PADDING is an alias for NET_IP_ALIGN that can have two values:
0 and 2
The two systems you use may have different NET_IP_ALIGN values.
This could explain the behavior. Then what I proposed should work
for both of you: frame_length - ETH_FCS_LEN

Re: [PATCH net v2 1/2] net: dsa: lantiq_gswip: Don't use PHY auto polling

[Florian Fainelli]

On 4/8/2021 11:38 AM, Martin Blumenstingl wrote:
> PHY auto polling on the GSWIP hardware can be used so link changes
> (speed, link up/down, etc.) can be detected automatically. Internally
> GSWIP reads the PHY's registers for this functionality. Based on this
> automatic detection GSWIP can also automatically re-configure it's port
> settings. Unfortunately this auto polling (and configuration) mechanism
> seems to cause various issues observed by different people on different
> devices:
> - FritzBox 7360v2: the two Gbit/s ports (connected to the two internal
>   PHY11G instances) are working fine but the two Fast Ethernet ports
>   (using an AR8030 RMII PHY) are completely dead (neither RX nor TX are
>   received). It turns out that the AR8030 PHY sets the BMSR_ESTATEN bit
>   as well as the ESTATUS_1000_TFULL and ESTATUS_1000_XFULL bits. This
>   makes the PHY auto polling state machine (rightfully?) think that the
>   established link speed (when the other side is Gbit/s capable) is
>   1Gbit/s.
> - None of the Ethernet ports on the Zyxel P-2812HNU-F1 (two are
>   connected to the internal PHY11G GPHYs while the other three are
>   external RGMII PHYs) are working. Neither RX nor TX traffic was
>   observed. It is not clear which part of the PHY auto polling state-
>   machine caused this.
> - FritzBox 7412 (only one LAN port which is connected to one of the
>   internal GPHYs running in PHY22F / Fast Ethernet mode) was seeing
>   random disconnects (link down events could be seen). Sometimes all
>   traffic would stop after such disconnect. It is not clear which part
>   of the PHY auto polling state-machine cauased this.
> - TP-Link TD-W9980 (two ports are connected to the internal GPHYs
>   running in PHY11G / Gbit/s mode, the other two are external RGMII
>   PHYs) was affected by similar issues as the FritzBox 7412 just without
>   the "link down" events
> 
> Switch to software based configuration instead of PHY auto polling (and
> letting the GSWIP hardware configure the ports automatically) for the
> following link parameters:
> - link up/down
> - link speed
> - full/half duplex
> - flow control (RX / TX pause)
> 
> After a big round of manual testing by various people (who helped test
> this on OpenWrt) it turns out that this fixes all reported issues.
> 
> Additionally it can be considered more future proof because any
> "quirk" which is implemented for a PHY on the driver side can now be
> used with the GSWIP hardware as well because Linux is in control of the
> link parameters.
> 
> As a nice side-effect this also solves a problem where fixed-links were
> not supported previously because we were relying on the PHY auto polling
> mechanism, which cannot work for fixed-links as there's no PHY from
> where it can read the registers. Configuring the link settings on the
> GSWIP ports means that we now use the settings from device-tree also for
> ports with fixed-links.
> 
> Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
> Fixes: 3e6fdeb28f4c33 ("net: dsa: lantiq_gswip: Let GSWIP automatically set 
> the xMII clock")
> Cc: sta...@vger.kernel.org
> Acked-by: Hauke Mehrtens 
> Reviewed-by: Andrew Lunn 
> Signed-off-by: Martin Blumenstingl 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH net v2 2/2] net: dsa: lantiq_gswip: Configure all remaining GSWIP_MII_CFG bits

[Florian Fainelli]

On 4/8/2021 11:38 AM, Martin Blumenstingl wrote:
> There are a few more bits in the GSWIP_MII_CFG register for which we
> did rely on the boot-loader (or the hardware defaults) to set them up
> properly.
> 
> For some external RMII PHYs we need to select the GSWIP_MII_CFG_RMII_CLK
> bit and also we should un-set it for non-RMII PHYs. The
> GSWIP_MII_CFG_RMII_CLK bit is ignored for other PHY connection modes.
> 
> The GSWIP IP also supports in-band auto-negotiation for RGMII PHYs when
> the GSWIP_MII_CFG_RGMII_IBS bit is set. Clear this bit always as there's
> no known hardware which uses this (so it is not tested yet).
> 
> Clear the xMII isolation bit when set at initialization time if it was
> previously set by the bootloader. Not doing so could lead to no traffic
> (neither RX nor TX) on a port with this bit set.
> 
> While here, also add the GSWIP_MII_CFG_RESET bit. We don't need to
> manage it because this bit is self-clearning when set. We still add it
> here to get a better overview of the GSWIP_MII_CFG register.
> 
> Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
> Cc: sta...@vger.kernel.org
> Suggested-by: Hauke Mehrtens 
> Acked-by: Hauke Mehrtens 
> Signed-off-by: Martin Blumenstingl 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [OpenRISC] [PATCH v6 1/9] locking/qspinlock: Add ARCH_USE_QUEUED_SPINLOCKS_XCHG32

[Waiman Long]

On 4/6/21 7:52 PM, Stafford Horne wrote:


For OpenRISC I did ack the patch to convert to
CONFIG_ARCH_USE_QUEUED_SPINLOCKS_XCHG32=y.  But I think you are right, the
generic code in xchg_tail and the xchg16 emulation code in produced by OpenRISC
using xchg32 would produce very similar code.  I have not compared instructions,
but it does seem like duplicate functionality.

Why doesn't RISC-V add the xchg16 emulation code similar to OpenRISC?  For
OpenRISC we added xchg16 and xchg8 emulation code to enable qspinlocks.  So
one thought is with CONFIG_ARCH_USE_QUEUED_SPINLOCKS_XCHG32=y, can we remove our
xchg16/xchg8 emulation code?


For the record, the latest qspinlock code doesn't use xchg8 anymore. It 
still need xchg16, though.


Cheers,
Longman

Re: [Freedreno] [PATCH 1/3] drm/msm/mdp5: Configure PP_SYNC_HEIGHT to double the vtotal

[Rob Clark]

On Wed, Apr 7, 2021 at 12:11 PM AngeloGioacchino Del Regno
 wrote:
>
> Il 07/04/21 20:19, abhin...@codeaurora.org ha scritto:
> > Hi Marijn
> >
> > On 2021-04-06 14:47, Marijn Suijten wrote:
> >> Leaving this at a close-to-maximum register value 0xFFF0 means it takes
> >> very long for the MDSS to generate a software vsync interrupt when the
> >> hardware TE interrupt doesn't arrive.  Configuring this to double the
> >> vtotal (like some downstream kernels) leads to a frame to take at most
> >> twice before the vsync signal, until hardware TE comes up.
> >>
> >> In this case the hardware interrupt responsible for providing this
> >> signal - "disp-te" gpio - is not hooked up to the mdp5 vsync/pp logic at
> >> all.  This solves severe panel update issues observed on at least the
> >> Xperia Loire and Tone series, until said gpio is properly hooked up to
> >> an irq.
> >
> > The reason the CONFIG_HEIGHT was at such a high value is to make sure that
> > we always get the TE only from the panel vsync and not false positives
> > coming
> > from the tear check logic itself.
> >
> > When you say that disp-te gpio is not hooked up, is it something
> > incorrect with
> > the schematic OR panel is not generating the TE correctly?
> >
>
> Sometimes, some panels aren't getting correctly configured by the
> OEM/ODM in the first place: especially when porting devices from
> downstream to upstream, developers often get in a situation in which
> their TE line is either misconfigured or the DriverIC is not configured
> to raise V-Sync interrupts.
> Please remember: some DDICs need a "commands sequence" to enable
> generating the TE interrupts, sometimes this is not standard, and
> sometimes OEMs/ODMs are not even doing that in their downstream code
> (but instead they work around it in creative ways "for reasons", even
> though their DDIC supports indeed sending TE events).
>
> This mostly happens when bringing up devices that have autorefresh
> enabled from the bootloader (when the bootloader sets up the splash
> screen) by using simple-panel as a (hopefully) temporary solution to get
> through the initial stages of porting.
>
> We are not trying to cover cases related to incorrect schematics or
> hardware mistakes here, as the fix for that - as you know - is to just
> fix your hardware.
> What we're trying to do here is to stop freezes and, in some cases,
> lockups, other than false positives making the developer go offroad when
> the platform shows that something is wrong during early porting.
>
> Also, sometimes, some DDICs will not generate TE interrupts when
> expected... in these cases we get a PP timeout and a MDP5 recovery: this
> is totally avoidable if we rely on the 2*vtotal, as we wouldn't get
> through the very time consuming task of recovering the entire MDP.
>
> Of course, if something is wrong in the MDP and the block really needs
> recovery, this "trick" won't save anyone and the recovery will anyway be
> triggered, as the PP-done will anyway timeout.

So, is this (mostly) a workaround due to TE not wired up?  In which
case I think it is ok, but maybe should have a comment about the
interaction with TE?

Currently I have this patch in msm-next-staging but I guess we need to
decide in the next day or so whether to drop it or smash in a comment?

BR,
-R

> >>
> >> Suggested-by: AngeloGioacchino Del Regno
> >> 
> >> Signed-off-by: Marijn Suijten 
> >> Reviewed-by: AngeloGioacchino Del Regno
> >> 
> >> ---
> >>  drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> >> b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> >> index ff2c1d583c79..2d5ac03dbc17 100644
> >> --- a/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> >> +++ b/drivers/gpu/drm/msm/disp/mdp5/mdp5_cmd_encoder.c
> >> @@ -51,7 +51,7 @@ static int pingpong_tearcheck_setup(struct
> >> drm_encoder *encoder,
> >>
> >>  mdp5_write(mdp5_kms, REG_MDP5_PP_SYNC_CONFIG_VSYNC(pp_id), cfg);
> >>  mdp5_write(mdp5_kms,
> >> -REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), 0xfff0);
> >> +REG_MDP5_PP_SYNC_CONFIG_HEIGHT(pp_id), (2 * mode->vtotal));
> >>  mdp5_write(mdp5_kms,
> >>  REG_MDP5_PP_VSYNC_INIT_VAL(pp_id), mode->vdisplay);
> >>  mdp5_write(mdp5_kms, REG_MDP5_PP_RD_PTR_IRQ(pp_id),
> >> mode->vdisplay + 1);
>

RE: [Intel-wired-lan] [PATCH][next] ice: Fix potential infinite loop when using u8 loop counter

[Brelinski, TonyX]

> -Original Message-
> From: Intel-wired-lan  On Behalf Of
> Colin King
> Sent: Wednesday, March 31, 2021 7:46 AM
> To: Brandeburg, Jesse ; Nguyen, Anthony L
> ; David S . Miller ;
> Jakub Kicinski ; Cao, Chinh T ;
> intel-wired-...@lists.osuosl.org; net...@vger.kernel.org
> Cc: kernel-janit...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH][next] ice: Fix potential infinite loop when
> using u8 loop counter
> 
> From: Colin Ian King 
> 
> A for-loop is using a u8 loop counter that is being compared to a u32
> cmp_dcbcfg->numapp to check for the end of the loop. If cmp_dcbcfg-
> >numapp is larger than 255 then the counter j will wrap around to zero and
> hence an infinite loop occurs. Fix this by making counter j the same type as
> cmp_dcbcfg->numapp.
> 
> Addresses-Coverity: ("Infinite loop")
> Fixes: aeac8ce864d9 ("ice: Recognize 860 as iSCSI port in CEE mode")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/net/ethernet/intel/ice/ice_dcb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Tested-by: Tony Brelinski  A Contingent Worker at 
Intel

Re: [PATCH] block: Fix sys_ioprio_set(.which=IOPRIO_WHO_PGRP) task iteration

[Jens Axboe]

On 4/8/21 3:46 AM, Peter Zijlstra wrote:
> 
> do_each_pid_thread() { } while_each_pid_thread() is a double loop and
> thus break doesn't work as expected. Also, it should be used under
> tasklist_lock because otherwise we can race against change_pid() for
> PGID/SID.

Applied, thanks.

-- 
Jens Axboe

[PATCH] pinctrl: samsung: use 'int' for register masks in Exynos

[Krzysztof Kozlowski]

The Special Function Registers on all Exynos SoC, including ARM64, are
32-bit wide, so entire driver uses matching functions like readl() or
writel().  On 64-bit ARM using unsigned long for register masks:
1. makes little sense as immediately after bitwise operation it will be
   cast to 32-bit value when calling writel(),
2. is actually error-prone because it might promote other operands to
   64-bit.

Addresses-Coverity: Unintentional integer overflow
Signed-off-by: Krzysztof Kozlowski 

---

Not tested on ARM64.

Dear Linus,

Please apply it directly, I don't have any patches for Samsung pinctrl
in my tree.
---
 drivers/pinctrl/samsung/pinctrl-exynos.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/pinctrl/samsung/pinctrl-exynos.c 
b/drivers/pinctrl/samsung/pinctrl-exynos.c
index 0cd7f33cdf25..2b99f4130e1e 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos.c
@@ -55,7 +55,7 @@ static void exynos_irq_mask(struct irq_data *irqd)
struct exynos_irq_chip *our_chip = to_exynos_irq_chip(chip);
struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(irqd);
unsigned long reg_mask = our_chip->eint_mask + bank->eint_offset;
-   unsigned long mask;
+   unsigned int mask;
unsigned long flags;
 
raw_spin_lock_irqsave(>slock, flags);
@@ -83,7 +83,7 @@ static void exynos_irq_unmask(struct irq_data *irqd)
struct exynos_irq_chip *our_chip = to_exynos_irq_chip(chip);
struct samsung_pin_bank *bank = irq_data_get_irq_chip_data(irqd);
unsigned long reg_mask = our_chip->eint_mask + bank->eint_offset;
-   unsigned long mask;
+   unsigned int mask;
unsigned long flags;
 
/*
@@ -483,7 +483,7 @@ static void exynos_irq_eint0_15(struct irq_desc *desc)
chained_irq_exit(chip, desc);
 }
 
-static inline void exynos_irq_demux_eint(unsigned long pend,
+static inline void exynos_irq_demux_eint(unsigned int pend,
struct irq_domain *domain)
 {
unsigned int irq;
@@ -500,8 +500,8 @@ static void exynos_irq_demux_eint16_31(struct irq_desc 
*desc)
 {
struct irq_chip *chip = irq_desc_get_chip(desc);
struct exynos_muxed_weint_data *eintd = irq_desc_get_handler_data(desc);
-   unsigned long pend;
-   unsigned long mask;
+   unsigned int pend;
+   unsigned int mask;
int i;
 
chained_irq_enter(chip, desc);
-- 
2.25.1

[GIT PULL] Please pull RDMA subsystem changes

[Jason Gunthorpe]

Hi Linus,

Nothing very exciting here, just a few small bug fixes. No red flags
for this release have shown up.

Thanks,
Jason

The following changes since commit a5e13c6df0e41702d2b2c77c8ad41677ebb065b3:

  Linux 5.12-rc5 (2021-03-28 15:48:16 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus

for you to fetch changes up to d1c803a9ccd7bd3aff5e989ccfb39ed3b799b975:

  RDMA/addr: Be strict with gid size (2021-04-08 16:14:56 -0300)


RDMA 5.12 third rc pull request

Several bug fixes:

- Regression from the last pull request in cxgb4 related to the ipv6 fixes

- KASAN crasher in rtrs

- oops in hfi1 related to a buggy BIOS

- Userspace could oops qedr's XRC support

- Uninitialized memory when parsing a LS_NLA_TYPE_DGID netlink message


Kamal Heib (1):
  RDMA/qedr: Fix kernel panic when trying to access recv_cq

Leon Romanovsky (1):
  RDMA/addr: Be strict with gid size

Md Haris Iqbal (1):
  RDMA/rtrs-clt: Close rtrs client conn before destroying rtrs clt session 
files

Mike Marciniszyn (1):
  IB/hfi1: Fix probe time panic when AIP is enabled with a buggy BIOS

Potnuri Bharat Teja (1):
  RDMA/cxgb4: check for ipv6 address properly while destroying listener

 drivers/infiniband/core/addr.c |  4 +++-
 drivers/infiniband/hw/cxgb4/cm.c   |  3 ++-
 drivers/infiniband/hw/hfi1/affinity.c  | 21 +
 drivers/infiniband/hw/hfi1/hfi.h   |  1 +
 drivers/infiniband/hw/hfi1/init.c  | 10 +-
 drivers/infiniband/hw/hfi1/netdev_rx.c |  3 +--
 drivers/infiniband/hw/qedr/verbs.c |  3 ++-
 drivers/infiniband/ulp/rtrs/rtrs-clt.c |  2 +-
 8 files changed, 24 insertions(+), 23 deletions(-)


signature.asc
Description: PGP signature

Re: [PATCH net v1] Revert "lan743x: trim all 4 bytes of the FCS; not just 2"

[George McCollister]

On Thu, Apr 8, 2021 at 1:35 PM Sven Van Asbroeck  wrote:
>
> Hi George,
>
> On Thu, Apr 8, 2021 at 2:26 PM Sven Van Asbroeck  wrote:
> >
> > George, I will send a patch for you to try shortly. Except if you're
> > already ahead :)
>
> Would this work for you? It does for me.

Works for me too.

>
> diff --git a/drivers/net/ethernet/microchip/lan743x_main.c
> b/drivers/net/ethernet/microchip/lan743x_main.c
> index dbdfabff3b00..7b6794aa8ea9 100644
> --- a/drivers/net/ethernet/microchip/lan743x_main.c
> +++ b/drivers/net/ethernet/microchip/lan743x_main.c
> @@ -885,8 +885,8 @@ static int lan743x_mac_set_mtu(struct
> lan743x_adapter *adapter, int new_mtu)
> }
>
> mac_rx &= ~(MAC_RX_MAX_SIZE_MASK_);
> -   mac_rx |= (((new_mtu + ETH_HLEN + 4) << MAC_RX_MAX_SIZE_SHIFT_) &
> - MAC_RX_MAX_SIZE_MASK_);
> +   mac_rx |= (((new_mtu + ETH_HLEN + ETH_FCS_LEN)
> + << MAC_RX_MAX_SIZE_SHIFT_) & MAC_RX_MAX_SIZE_MASK_);
> lan743x_csr_write(adapter, MAC_RX, mac_rx);
>
> if (enabled) {
> @@ -1944,7 +1944,7 @@ static int lan743x_rx_init_ring_element(struct
> lan743x_rx *rx, int index)
> struct sk_buff *skb;
> dma_addr_t dma_ptr;
>
> -   buffer_length = netdev->mtu + ETH_HLEN + 4 + RX_HEAD_PADDING;
> +   buffer_length = netdev->mtu + ETH_HLEN + ETH_FCS_LEN + 
> RX_HEAD_PADDING;
>
> descriptor = >ring_cpu_ptr[index];
> buffer_info = >buffer_info[index];
> @@ -2040,7 +2040,7 @@ lan743x_rx_trim_skb(struct sk_buff *skb, int 
> frame_length)
> dev_kfree_skb_irq(skb);
> return NULL;
> }
> -   frame_length = max_t(int, 0, frame_length - RX_HEAD_PADDING - 2);
> +   frame_length = max_t(int, 0, frame_length - ETH_FCS_LEN);
> if (skb->len > frame_length) {
> skb->tail -= skb->len - frame_length;
> skb->len = frame_length;

[PATCH 01/12] staging: rtl8188eu: remove the last urb callback macros

[Martin Kaiser]

Both usb_read_port_complete and usb_write_port_complete have a regs
parameter that is not used.

When this parameter is removed, the functions can be used as urb
completion callbacks directly. There's no need for the macros that
strip the second parameter.

Signed-off-by: Martin Kaiser 
---
 drivers/staging/rtl8188eu/include/usb_ops_linux.h | 5 -
 drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c  | 4 ++--
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/usb_ops_linux.h 
b/drivers/staging/rtl8188eu/include/usb_ops_linux.h
index 2f4976d251a1..0262ace52e71 100644
--- a/drivers/staging/rtl8188eu/include/usb_ops_linux.h
+++ b/drivers/staging/rtl8188eu/include/usb_ops_linux.h
@@ -10,11 +10,6 @@
 #define USB_HIGH_SPEED_BULK_SIZE   512
 #define USB_FULL_SPEED_BULK_SIZE   64
 
-#define usb_write_port_complete(purb, regs)\
-   usb_write_port_complete(purb)
-#define usb_read_port_complete(purb, regs) \
-   usb_read_port_complete(purb)
-
 unsigned int ffaddr2pipehdl(struct dvobj_priv *pdvobj, u32 addr);
 
 u8 usb_read8(struct adapter *adapter, u32 addr);
diff --git a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c 
b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
index f2fa4fb3595f..28655f41a75b 100644
--- a/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
+++ b/drivers/staging/rtl8188eu/os_dep/usb_ops_linux.c
@@ -334,7 +334,7 @@ u32 usb_read32(struct adapter *adapter, u32 addr)
return le32_to_cpu(data);
 }
 
-static void usb_read_port_complete(struct urb *purb, struct pt_regs *regs)
+static void usb_read_port_complete(struct urb *purb)
 {
struct recv_buf *precvbuf = (struct recv_buf *)purb->context;
struct adapter *adapt = (struct adapter *)precvbuf->adapter;
@@ -519,7 +519,7 @@ int usb_write32(struct adapter *adapter, u32 addr, u32 val)
return usbctrl_vendorreq(adapter, wvalue, , 4, 
REALTEK_USB_VENQT_WRITE);
 }
 
-static void usb_write_port_complete(struct urb *purb, struct pt_regs *regs)
+static void usb_write_port_complete(struct urb *purb)
 {
struct xmit_buf *pxmitbuf = (struct xmit_buf *)purb->context;
struct adapter *padapter = pxmitbuf->padapter;
-- 
2.20.1

Re: [PATCH 6/7] KVM: SVM: hyper-v: Enlightened MSR-Bitmap support

[Paolo Bonzini]

On 07/04/21 16:41, Vineeth Pillai wrote:
  
+#if IS_ENABLED(CONFIG_HYPERV)

+static inline void hv_vmcb_dirty_nested_enlightenments(struct kvm_vcpu *vcpu)
+{
+   struct vmcb *vmcb = to_svm(vcpu)->vmcb;
+
+   /*
+* vmcb can be NULL if called during early vcpu init.
+* And its okay not to mark vmcb dirty during vcpu init
+* as we mark it dirty unconditionally towards end of vcpu
+* init phase.
+*/
+   if (vmcb && vmcb_is_clean(vmcb, VMCB_HV_NESTED_ENLIGHTENMENTS) &&
+   vmcb->hv_enlightenments.hv_enlightenments_control.msr_bitmap)
+   vmcb_mark_dirty(vmcb, VMCB_HV_NESTED_ENLIGHTENMENTS);
+}


In addition to what Vitaly said, can svm->vmcb really be NULL?  If so it 
might be better to reorder initializations and skip the NULL check.


Paolo

Re: 08ed4efad6: stress-ng.sigsegv.ops_per_sec -41.9% regression

[Linus Torvalds]

On Thu, Apr 8, 2021 at 1:32 AM kernel test robot  wrote:
>
> FYI, we noticed a -41.9% regression of stress-ng.sigsegv.ops_per_sec due to 
> commit
> 08ed4efad684 ("[PATCH v10 6/9] Reimplement RLIMIT_SIGPENDING on top of 
> ucounts")

Ouch.

I *think* this test may be testing "send so many signals that it
triggers the signal queue overflow case".

And I *think* that the performance degradation may be due to lots of
unnecessary allocations, because ity looks like that commit changes
__sigqueue_alloc() to do

struct sigqueue *q = kmem_cache_alloc(sigqueue_cachep, flags);

*before* checking the signal limit, and then if the signal limit was
exceeded, it will just be free'd instead.

The old code would check the signal count against RLIMIT_SIGPENDING
*first*, and if there were m ore pending signals then it wouldn't do
anything at all (including not incrementing that expensive atomic
count).

Also, the old code was very careful to only do the "get_user()" for
the *first* signal it added to the queue, and do the "put_user()" for
when removing the last signal. Exactly because those atomics are very
expensive.

The new code just does a lot of these atomics unconditionally.

I dunno. The profile data in there is a bit hard to read, but there's
a lot more cachee misses, and a *lot* of node crossers:

>5961544  +190.4%   17314361perf-stat.i.cache-misses
>   22107466  +119.2%   48457656perf-stat.i.cache-references
> 163292 ą  3%   +4582.0%7645410perf-stat.i.node-load-misses
> 227388 ą  2%   +3708.8%8660824perf-stat.i.node-loads

and (probably as a result) average instruction costs have gone up enormously:

>   3.47   +66.8%   5.79perf-stat.overall.cpi
>  22849   -65.6%   7866
> perf-stat.overall.cycles-between-cache-misses

and it does seem to be at least partly about "put_ucounts()":

>   0.00+4.54.46
> perf-profile.calltrace.cycles-pp.put_ucounts.__sigqueue_free.get_signal.arch_do_signal_or_restart.exit_to_user_mode_prepare

and a lot of "get_ucounts()".

But it may also be that the new "get sigpending" is just *so* much
more expensive than it used to be.

   Linus

Re: [GIT PULL] arm64: dts: TI K3 updates for v5.13

[Nishanth Menon]

On 17:24-20210408, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> On Mon, 5 Apr 2021 10:53:36 -0500, Nishanth Menon wrote:
> > Please pull the following device tree changes for v5.13 cycle.
> > 
> > The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:
> > 
> >   Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)
> > 
> > are available in the Git repository at:
> > 
> > [...]
> 
> Merged into arm/dt, thanks!

Thanks.
> 
> There are a couple added warnings from 'make W=1 dtbs_check' though:
> 
> ti/k3-am64-main.dtsi:376.40-385.4: Warning (simple_bus_reg): 
> /bus@f4000/interrupt-controller0: missing or empty reg/ranges property
> ti/k3-am64-main.dtsi:45.13-135.4: Warning (simple_bus_reg): /bus@f4000/dmss: 
> missing or empty reg/ranges property
> ti/k3-am64-mcu.dtsi:77.39-86.4: Warning (simple_bus_reg): 
> /bus@f4000/bus@400/interrupt-controller1: missing or empty reg/ranges 
> property
> 
> ti/k3-am642-evm.dt.yaml: bus@400: interrupt-controller1: {'type': 
> 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 
> 'ti,intr-trigger-type': [[1]], 'interrupt-controller': True, 
> 'interrupt-parent': [[1]], '#interrupt-cells': [[1]], 'ti,sci': [[4]], 
> 'ti,sci-dev-id': [[5]], 'ti,interrupt-ranges': [[0, 104, 4]], 'phandle': 
> [[5]]}
> ti/k3-am642-evm.dt.yaml: bus@f4000: dmss: {'type': 'object'} is not allowed 
> for {'compatible': ['simple-mfd'], '#address-cells': [[2]], '#size-cells': 
> [[2]], 'dma-ranges': True, 'ranges':  'phandle': [[7]]}}
> ti/k3-am642-evm.dt.yaml: bus@f4000: interrupt-controller0: {'type': 'object'} 
> is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': 
> [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], 
> '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[3]], 
> 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle': [[15]]}
> ti/k3-am642-evm.dt.yaml: flash@0: 'cdns,read-delay', 'cdns,tchsh-ns', 
> 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the 
> regexes: '^partition@', 'pinctrl-[0-9]+'
> ti/k3-am642-sk.dt.yaml: bus@400: interrupt-controller1: {'type': 
> 'object'} is not allowed for {'compatible': ['ti,sci-intr'], 
> 'ti,intr-trigger-type': [[1]], ...
> ti/k3-am642-sk.dt.yaml: bus@f4000: dmss: {'type': 'object'} is not allowed 
> for {'compatible': ['simple-mfd'], ...
> ti/k3-am642-sk.dt.yaml: bus@f4000: interrupt-controller0: {'type': 'object'} 
> is not allowed for {'compatible': ['ti,sci-intr'], 'ti,intr-trigger-type': 
> [[1]], 'interrupt-controller': True, 'interrupt-parent': [[1]], 
> '#interrupt-cells': [[1]], 'ti,sci': [[4]], 'ti,sci-dev-id': [[3]], 
> 'ti,interrupt-ranges': [[0, 32, 16]], 'phandle': [[11]]}
> ti/k3-am642-sk.dt.yaml: flash@0: 'cdns,read-delay', 'cdns,tchsh-ns', 
> 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not match any of the 
> regexes: '^partition@', 'pinctrl-[0-9]+'
> ti/k3-j7200-common-proc-board.dt.yaml: flash@0: 'cdns,read-delay', 
> 'cdns,tchsh-ns', 'cdns,tsd2d-ns', 'cdns,tshsl-ns', 'cdns,tslch-ns' do not 
> match any of the regexes: '^partition@', 'pinctrl-[0-9]+'
> 
> 
> merge commit: 4b8cf90637f295ff1cb1f4bdfde134dab1196296


We have a bunch of problems with interrupt controller definitions -
attempts in [1] [2] did'nt seem to come to any form of conclusion yet.

Cdns is a convert from txt to yaml and is queued on Marks' tree[3]

These issues pre-existed in existing definitions and/or convertion
from txt and we are already working to make sure we try and reach a
conclusion soon[4]. I am guessing from your note that it is high time we
put our foot down on txt bindings and clean yamls, I will ensure we
follow up on that.


[1] 
https://lore.kernel.org/linux-devicetree/cal_jsq++dyikg9smqgx9fapdjnvrezcxnb0y5uh-5_2gbzt...@mail.gmail.com/#t
[2] 
https://lore.kernel.org/linux-arm-kernel/20210311215914.pgpz2yymmfqlainl@episode/
 
[3] 
https://lore.kernel.org/linux-arm-kernel/161726952255.2486.16196604421904035265.b4...@kernel.org/
[4] 
https://lore.kernel.org/linux-arm-kernel/20210311134908.jsh2lywtwzvlyvbc@finally/
-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 
849D 1736 249D

Re: [PATCH] arch/m68k/kernel/sys_m68k: Add missing mmap_read_lock() to sys_cacheflush()

[Liam Howlett]

Forgot the fixes line.

* Liam Howlett  [210407 16:00]:
> When the superuser flushes the entire cache, the mmap_read_lock() is not
> taken, but mmap_read_unlock() is called.  Add the missing
> mmap_read_lock() call.
> 
> Signed-off-by: Liam R. Howlett 
> ---
>  arch/m68k/kernel/sys_m68k.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/m68k/kernel/sys_m68k.c b/arch/m68k/kernel/sys_m68k.c
> index 1c235d8f53f3..f55bdcb8e4f1 100644
> --- a/arch/m68k/kernel/sys_m68k.c
> +++ b/arch/m68k/kernel/sys_m68k.c
> @@ -388,6 +388,8 @@ sys_cacheflush (unsigned long addr, int scope, int cache, 
> unsigned long len)
>   ret = -EPERM;
>   if (!capable(CAP_SYS_ADMIN))
>   goto out;
> +
> + mmap_read_lock(current->mm);
>   } else {
>   struct vm_area_struct *vma;
>  
> -- 
> 2.30.0
From aeee71b15f54426f02f41a4408afbd0b5acab7ec Mon Sep 17 00:00:00 2001
From: "Liam R. Howlett" 
Date: Wed, 7 Apr 2021 11:39:06 -0400
Subject: [PATCH] arch/m68k/kernel/sys_m68k: Add missing mmap_read_lock() to
 sys_cacheflush()

When the superuser flushes the entire cache, the mmap_read_lock() is not
taken, but mmap_read_unlock() is called.  Add the missing
mmap_read_lock() call.

Fixes: cd2567b6850b (m68k: call find_vma with the mmap_sem held in
sys_cacheflush())
Signed-off-by: Liam R. Howlett 
---
 arch/m68k/kernel/sys_m68k.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/m68k/kernel/sys_m68k.c b/arch/m68k/kernel/sys_m68k.c
index 1c235d8f53f3..f55bdcb8e4f1 100644
--- a/arch/m68k/kernel/sys_m68k.c
+++ b/arch/m68k/kernel/sys_m68k.c
@@ -388,6 +388,8 @@ sys_cacheflush (unsigned long addr, int scope, int cache, unsigned long len)
 		ret = -EPERM;
 		if (!capable(CAP_SYS_ADMIN))
 			goto out;
+
+		mmap_read_lock(current->mm);
 	} else {
 		struct vm_area_struct *vma;
 
-- 
2.30.0

Re: [GIT PULL] ARM: at91: dt for 5.13

[Nicolas Ferre]

Hi Arnd,

On 08/04/2021 at 17:24, Arnd Bergmann wrote:

From: Arnd Bergmann 

On Wed, 7 Apr 2021 13:44:15 +0200, nicolas.fe...@microchip.com wrote:

Arnd, Olof,

Here is first batch of dt changes for 5.13. Please pull.

Thanks, best regards,
   Nicolas

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

[...]


Merged into arm/dt, thanks!

I saw two new warnings from 'make dtbs_check W=1':

arch/arm/boot/dts/at91-sama5d2_ptc_ek.dt.yaml: /: 'etm@73C000' does not match 
any of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', 'pinctrl-[0-9]+'
arch/arm/boot/dts/at91-kizbox3-hs.dt.yaml: /: 'etm@73C000' does not match any 
of the regexes: '@(0|[1-9a-f][0-9a-f]*)$', '^[^@]+$', 'pinctrl-[0-9]+'


Oh, got it: it's the upper case letter withing the etm hex address. I 
used this one to mach what was done in the reg property. I'm fixing both 
of them and sending the patch to the ml right now.


Tell me if I add it to a subsequent pull-request or if you prefer to 
take it the soonest in order to not generate additional warnings upstream.


BTW, I now have a dtschema at the proper level of support for running 
"make dtbs_check W=1" and will do it before sending pull-requests in the 
future.


Thanks for the heads-up. Best regards,
  Nicolas



merge commit: e2b064fec8e49112f7dac779fcec12ded40728c2

Arnd




--
Nicolas Ferre

Re: 08ed4efad6: stress-ng.sigsegv.ops_per_sec -41.9% regression

[Alexey Gladkov]

On Thu, Apr 08, 2021 at 09:22:40AM -0700, Linus Torvalds wrote:
> On Thu, Apr 8, 2021 at 1:32 AM kernel test robot  
> wrote:
> >
> > FYI, we noticed a -41.9% regression of stress-ng.sigsegv.ops_per_sec due to 
> > commit
> > 08ed4efad684 ("[PATCH v10 6/9] Reimplement RLIMIT_SIGPENDING on top of 
> > ucounts")
> 
> Ouch.
> 
> I *think* this test may be testing "send so many signals that it
> triggers the signal queue overflow case".
> 
> And I *think* that the performance degradation may be due to lots of
> unnecessary allocations, because ity looks like that commit changes
> __sigqueue_alloc() to do
> 
> struct sigqueue *q = kmem_cache_alloc(sigqueue_cachep, flags);
> 
> *before* checking the signal limit, and then if the signal limit was
> exceeded, it will just be free'd instead.
> 
> The old code would check the signal count against RLIMIT_SIGPENDING
> *first*, and if there were m ore pending signals then it wouldn't do
> anything at all (including not incrementing that expensive atomic
> count).
> 
> Also, the old code was very careful to only do the "get_user()" for
> the *first* signal it added to the queue, and do the "put_user()" for
> when removing the last signal. Exactly because those atomics are very
> expensive.
> 
> The new code just does a lot of these atomics unconditionally.

Yes and right now I'm trying to rewrite this patch.

> I dunno. The profile data in there is a bit hard to read, but there's
> a lot more cachee misses, and a *lot* of node crossers:
> 
> >5961544  +190.4%   17314361perf-stat.i.cache-misses
> >   22107466  +119.2%   48457656perf-stat.i.cache-references
> > 163292 ą  3%   +4582.0%7645410perf-stat.i.node-load-misses
> > 227388 ą  2%   +3708.8%8660824perf-stat.i.node-loads
> 
> and (probably as a result) average instruction costs have gone up enormously:
> 
> >   3.47   +66.8%   5.79perf-stat.overall.cpi
> >  22849   -65.6%   7866
> > perf-stat.overall.cycles-between-cache-misses
> 
> and it does seem to be at least partly about "put_ucounts()":
> 
> >   0.00+4.54.46
> > perf-profile.calltrace.cycles-pp.put_ucounts.__sigqueue_free.get_signal.arch_do_signal_or_restart.exit_to_user_mode_prepare
> 
> and a lot of "get_ucounts()".
> 
> But it may also be that the new "get sigpending" is just *so* much
> more expensive than it used to be.

Thanks for decrypting this! I spent some time to understand this report
and still wasn't sure I understood it.

-- 
Rgrds, legion

Re: [PATCH v1 2/2] drivers/gpu/drm: don't select DMA_CMA or CMA from aspeed or etnaviv

[David Hildenbrand]

On 08.04.21 14:49, Linus Walleij wrote:

On Thu, Apr 8, 2021 at 2:01 PM David Hildenbrand  wrote:


This is something you could do using a hidden helper symbol like

config DRMA_ASPEED_GFX
 bool "Aspeed display driver"
 select DRM_WANT_CMA

config DRM_WANT_CMA
 bool
 help
Select this from any driver that benefits from CMA being enabled

config DMA_CMA
 bool "Use CMA helpers for DRM"
 default DRM_WANT_CMA

   Arnd



That's precisely what I had first, with an additional "WANT_CMA" --  but
looking at the number of such existing options (I was able to spot 1 !)


If you do this it probably makes sense to fix a few other drivers
Kconfig in the process. It's not just a problem with your driver.
"my" drivers:



:) I actually wanted to convert them to "depends on DMA_CMA" but ran 
into recursive dependencies ...



drivers/gpu/drm/mcde/Kconfig
drivers/gpu/drm/pl111/Kconfig
drivers/gpu/drm/tve200/Kconfig


I was assuming these are "real" dependencies. Will it also work without 
DMA_CMA?




certainly needs this as well, and pretty much anything that is
selecting DRM_KMS_CMA_HELPER or
DRM_GEM_CMA_HELPER "wants" DMA_CMA.


"wants" as in "desires to use but can life without" or "wants" as in 
"really needs it". ?


--
Thanks,

David / dhildenb

Re: [RFC PATCH v2 3/4] arm64: Detect FTRACE cases that make the stack trace unreliable

[Mark Brown]

On Mon, Apr 05, 2021 at 03:43:12PM -0500, madve...@linux.microsoft.com wrote:
> From: "Madhavan T. Venkataraman" 
> 
> When CONFIG_DYNAMIC_FTRACE_WITH_REGS is enabled and tracing is activated
> for a function, the ftrace infrastructure is called for the function at
> the very beginning. Ftrace creates two frames:

This looks good to me however I'd really like someone who has a firmer
understanding of what ftrace is doing to double check as it is entirely
likely that I am missing cases here, it seems likely that if I am
missing stuff it's extra stuff that needs to be added and we're not
actually making use of the reliability information yet.


signature.asc
Description: PGP signature

Re: [PATCH v4 2/6] dt-bindings: PCI: Add bindings for Brcmstb endpoint device voltage regulators

[Jim Quinlan]

On Thu, Apr 8, 2021 at 12:20 PM Rob Herring  wrote:
>
> On Tue, Apr 06, 2021 at 02:25:49PM -0400, Jim Quinlan wrote:
> > On Tue, Apr 6, 2021 at 1:32 PM Mark Brown  wrote:
> > >
> > > On Tue, Apr 06, 2021 at 01:26:51PM -0400, Jim Quinlan wrote:
> > > > On Tue, Apr 6, 2021 at 12:47 PM Mark Brown  wrote:
> > >
> > > > > No great problem with having these in the controller node (assming it
> > > > > accurately describes the hardware) but I do think we ought to also be
> > > > > able to describe these per slot.
>
> PCIe is effectively point to point, so there's only 1 slot unless
> there's a PCIe switch in the middle. If that's the case, then it's all
> more complicated.
>
> > > > Can you explain what you think that would look like in the DT?
> > >
> > > I *think* that's just some properties on the nodes for the endpoints,
> > > note that the driver could just ignore them for now.  Not sure where or
> > > if we document any extensions but child nodes are in section 4 of the
> > > v2.1 PCI bus binding.
> >
> > Hi Mark,
> >
> > I'm a little confused -- here is how I remember the chronology of the
> > "DT bindings" commit reviews, please correct me if I'm wrong:
> >
> > o JimQ submitted a pullreq for using voltage regulators in the same
> > style as the existing "rockport" PCIe driver.
> > o After some deliberation, RobH preferred that the voltage regulators
> > should go into the PCIe subnode device's DT node.
>
> IIRC, that's because you said there isn't a standard slot.
Admittedly, I'm not exactly sure what you mean by a "standard slot".
Our PCIIe HW does not support  hotplug or have a presence bit or
anything like that.  Our root complex has one port; it can only
directly connect to a single switch or endpoint. This connection shows
up as slot0.  The voltage regulator(s) involved depend on a GPIO that
turns the power  on/off for the connected device/chip.  The gpio pin
can vary from board to board but this is easily handled in our DT.
Some boards have regulators that are always on and not associated with
a GPIO pin -- these have no representation in our DT.

Regards,
Jim


>
> > o JimQ put the voltage regulators in the subnode device's DT node.
> > o MarkB didn't like the fact that the code did a global search for the
> > regulator since it could not provide the owning struct device* handle.
> > o RobH relented, and said that if it is just two specific and standard
> > voltage regulators, perhaps they can go in the parent DT node after
> > all.
> > o JimQ put the regulators back in the PCIe node.
> > o MarkB now wants the regulators to go back into the child node again?
> >
> > Folks, please advise.
> >
> > Regards,
> > Jim Quinlan
> > Broadcom STB

Re: [PATCH] KVM: X86: Count success and invalid yields

[Sean Christopherson]

On Tue, Apr 06, 2021, Wanpeng Li wrote:
> From: Wanpeng Li 
> 
> To analyze some performance issues with lock contention and scheduling,
> it is nice to know when directed yield are successful or failing.
> 
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/include/asm/kvm_host.h |  2 ++
>  arch/x86/kvm/x86.c  | 26 --
>  2 files changed, 22 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 44f8930..157bcaa 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -1126,6 +1126,8 @@ struct kvm_vcpu_stat {
>   u64 halt_poll_success_ns;
>   u64 halt_poll_fail_ns;
>   u64 nested_run;
> + u64 yield_directed;
> + u64 yield_directed_ignore;
>  };
>  
>  struct x86_instruction_info;
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 16fb395..3b475cd 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -246,6 +246,8 @@ struct kvm_stats_debugfs_item debugfs_entries[] = {
>   VCPU_STAT("halt_poll_success_ns", halt_poll_success_ns),
>   VCPU_STAT("halt_poll_fail_ns", halt_poll_fail_ns),
>   VCPU_STAT("nested_run", nested_run),
> + VCPU_STAT("yield_directed", yield_directed),

This is ambiguous, it's not clear without looking at the code if it's counting
attempts or actual yields.

> + VCPU_STAT("yield_directed_ignore", yield_directed_ignore),

"ignored" also feels a bit misleading, as that implies KVM deliberately ignored
a valid request, whereas many of the failure paths are due to invalid requests
or errors of some kind.

What about mirroring the halt poll stats, i.e. track "attempted" and 
"successful",
as opposed to "attempted" and "ignored/failed".And maybe switched directed
and yield?  I.e. directed_yield_attempted and directed_yield_successful.

Alternatively, would it make sense to do s/directed/pv, or is that not worth the
potential risk of being wrong if a non-paravirt use case comes along?

pv_yield_attempted
pv_yield_successful

>   VM_STAT("mmu_shadow_zapped", mmu_shadow_zapped),
>   VM_STAT("mmu_pte_write", mmu_pte_write),
>   VM_STAT("mmu_pde_zapped", mmu_pde_zapped),
> @@ -8211,21 +8213,33 @@ void kvm_apicv_init(struct kvm *kvm, bool enable)
>  }
>  EXPORT_SYMBOL_GPL(kvm_apicv_init);
>  
> -static void kvm_sched_yield(struct kvm *kvm, unsigned long dest_id)
> +static void kvm_sched_yield(struct kvm_vcpu *vcpu, unsigned long dest_id)
>  {
>   struct kvm_vcpu *target = NULL;
>   struct kvm_apic_map *map;
>  
> + vcpu->stat.yield_directed++;
> +
>   rcu_read_lock();
> - map = rcu_dereference(kvm->arch.apic_map);
> + map = rcu_dereference(vcpu->kvm->arch.apic_map);
>  
>   if (likely(map) && dest_id <= map->max_apic_id && 
> map->phys_map[dest_id])
>   target = map->phys_map[dest_id]->vcpu;
>  
>   rcu_read_unlock();
> + if (!target)
> + goto no_yield;
> +
> + if (!READ_ONCE(target->ready))

I vote to keep these checks together.  That'll also make the addition of the
"don't yield to self" check match the order of ready vs. self in 
kvm_vcpu_on_spin().

if (!target || !READ_ONCE(target->ready))

> + goto no_yield;
>  
> - if (target && READ_ONCE(target->ready))
> - kvm_vcpu_yield_to(target);
> + if (kvm_vcpu_yield_to(target) <= 0)
> + goto no_yield;
> + return;
> +
> +no_yield:
> + vcpu->stat.yield_directed_ignore++;
> + return;
>  }
>  
>  int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
> @@ -8272,7 +8286,7 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
>   break;
>  
>   kvm_pv_kick_cpu_op(vcpu->kvm, a0, a1);
> - kvm_sched_yield(vcpu->kvm, a1);
> + kvm_sched_yield(vcpu, a1);
>   ret = 0;
>   break;
>  #ifdef CONFIG_X86_64
> @@ -8290,7 +8304,7 @@ int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
>   if (!guest_pv_has(vcpu, KVM_FEATURE_PV_SCHED_YIELD))
>   break;
>  
> - kvm_sched_yield(vcpu->kvm, a0);
> + kvm_sched_yield(vcpu, a0);
>   ret = 0;
>   break;
>   default:
> -- 
> 2.7.4
> 

Re: [PATCH 3/4] mce/copyin: fix to not SIGBUS when copying from user hits poison

[Luck, Tony]

On Thu, Apr 08, 2021 at 10:49:58AM +0200, Borislav Petkov wrote:
> On Wed, Apr 07, 2021 at 02:43:10PM -0700, Luck, Tony wrote:
> > On Wed, Apr 07, 2021 at 11:18:16PM +0200, Borislav Petkov wrote:
> > > On Thu, Mar 25, 2021 at 05:02:34PM -0700, Tony Luck wrote:
> > > > Andy Lutomirski pointed out that sending SIGBUS to tasks that
> > > > hit poison in the kernel copying syscall parameters from user
> > > > address space is not the right semantic.
> > > 
> > > What does that mean exactly?
> > 
> > Andy said that a task could check a memory range for poison by
> > doing:
> > 
> > ret = write(fd, buf, size);
> > if (ret == size) {
> > memory range is all good
> > }
> > 
> > That doesn't work if the kernel sends a SIGBUS.
> > 
> > It doesn't seem a likely scenario ... but Andy is correct that
> > the above ought to work.
> 
> We need to document properly what this is aiming to fix. He said
> something yesterday along the lines of kthread_use_mm() hitting a SIGBUS
> when a kthread "attaches" to an address space. I'm still unclear as to
> how exactly that happens - there are only a handful of kthread_use_mm()
> users in the tree...

Also not clear to me either ... but sending a SIGBUS to a kthread isn't
going to do anything useful. So avoiding doing that is another worthy
goal.

> > Yes. This is for kernel reading memory belongng to "current" task.
> 
> Provided "current" is really the task to which the poison page belongs.
> That kthread_use_mm() thing sounded like the wrong task gets killed. But that
> needs more details.

With these patches nothing gets killed when kernel touches user poison.
If this is in a regular system call then these patches will return EFAULT
to the user (but now that I see EHWPOISON exists that looks like a better
choice - so applications can distinguish the "I just used an invalid address in
a parameter to a syscall" from "This isn't my fault, the memory broke".

> > Same in that the page gets unmapped. Different in that there
> > is no SIGBUS if the kernel did the access for the user.
> 
> What is even the actual use case with sending tasks SIGBUS on poison
> consumption? KVM? Others?

KVM apparently passes a machine check into the guest. Though it seems
to be misisng the MCG_STATUS information to tell the guest whether this
is an "Action Required" machine check, or an "Action Optional" (i.e.
whether the poison was found synchonously by execution of the current
instruction, or asynchronously).

> Are we documenting somewhere: "if your process gets a SIGBUS and this
> and that, which means your page got offlined, you should do this and
> that to recover"?

There is the ancient Documentation/vm/hwpoison.rst from 2009 ... nothing
seems wrong in that, but could use some updates.  I don't know how much
detail we might want to go into on recovery stratgies for applications.
In terms of production s/w there was one ISV who prototyped recovery
for their application but last time I checked didn't enable it in the
production version.

Essentially it boils down to:
SIGBUS handler gets additional data giving virtual address that has gone away

1) Can the application replace the lost page?
Use mmap(addr, MAP_FIXED, ...) to map a fresh page into the gap
and fill with replacement data. This case can return from SIGBUS
handler to re-execute failed instruction
2) Can the application continue in degraded mode w/o the lost page?
Hunt down pointers to lost page and update structures to say
"this data lost". Use siglongjmp() to go to preset recovery path
3) Can the application shut down gracefully?
Record details of the lost page. Inform next-of-kin. Exit.
4) Default - just exit

-Tony

[PATCH] remoteproc: qcom: pas: Add modem support for SDX55

[Manivannan Sadhasivam]

Add remoteproc support for Hexagon modem found on the Qualcomm SDX55
platform.

Signed-off-by: Manivannan Sadhasivam 
---
 drivers/remoteproc/qcom_q6v5_pas.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/remoteproc/qcom_q6v5_pas.c 
b/drivers/remoteproc/qcom_q6v5_pas.c
index e635454d6170..292141877260 100644
--- a/drivers/remoteproc/qcom_q6v5_pas.c
+++ b/drivers/remoteproc/qcom_q6v5_pas.c
@@ -785,6 +785,22 @@ static const struct adsp_data wcss_resource_init = {
.ssctl_id = 0x12,
 };
 
+static const struct adsp_data sdx55_mpss_resource = {
+   .crash_reason_smem = 421,
+   .firmware_name = "modem.mdt",
+   .pas_id = 4,
+   .has_aggre2_clk = false,
+   .auto_boot = true,
+   .proxy_pd_names = (char*[]){
+   "cx",
+   "mss",
+   NULL
+   },
+   .ssr_name = "mpss",
+   .sysmon_name = "modem",
+   .ssctl_id = 0x22,
+};
+
 static const struct of_device_id adsp_of_match[] = {
{ .compatible = "qcom,msm8974-adsp-pil", .data = _resource_init},
{ .compatible = "qcom,msm8996-adsp-pil", .data = _resource_init},
@@ -797,6 +813,7 @@ static const struct of_device_id adsp_of_match[] = {
{ .compatible = "qcom,sc7180-mpss-pas", .data = _resource_init},
{ .compatible = "qcom,sdm845-adsp-pas", .data = _resource_init},
{ .compatible = "qcom,sdm845-cdsp-pas", .data = _resource_init},
+   { .compatible = "qcom,sdx55-mpss-pas", .data = _mpss_resource},
{ .compatible = "qcom,sm8150-adsp-pas", .data = _adsp_resource},
{ .compatible = "qcom,sm8150-cdsp-pas", .data = _cdsp_resource},
{ .compatible = "qcom,sm8150-mpss-pas", .data = _resource_init},
-- 
2.25.1

Re: [PATCH 04/10] mm/migrate: make migrate_pages() return nr_succeeded

[Yang Shi]

On Thu, Apr 8, 2021 at 3:14 AM Oscar Salvador  wrote:
>
> On Thu, Apr 01, 2021 at 11:32:23AM -0700, Dave Hansen wrote:
> >
> > From: Yang Shi 
> >
> > The migrate_pages() returns the number of pages that were not migrated,
> > or an error code.  When returning an error code, there is no way to know
> > how many pages were migrated or not migrated.
> >
> > In the following patch, migrate_pages() is used to demote pages to PMEM
> > node, we need account how many pages are reclaimed (demoted) since page
> > reclaim behavior depends on this.  Add *nr_succeeded parameter to make
> > migrate_pages() return how many pages are demoted successfully for all
> > cases.
> >
> > Signed-off-by: Yang Shi 
> > Signed-off-by: Dave Hansen 
> > Reviewed-by: Yang Shi 
> > Cc: Wei Xu 
> > Cc: Huang Ying 
> > Cc: Dan Williams 
> > Cc: David Hildenbrand 
> > Cc: osalvador 
> >
>
> ...
> >  int migrate_pages(struct list_head *from, new_page_t get_new_page,
> >   free_page_t put_new_page, unsigned long private,
> > - enum migrate_mode mode, int reason)
> > + enum migrate_mode mode, int reason, unsigned int 
> > *nr_succeeded)
> >  {
> >   int retry = 1;
> >   int thp_retry = 1;
> >   int nr_failed = 0;
> > - int nr_succeeded = 0;
> >   int nr_thp_succeeded = 0;
> >   int nr_thp_failed = 0;
> >   int nr_thp_split = 0;
> > @@ -1611,10 +1611,10 @@ retry:
> >   case MIGRATEPAGE_SUCCESS:
> >   if (is_thp) {
> >   nr_thp_succeeded++;
> > - nr_succeeded += nr_subpages;
> > + *nr_succeeded += nr_subpages;
> >   break;
> >   }
> > - nr_succeeded++;
> > + (*nr_succeeded)++;
> >   break;
> >   default:
> >   /*
> > @@ -1643,12 +1643,12 @@ out:
> >*/
> >   list_splice(_pages, from);
> >
> > - count_vm_events(PGMIGRATE_SUCCESS, nr_succeeded);
> > + count_vm_events(PGMIGRATE_SUCCESS, *nr_succeeded);
> >   count_vm_events(PGMIGRATE_FAIL, nr_failed);
> >   count_vm_events(THP_MIGRATION_SUCCESS, nr_thp_succeeded);
> >   count_vm_events(THP_MIGRATION_FAIL, nr_thp_failed);
> >   count_vm_events(THP_MIGRATION_SPLIT, nr_thp_split);
> > - trace_mm_migrate_pages(nr_succeeded, nr_failed, nr_thp_succeeded,
> > + trace_mm_migrate_pages(*nr_succeeded, nr_failed, nr_thp_succeeded,
> >  nr_thp_failed, nr_thp_split, mode, reason);
>
> It seems that reclaiming is the only user who cared about how many pages
> could we migrated, could not do the following instead:
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 695a594e5860..d4170b7ea2fe 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1503,7 +1503,7 @@ static inline int try_split_thp(struct page *page, 
> struct page **page2,
>   */
>  int migrate_pages(struct list_head *from, new_page_t get_new_page,
> free_page_t put_new_page, unsigned long private,
> -   enum migrate_mode mode, int reason)
> +   enum migrate_mode mode, int reason, unsigned int 
> *ret_succeeded)
>  {
> int retry = 1;
> int thp_retry = 1;
> @@ -1654,6 +1654,9 @@ int migrate_pages(struct list_head *from, new_page_t 
> get_new_page,
> if (!swapwrite)
> current->flags &= ~PF_SWAPWRITE;
>
> +   if (ret_succedded)
> +   *ret_succedded = nr_succedded;
> +
> return rc;
>  }
>
>  And pass only a valid pointer from demote_page_list() and NULL from all
>  the others?
>  I was just wondered after all those "unsigned int nr_succedded" in all
>  other functions.
>  This would also solve the "be careful to initialize nr_succedded"
>  problem?

Thanks, Oscar. Yes, kind of. But we have to remember to initialize
"nr_succedded" pointer properly for every migrate_pages() callsite,
right? And it doesn't prevent from returning wrong value if
migrate_pages() is called multiple times by one caller although there
might be not such case (calls migrate_pages() multiple times and care
about nr_succeded) for now.

So IMHO I do prefer Wei's suggestion to have migrate_pages()
initialize nr_succeeded. This seems simpler.


>
>
> --
> Oscar Salvador
> SUSE L3

RE: [PATCH net-next v3 2/2] misc: Add Renesas Synchronization Management Unit (SMU) support

[Min Li]

> 
> Again, please make this only one file.
> 
Hi Greg, the 2 boards have some same named registers in idt82p33_reg.h and 
idt8a340_reg.h
so if I put them all in the same file, there will be name conflicts.