[PATCH v2] ASoC: Intel: Skylake: skl-topology: fix -frame-larger-than

[Nick Desaulniers]

Fixes:
sound/soc/intel/skylake/skl-topology.c:3613:13: warning: stack frame
size of 1304 bytes in function 'skl_tplg_complete'
[-Wframe-larger-than=]

struct snd_ctl_elem_value is 1224 bytes in my configuration.

Heap allocate it, then free it within the current frame.

Signed-off-by: Nick Desaulniers 
---
Changes V1 -> V2: rebased on mainline.

 sound/soc/intel/skylake/skl-topology.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/sound/soc/intel/skylake/skl-topology.c 
b/sound/soc/intel/skylake/skl-topology.c
index b824086203b9..566d07b4b523 100644
--- a/sound/soc/intel/skylake/skl-topology.c
+++ b/sound/soc/intel/skylake/skl-topology.c
@@ -3613,10 +3613,15 @@ static int skl_manifest_load(struct snd_soc_component 
*cmpnt, int index,
 static void skl_tplg_complete(struct snd_soc_component *component)
 {
struct snd_soc_dobj *dobj;
-   struct snd_soc_acpi_mach *mach =
-   dev_get_platdata(component->card->dev);
+   struct snd_soc_acpi_mach *mach;
+   struct snd_ctl_elem_value *val;
int i;
 
+   val = kzalloc(sizeof(*val), GFP_KERNEL);
+   if (!val)
+   return;
+
+   mach = dev_get_platdata(component->card->dev);
list_for_each_entry(dobj, &component->dobj_list, list) {
struct snd_kcontrol *kcontrol = dobj->control.kcontrol;
struct soc_enum *se;
@@ -3632,14 +3637,13 @@ static void skl_tplg_complete(struct snd_soc_component 
*component)
sprintf(chan_text, "c%d", mach->mach_params.dmic_num);
 
for (i = 0; i < se->items; i++) {
-   struct snd_ctl_elem_value val = {};
-
if (strstr(texts[i], chan_text)) {
-   val.value.enumerated.item[0] = i;
-   kcontrol->put(kcontrol, &val);
+   val->value.enumerated.item[0] = i;
+   kcontrol->put(kcontrol, val);
}
}
}
+   kfree(val);
 }
 
 static struct snd_soc_tplg_ops skl_tplg_ops  = {

base-commit: 88fe49249c99de14e543c632a46248d85411ab9e
-- 
2.25.1

[PATCH v3] iommu/tegra-smmu: Add pagetable mappings to debugfs

[Nicolin Chen]

This patch dumps all active mapping entries from pagetable
to a debugfs directory named "mappings".

Ataching an example:

SWGROUP: hc
ASID: 0
reg: 0x250
PTB_ASID: 0xe0080004
as->pd_dma: 0x80004000
{
[1023] 0xf008000b (1)
{
PTE RANGE  | ATTR | PHYS   | IOVA   
| SIZE
[#1023, #1023] | 0x5  | 0x000111a8d000 | 0xf000 
| 0x1000
}
}
Total PDE count: 1
Total PTE count: 1

Signed-off-by: Nicolin Chen 
---
Changelog
v3:
 * Fixed PHYS and IOVA print formats
 * Changed variables to unsigned int type
 * Changed the table outputs to be compact
v2: https://lkml.org/lkml/2021/3/9/1382
 * Expanded mutex range to the entire function
 * Added as->lock to protect pagetable walkthrough
 * Replaced devm_kzalloc with devm_kcalloc for group_debug
 * Added "PTE RANGE" and "SIZE" columns to group contiguous mappings
 * Dropped as->count check; added WARN_ON when as->count mismatches pd[pd_index]
v1: https://lkml.org/lkml/2020/9/26/70

 drivers/iommu/tegra-smmu.c | 175 +++--
 1 file changed, 170 insertions(+), 5 deletions(-)

diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index 97eb62f667d2..269737d51ad4 100644
--- a/drivers/iommu/tegra-smmu.c
+++ b/drivers/iommu/tegra-smmu.c
@@ -19,6 +19,11 @@
 #include 
 #include 
 
+struct tegra_smmu_group_debug {
+   const struct tegra_smmu_swgroup *group;
+   void *priv;
+};
+
 struct tegra_smmu_group {
struct list_head list;
struct tegra_smmu *smmu;
@@ -47,6 +52,8 @@ struct tegra_smmu {
struct dentry *debugfs;
 
struct iommu_device iommu;  /* IOMMU Core code handle */
+
+   struct tegra_smmu_group_debug *group_debug;
 };
 
 struct tegra_smmu_as {
@@ -152,6 +159,9 @@ static inline u32 smmu_readl(struct tegra_smmu *smmu, 
unsigned long offset)
 
 #define SMMU_PDE_ATTR  (SMMU_PDE_READABLE | SMMU_PDE_WRITABLE | \
 SMMU_PDE_NONSECURE)
+#define SMMU_PTE_ATTR  (SMMU_PTE_READABLE | SMMU_PTE_WRITABLE | \
+SMMU_PTE_NONSECURE)
+#define SMMU_PTE_ATTR_SHIFT(29)
 
 static unsigned int iova_pd_index(unsigned long iova)
 {
@@ -163,6 +173,12 @@ static unsigned int iova_pt_index(unsigned long iova)
return (iova >> SMMU_PTE_SHIFT) & (SMMU_NUM_PTE - 1);
 }
 
+static unsigned long pd_pt_index_iova(unsigned int pd_index, unsigned int 
pt_index)
+{
+   return ((dma_addr_t)pd_index & (SMMU_NUM_PDE - 1)) << SMMU_PDE_SHIFT |
+  ((dma_addr_t)pt_index & (SMMU_NUM_PTE - 1)) << SMMU_PTE_SHIFT;
+}
+
 static bool smmu_dma_addr_valid(struct tegra_smmu *smmu, dma_addr_t addr)
 {
addr >>= 12;
@@ -334,7 +350,7 @@ static void tegra_smmu_domain_free(struct iommu_domain 
*domain)
 }
 
 static const struct tegra_smmu_swgroup *
-tegra_smmu_find_swgroup(struct tegra_smmu *smmu, unsigned int swgroup)
+tegra_smmu_find_swgroup(struct tegra_smmu *smmu, unsigned int swgroup, int 
*index)
 {
const struct tegra_smmu_swgroup *group = NULL;
unsigned int i;
@@ -342,6 +358,8 @@ tegra_smmu_find_swgroup(struct tegra_smmu *smmu, unsigned 
int swgroup)
for (i = 0; i < smmu->soc->num_swgroups; i++) {
if (smmu->soc->swgroups[i].swgroup == swgroup) {
group = &smmu->soc->swgroups[i];
+   if (index)
+   *index = i;
break;
}
}
@@ -350,19 +368,22 @@ tegra_smmu_find_swgroup(struct tegra_smmu *smmu, unsigned 
int swgroup)
 }
 
 static void tegra_smmu_enable(struct tegra_smmu *smmu, unsigned int swgroup,
- unsigned int asid)
+ struct tegra_smmu_as *as)
 {
const struct tegra_smmu_swgroup *group;
+   unsigned int asid = as->id;
unsigned int i;
u32 value;
 
-   group = tegra_smmu_find_swgroup(smmu, swgroup);
+   group = tegra_smmu_find_swgroup(smmu, swgroup, &i);
if (group) {
value = smmu_readl(smmu, group->reg);
value &= ~SMMU_ASID_MASK;
value |= SMMU_ASID_VALUE(asid);
value |= SMMU_ASID_ENABLE;
smmu_writel(smmu, value, group->reg);
+   if (smmu->group_debug)
+   smmu->group_debug[i].priv = as;
} else {
pr_warn("%s group from swgroup %u not found\n", __func__,
swgroup);
@@ -389,13 +410,15 @@ static void tegra_smmu_disable(struct tegra_smmu *smmu, 
unsigned int swgroup,
unsigned int i;
u32 value;
 
-   group = tegra_smmu_find_swgroup(smmu, swgroup);
+   group = tegra_smmu_find_swgroup(smmu, swgroup, &i);
if (group) {
value = smmu_readl(smmu, group->reg);
value &= ~SMMU_ASID_MASK;
value |= SMMU_ASID_VALUE(asid);
value &= ~SMMU_ASID_ENA

Re: [PATCH][next] bus: mhi: core: remove redundant initialization of variables state and ee

[Loic Poulain]

On Thu, 11 Mar 2021 at 12:18, Colin King  wrote:
>
> From: Colin Ian King 
>
> The variables state and ee are being initialized with values that
> are never read and are being updated later with a new values. The
> initializations are redundant and can be removed.
>
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King 

Reviewed-by: Loic Poulain 

> ---
>  drivers/bus/mhi/core/main.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index 2c61dfd01353..3faf8bade520 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -428,9 +428,9 @@ irqreturn_t mhi_intvec_threaded_handler(int irq_number, 
> void *priv)
>  {
> struct mhi_controller *mhi_cntrl = priv;
> struct device *dev = &mhi_cntrl->mhi_dev->dev;
> -   enum mhi_state state = MHI_STATE_MAX;
> +   enum mhi_state state;
> enum mhi_pm_state pm_state = 0;
> -   enum mhi_ee_type ee = MHI_EE_MAX;
> +   enum mhi_ee_type ee;
>
> write_lock_irq(&mhi_cntrl->pm_lock);
> if (!MHI_REG_ACCESS_VALID(mhi_cntrl->pm_state)) {
> --
> 2.30.2
>

[BUG] net: rds: rds_send_probe memory leak

[Fatih Yildirim]

Hi Santosh,

I've been working on a memory leak bug reported by syzbot.
https://syzkaller.appspot.com/bug?id=39b72114839a6dbd66c1d2104522698a813f9ae2

It seems that memory allocated in rds_send_probe function is not freed.

Let me share my observations.
rds_message is allocated at the beginning of rds_send_probe function.
Then it is added to cp_send_queue list of rds_conn_path and refcount
is increased by one.
Next, in rds_send_xmit function it is moved from cp_send_queue list to
cp_retrans list, and again refcount is increased by one.
Finally in rds_loop_xmit function refcount is increased by one.
So, total refcount is 4.
However, rds_message_put is called three times, in rds_send_probe,
rds_send_remove_from_sock and rds_send_xmit functions. It seems that
one more rds_message_put is needed.
Would you please check and share your comments on this issue?

Thanks,
Fatih

Re: [PATCH] virtio-mmio: read[wl]()/write[wl] are already little-endian

[Michael S. Tsirkin]

On Sat, Mar 13, 2021 at 06:10:29PM +0100, Laurent Vivier wrote:
> Le 11/03/2021 à 16:44, Michael S. Tsirkin a écrit :
> > On Tue, Mar 09, 2021 at 11:43:13PM +0100, Laurent Vivier wrote:
> >> read[wl]()/write[wl] already access memory in little-endian mode.
> > 
> > But then they convert it to CPU right? We just convert it back ...
> 
> In fact the problem is in QEMU.
> 
> On a big-endian guest, the readw() returns a byte-swapped value, This means 
> QEMU doesn't provide a
> little-endian value.
> 
> I found in QEMU virtio_mmio_read() provides a value with byte-swapped bytes.
> 
> The problem comes from virtio_config_readX() functions that read the value 
> using ldX_p accessors.
> 
> Is it normal not to use the modern variant here if we are not in legacy mode?
> 
> I think we should have something like this in virtio_mmio_read (and write):
> 
> --- a/hw/virtio/virtio-mmio.c
> +++ b/hw/virtio/virtio-mmio.c
> @@ -112,15 +112,28 @@ static uint64_t virtio_mmio_read(void *opaque, hwaddr 
> offset, unsigned size)
> 
>  if (offset >= VIRTIO_MMIO_CONFIG) {
>  offset -= VIRTIO_MMIO_CONFIG;
> -switch (size) {
> -case 1:
> -return virtio_config_readb(vdev, offset);
> -case 2:
> -return virtio_config_readw(vdev, offset);
> -case 4:
> -return virtio_config_readl(vdev, offset);
> -default:
> -abort();
> +if (proxy->legacy) {
> +switch (size) {
> +case 1:
> +return virtio_config_readb(vdev, offset);
> +case 2:
> +return virtio_config_readw(vdev, offset);
> +case 4:
> +return virtio_config_readl(vdev, offset);
> +default:
> +abort();
> +}
> +} else {
> +switch (size) {
> +case 1:
> +return virtio_config_modern_readb(vdev, offset);
> +case 2:
> +return virtio_config_modern_readw(vdev, offset);
> +case 4:
> +return virtio_config_modern_readl(vdev, offset);
> +default:
> +abort();
> +}
>  }
>  }
>  if (size != 4) {

Sounds reasonable ...


> And we need the same thing in virtio_pci_config_read() (and write).

We already have it, see below.

> And this could explain why it works with virtio-pci and not with virtio-mmio 
> with the big-endian guest:
> 
> with virtio-pci the bytes are swapped twice (once in virtio-mmio and then in 
> virtio-pci), so they
> are restored to the initial value, whereas with direct virtio-mmio they are 
> swapped only once.
> 
> Thanks,
> Laurent

virtio pci does this: modern accesses use:

virtio_pci_device_read

static uint64_t virtio_pci_device_read(void *opaque, hwaddr addr,
   unsigned size)
{
VirtIOPCIProxy *proxy = opaque;
VirtIODevice *vdev = virtio_bus_get_device(&proxy->bus);
uint64_t val = 0;

if (vdev == NULL) {
return val;
}

switch (size) {
case 1:
val = virtio_config_modern_readb(vdev, addr);
break;
case 2:
val = virtio_config_modern_readw(vdev, addr);
break;
case 4:
val = virtio_config_modern_readl(vdev, addr);
break;
}
return val;
}


while legacy accesses use:

virtio_pci_config_read

static uint64_t virtio_pci_config_read(void *opaque, hwaddr addr,
   unsigned size)
{
VirtIOPCIProxy *proxy = opaque;
VirtIODevice *vdev = virtio_bus_get_device(&proxy->bus);
uint32_t config = VIRTIO_PCI_CONFIG_SIZE(&proxy->pci_dev);
uint64_t val = 0;
if (addr < config) {
return virtio_ioport_read(proxy, addr);
}
addr -= config;

switch (size) {
case 1:
val = virtio_config_readb(vdev, addr);
break;
case 2:
val = virtio_config_readw(vdev, addr);
if (virtio_is_big_endian(vdev)) {
val = bswap16(val);
}
break;
case 4:
val = virtio_config_readl(vdev, addr);
if (virtio_is_big_endian(vdev)) {
val = bswap32(val);
}
break;
}
return val;
}


the naming is configing but there you are.

virtio_pci_config_read is also calling virtio_is_big_endian.


static inline bool virtio_is_big_endian(VirtIODevice *vdev)
{   
if (!virtio_vdev_has_feature(vdev, VIRTIO_F_VERSION_1)) {
assert(vdev->device_endian != VIRTIO_DEVICE_ENDIAN_UNKNOWN);
return vdev->device_endian == VIRTIO_DEVICE_ENDIAN_BIG;
}   
/* Devices conforming to VIRTIO 1.0 or later are always LE. */
return false;
}   


I note that
virtio_is_big_endian is kind of wrong for modern config accesses since it
checks guest feature bits - config accesses are done before features are
acknowledged.
Luckily this function is never called for a modern guest ...
It would be 

Re: [PATCH 05/23] ASoC: cx2070x: remove useless assignment

[Takashi Iwai]

On Fri, 12 Mar 2021 19:22:28 +0100,
Pierre-Louis Bossart wrote:
> 
> Cppcheck warning:
> 
> sound/soc/codecs/cx2072x.c:830:26: style: Variable
> 'reg1.r.rx_data_one_line' is reassigned a value before the old one has
> been used. [redundantAssignment]
> 
>  reg1.r.rx_data_one_line = 1;
>  ^
> 
> sound/soc/codecs/cx2072x.c:782:26: note: reg1.r.rx_data_one_line is
> assigned
>  reg1.r.rx_data_one_line = 1;
>  ^
> 
> sound/soc/codecs/cx2072x.c:830:26: note: reg1.r.rx_data_one_line is
> overwritten
>  reg1.r.rx_data_one_line = 1;
>  ^
> 
> sound/soc/codecs/cx2072x.c:831:26: style: Variable
> 'reg1.r.tx_data_one_line' is reassigned a value before the old one has
> been used. [redundantAssignment]
>  reg1.r.tx_data_one_line = 1;
>  ^
> sound/soc/codecs/cx2072x.c:783:26: note: reg1.r.tx_data_one_line is
> assigned
>  reg1.r.tx_data_one_line = 1;
>  ^
> 
> sound/soc/codecs/cx2072x.c:831:26: note: reg1.r.tx_data_one_line is
> overwritten
>  reg1.r.tx_data_one_line = 1;
>  ^
> 
> Likely copy/paste.
> 
> Signed-off-by: Pierre-Louis Bossart 

Reviewed-by: Takashi Iwai 


thanks,

Takashi


> ---
>  sound/soc/codecs/cx2072x.c | 3 ---
>  1 file changed, 3 deletions(-)
> 
> diff --git a/sound/soc/codecs/cx2072x.c b/sound/soc/codecs/cx2072x.c
> index 8ab22815c2c9..d2d004654c9b 100644
> --- a/sound/soc/codecs/cx2072x.c
> +++ b/sound/soc/codecs/cx2072x.c
> @@ -827,9 +827,6 @@ static int cx2072x_config_i2spcm(struct cx2072x_priv 
> *cx2072x)
>   }
>   regdbt2.r.i2s_bclk_invert = is_bclk_inv;
>  
> - reg1.r.rx_data_one_line = 1;
> - reg1.r.tx_data_one_line = 1;
> -
>   /* Configures the BCLK output */
>   bclk_rate = cx2072x->sample_rate * frame_len;
>   reg5.r.i2s_pcm_clk_div_chan_en = 0;
> -- 
> 2.25.1
> 

Re: [PATCH 05/23] ASoC: cx2070x: remove useless assignment

[Takashi Iwai]

On Fri, 12 Mar 2021 19:22:28 +0100,
Pierre-Louis Bossart wrote:
> 
> Cppcheck warning:
> 
> sound/soc/codecs/cx2072x.c:830:26: style: Variable
> 'reg1.r.rx_data_one_line' is reassigned a value before the old one has
> been used. [redundantAssignment]
> 
>  reg1.r.rx_data_one_line = 1;
>  ^
> 
> sound/soc/codecs/cx2072x.c:782:26: note: reg1.r.rx_data_one_line is
> assigned
>  reg1.r.rx_data_one_line = 1;
>  ^
> 
> sound/soc/codecs/cx2072x.c:830:26: note: reg1.r.rx_data_one_line is
> overwritten
>  reg1.r.rx_data_one_line = 1;
>  ^
> 
> sound/soc/codecs/cx2072x.c:831:26: style: Variable
> 'reg1.r.tx_data_one_line' is reassigned a value before the old one has
> been used. [redundantAssignment]
>  reg1.r.tx_data_one_line = 1;
>  ^
> sound/soc/codecs/cx2072x.c:783:26: note: reg1.r.tx_data_one_line is
> assigned
>  reg1.r.tx_data_one_line = 1;
>  ^
> 
> sound/soc/codecs/cx2072x.c:831:26: note: reg1.r.tx_data_one_line is
> overwritten
>  reg1.r.tx_data_one_line = 1;
>  ^
> 
> Likely copy/paste.
> 
> Signed-off-by: Pierre-Louis Bossart 

Reviewed-by: Takashi Iwai 


thanks,

Takashi

Re: [PATCH 06/23] ASoC: cx2070x: remove duplicate else branch

[Takashi Iwai]

On Fri, 12 Mar 2021 19:22:29 +0100,
Pierre-Louis Bossart wrote:
> 
> cppcheck warning:
> 
> sound/soc/codecs/cx2072x.c:1436:10: style:inconclusive: Found
> duplicate branches for 'if' and 'else'. [duplicateBranch]
>   } else if (type & 0x4) {
>  ^
> sound/soc/codecs/cx2072x.c:1439:5: note: Found duplicate branches for
> 'if' and 'else'.
>   } else {
> ^
> sound/soc/codecs/cx2072x.c:1436:10: note: Found duplicate branches for
> 'if' and 'else'.
>   } else if (type & 0x4) {
>  ^
> 
> The last two branches do the same thing and can be collapsed together.
> 
> Signed-off-by: Pierre-Louis Bossart 

Reviewed-by: Takashi Iwai 


thanks,

Takashi

Re: [PATCH] staging: octeon-usb: fixed precedence issue

[Greg KH]

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top

On Sun, Mar 14, 2021 at 01:34:23PM +0530, Selvakumar E wrote:
> Hi Greg
> I changed the line because of the checkpatch.pl warned for
> precedence issue.

But I fail to see how this:

> > > +#define CVMX_USBCXREG1((reg), bid) \

Does anything here at all.

What am I missing?

thanks,

greg k-h

Re: [BUG] net: rds: rds_send_probe memory leak

[Greg KH]

On Sun, Mar 14, 2021 at 11:23:10AM +0300, Fatih Yildirim wrote:
> Hi Santosh,
> 
> I've been working on a memory leak bug reported by syzbot.
> https://syzkaller.appspot.com/bug?id=39b72114839a6dbd66c1d2104522698a813f9ae2
> 
> It seems that memory allocated in rds_send_probe function is not freed.
> 
> Let me share my observations.
> rds_message is allocated at the beginning of rds_send_probe function.
> Then it is added to cp_send_queue list of rds_conn_path and refcount
> is increased by one.
> Next, in rds_send_xmit function it is moved from cp_send_queue list to
> cp_retrans list, and again refcount is increased by one.
> Finally in rds_loop_xmit function refcount is increased by one.
> So, total refcount is 4.
> However, rds_message_put is called three times, in rds_send_probe,
> rds_send_remove_from_sock and rds_send_xmit functions. It seems that
> one more rds_message_put is needed.
> Would you please check and share your comments on this issue?

Do you have a proposed patch that syzbot can test to verify if this is
correct or not?

thanks,

gre gk-h

Re: [PATCH v1 0/4] ALSA: hda/cirrus: Make CS8409 driver more generic by using fixups

[Takashi Iwai]

On Sat, 13 Mar 2021 12:34:06 +0100,
Vitaly Rodionov wrote:
> 
> This series of patches will address comments by Pierre-Louis Bossart,
> cleans up patch_cirrus.c source, reducing checkpatch.pl warnings from 19 to 0,
> fixing an issue reported by Canonical: BugLink: 
> https://bugs.launchpad.net/bugs/1918378,
> and makes the CS8409 patch more generic by using fixups.
> 
> Stefan Binding (4):
>   ALSA: hda/cirrus: Add error handling into CS8409 I2C functions
>   ALSA: hda/cirrus: Cleanup patch_cirrus.c code.
>   ALSA: hda/cirrus: Fix CS42L42 Headset Mic volume control name
>   ALSA: hda/cirrus: Make CS8409 driver more generic by using fixups.

Is this the same content as the series you've already submitted in
20210312184452.3288-1-vita...@opensource.cirrus.com ?


thanks,

Takashi

[PATCH v6 0/3] mm, vsprintf: dump full information of page flags in pGp

[Yafang Shao]

The existed pGp shows the names of page flags only, rather than the full
information including section, node, zone, last cpuipid and kasan tag.
While it is not easy to parse these information manually because there
are so many flavors. We'd better interpret them in printf.

To be compitable with the existed format of pGp, the new introduced ones
also use '|' as the separator, then the user tools parsing pGp won't
need to make change, suggested by Matthew. The new added information is
tracked onto the end of the existed one, e.g.
[ 8838.835456] Slab 0x2828b78a objects=33 used=3 fp=0xd04efc88 
flags=0x17c0010200(slab|head|node=0|zone=2|lastcpupid=0x1f)

The documentation and test cases are also updated. The result of the
test cases as follows,
[68599.816764] test_printf: loaded.
[68599.819068] test_printf: all 388 tests passed
[68599.830367] test_printf: unloaded.

This patchset also includes some code cleanup in mm/slub.c.

v6:
- fixes the build failure and test failure reported by kernel test robot

v5:
- remove the bitmap and better name the struct, per Petr

v4:
- extend %pGp instead of introducing new format, per Matthew

v3:
- coding improvement, per Joe and Andy
- the possible impact on debugfs and the fix of it, per Joe and Matthew
- introduce new format instead of changing pGp, per Andy

v2:
- various coding improvement, per Joe, Miaohe, Vlastimil and Andy
- remove the prefix completely in patch #2, per Vlastimil
- Update the test cases, per Andy

Yafang Shao (3):
  mm, slub: use pGp to print page flags
  mm, slub: don't combine pr_err with INFO
  vsprintf: dump full information of page flags in pGp

 Documentation/core-api/printk-formats.rst |  2 +-
 lib/test_printf.c | 90 ---
 lib/vsprintf.c| 66 +++--
 mm/slub.c | 13 ++--
 4 files changed, 149 insertions(+), 22 deletions(-)

-- 
2.18.2

[PATCH v6 1/3] mm, slub: use pGp to print page flags

[Yafang Shao]

As pGp has been already introduced in printk, we'd better use it to make
the output human readable.

Before this change, the output is,
[ 6155.716018] INFO: Slab 0x4027dd4f objects=33 used=3 
fp=0x8cd1579c flags=0x17c0010200

While after this change, the output is,
[ 8846.517809] INFO: Slab 0xf42a2c60 objects=33 used=3 
fp=0x60d32ca8 flags=0x17c0010200(slab|head)

Signed-off-by: Yafang Shao 
Reviewed-by: David Hildenbrand 
Reviewed-by: Vlastimil Babka 
Acked-by: David Rientjes 
Acked-by: Christoph Lameter 
Reviewed-by: Matthew Wilcox (Oracle) 
Reviewed-by: Miaohe Lin 
Reviewed-by: Andy Shevchenko 
---
 mm/slub.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index 3021ce9bf1b3..ed3f728c1367 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -650,8 +650,9 @@ void print_tracking(struct kmem_cache *s, void *object)
 
 static void print_page_info(struct page *page)
 {
-   pr_err("INFO: Slab 0x%p objects=%u used=%u fp=0x%p flags=0x%04lx\n",
-  page, page->objects, page->inuse, page->freelist, page->flags);
+   pr_err("INFO: Slab 0x%p objects=%u used=%u fp=0x%p flags=%#lx(%pGp)\n",
+  page, page->objects, page->inuse, page->freelist,
+  page->flags, &page->flags);
 
 }
 
-- 
2.18.2

[PATCH v6 3/3] vsprintf: dump full information of page flags in pGp

[Yafang Shao]

Currently the pGp only shows the names of page flags, rather than
the full information including section, node, zone, last cpupid and
kasan tag. While it is not easy to parse these information manually
because there're so many flavors. Let's interpret them in pGp as well.

To be compitable with the existed format of pGp, the new introduced ones
also use '|' as the separator, then the user tools parsing pGp won't
need to make change, suggested by Matthew. The new information is
tracked onto the end of the existed one.

On example of the output in mm/slub.c as follows,
- Before the patch,
[ 6343.396602] Slab 0x4382e02b objects=33 used=3 fp=0x9ae06ffc 
flags=0x17c0010200(slab|head)

- After the patch,
[ 8448.272530] Slab 0x90797883 objects=33 used=3 fp=0x790f1c26 
flags=0x17c0010200(slab|head|node=0|zone=2|lastcpupid=0x1f)

The documentation and test cases are also updated. The output of the
test cases as follows,
[68599.816764] test_printf: loaded.
[68599.819068] test_printf: all 388 tests passed
[68599.830367] test_printf: unloaded.

[l...@intel.com: reported issues in the prev version in test_printf.c]

Signed-off-by: Yafang Shao 
Cc: David Hildenbrand 
Cc: Joe Perches 
Cc: Miaohe Lin 
Cc: Vlastimil Babka 
Cc: Andy Shevchenko 
Cc: Matthew Wilcox 
Cc: Petr Mladek 
Cc: kernel test robot 
---
 Documentation/core-api/printk-formats.rst |  2 +-
 lib/test_printf.c | 90 ---
 lib/vsprintf.c| 66 +++--
 3 files changed, 142 insertions(+), 16 deletions(-)

diff --git a/Documentation/core-api/printk-formats.rst 
b/Documentation/core-api/printk-formats.rst
index 160e710d992f..00d07c7eefd4 100644
--- a/Documentation/core-api/printk-formats.rst
+++ b/Documentation/core-api/printk-formats.rst
@@ -540,7 +540,7 @@ Flags bitfields such as page flags, gfp_flags
 
 ::
 
-   %pGpreferenced|uptodate|lru|active|private
+   %pGp
referenced|uptodate|lru|active|private|node=0|zone=2|lastcpupid=0x1f
%pGgGFP_USER|GFP_DMA32|GFP_NOWARN
%pGvread|exec|mayread|maywrite|mayexec|denywrite
 
diff --git a/lib/test_printf.c b/lib/test_printf.c
index 95a2f82427c7..f87e433d6fa9 100644
--- a/lib/test_printf.c
+++ b/lib/test_printf.c
@@ -577,24 +577,98 @@ netdev_features(void)
 {
 }
 
+struct page_flags_test {
+   int width;
+   int shift;
+   int mask;
+   unsigned long value;
+   const char *fmt;
+   const char *name;
+};
+
+static struct page_flags_test pft[] = {
+   {SECTIONS_WIDTH, SECTIONS_PGSHIFT, SECTIONS_MASK,
+0, "%d", "section"},
+   {NODES_WIDTH, NODES_PGSHIFT, NODES_MASK,
+0, "%d", "node"},
+   {ZONES_WIDTH, ZONES_PGSHIFT, ZONES_MASK,
+0, "%d", "zone"},
+   {LAST_CPUPID_WIDTH, LAST_CPUPID_PGSHIFT, LAST_CPUPID_MASK,
+0, "%#x", "lastcpupid"},
+   {KASAN_TAG_WIDTH, KASAN_TAG_PGSHIFT, KASAN_TAG_MASK,
+0, "%#x", "kasantag"},
+};
+
+static void __init
+page_flags_test(int section, int node, int zone, int last_cpupid,
+   int kasan_tag, int flags, const char *name, char *cmp_buf)
+{
+   unsigned long values[] = {section, node, zone, last_cpupid, kasan_tag};
+   unsigned long page_flags = 0;
+   unsigned long size = 0;
+   bool append = false;
+   int i;
+
+   flags &= BIT(NR_PAGEFLAGS) - 1;
+   if (flags) {
+   page_flags |= flags;
+   snprintf(cmp_buf + size, BUF_SIZE - size, "%s", name);
+   size = strlen(cmp_buf);
+#if SECTIONS_WIDTH || NODES_WIDTH || ZONES_WIDTH || \
+   LAST_CPUPID_WIDTH || KASAN_TAG_WIDTH
+   /* Other information also included in page flags */
+   snprintf(cmp_buf + size, BUF_SIZE - size, "|");
+   size = strlen(cmp_buf);
+#endif
+   }
+
+   /* Set the test value */
+   for (i = 0; i < ARRAY_SIZE(pft); i++)
+   pft[i].value = values[i];
+
+   for (i = 0; i < ARRAY_SIZE(pft); i++) {
+   if (!pft[i].width)
+   continue;
+
+   if (append) {
+   snprintf(cmp_buf + size, BUF_SIZE - size, "|");
+   size = strlen(cmp_buf);
+   }
+
+   page_flags |= (pft[i].value & pft[i].mask) << pft[i].shift;
+   snprintf(cmp_buf + size, BUF_SIZE - size, "%s=", pft[i].name);
+   size = strlen(cmp_buf);
+   snprintf(cmp_buf + size, BUF_SIZE - size, pft[i].fmt,
+pft[i].value & pft[i].mask);
+   size = strlen(cmp_buf);
+   append = true;
+   }
+
+   test(cmp_buf, "%pGp", &page_flags);
+}
+
 static void __init
 flags(void)
 {
unsigned long flags;
-   gfp_t gfp;
char *cmp_buffer;
+   gfp_t gfp;
+
+   cmp_buffer = kmalloc(BUF_SIZE, GFP_KERNEL);
+   if (!cmp_buffer)
+   return;
 
flags = 0;
-   test("", "%pGp", &flags);
+   p

[PATCH v6 2/3] mm, slub: don't combine pr_err with INFO

[Yafang Shao]

It is strange to combine "pr_err" with "INFO", so let's remove the
prefix completely.
This patch is motivated by David's comment[1].

- before the patch
[ 8846.517809] INFO: Slab 0xf42a2c60 objects=33 used=3 
fp=0x60d32ca8 flags=0x17c0010200(slab|head)

- after the patch
[ 6343.396602] Slab 0x4382e02b objects=33 used=3 fp=0x9ae06ffc 
flags=0x17c0010200(slab|head)

[1]. 
https://lore.kernel.org/linux-mm/b9c0f2b6-e9b0-0c36-ebdd-2bc684c5a...@redhat.com/#t

Suggested-by: Vlastimil Babka 
Signed-off-by: Yafang Shao 
Acked-by: Vlastimil Babka 
Reviewed-by: Miaohe Lin 
Reviewed-by: Andy Shevchenko 
Reviewed-by: David Hildenbrand 
Cc: Matthew Wilcox 
---
 mm/slub.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index ed3f728c1367..7ed388077633 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -624,7 +624,7 @@ static void print_track(const char *s, struct track *t, 
unsigned long pr_time)
if (!t->addr)
return;
 
-   pr_err("INFO: %s in %pS age=%lu cpu=%u pid=%d\n",
+   pr_err("%s in %pS age=%lu cpu=%u pid=%d\n",
   s, (void *)t->addr, pr_time - t->when, t->cpu, t->pid);
 #ifdef CONFIG_STACKTRACE
{
@@ -650,7 +650,7 @@ void print_tracking(struct kmem_cache *s, void *object)
 
 static void print_page_info(struct page *page)
 {
-   pr_err("INFO: Slab 0x%p objects=%u used=%u fp=0x%p flags=%#lx(%pGp)\n",
+   pr_err("Slab 0x%p objects=%u used=%u fp=0x%p flags=%#lx(%pGp)\n",
   page, page->objects, page->inuse, page->freelist,
   page->flags, &page->flags);
 
@@ -707,7 +707,7 @@ static void print_trailer(struct kmem_cache *s, struct page 
*page, u8 *p)
 
print_page_info(page);
 
-   pr_err("INFO: Object 0x%p @offset=%tu fp=0x%p\n\n",
+   pr_err("Object 0x%p @offset=%tu fp=0x%p\n\n",
   p, p - addr, get_freepointer(s, p));
 
if (s->flags & SLAB_RED_ZONE)
@@ -800,7 +800,7 @@ static int check_bytes_and_report(struct kmem_cache *s, 
struct page *page,
end--;
 
slab_bug(s, "%s overwritten", what);
-   pr_err("INFO: 0x%p-0x%p @offset=%tu. First byte 0x%x instead of 0x%x\n",
+   pr_err("0x%p-0x%p @offset=%tu. First byte 0x%x instead of 0x%x\n",
fault, end - 1, fault - addr,
fault[0], value);
print_trailer(s, page, object);
@@ -3899,7 +3899,7 @@ static void list_slab_objects(struct kmem_cache *s, 
struct page *page,
for_each_object(p, s, addr, page->objects) {
 
if (!test_bit(__obj_to_index(s, addr, p), map)) {
-   pr_err("INFO: Object 0x%p @offset=%tu\n", p, p - addr);
+   pr_err("Object 0x%p @offset=%tu\n", p, p - addr);
print_tracking(s, p);
}
}
-- 
2.18.2

[GIT PULL] KVM fixes for 5.12-rc3

[Paolo Bonzini]

Linus,

The following changes since commit 9e46f6c6c959d9bb45445c2e8f04a75324a0dfd0:

  KVM: SVM: Clear the CR4 register on reset (2021-03-02 14:39:11 -0500)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

for you to fetch changes up to 35737d2db2f4567106c90060ad110b27cb354fa4:

  KVM: LAPIC: Advancing the timer expiration on guest initiated write 
(2021-03-12 13:18:52 -0500)


More fixes for ARM and x86.


Andrew Scull (1):
  KVM: arm64: Fix nVHE hyp panic host context restore

Jia He (1):
  KVM: arm64: Fix range alignment when walking page tables

Marc Zyngier (7):
  KVM: arm64: Turn kvm_arm_support_pmu_v3() into a static key
  KVM: arm64: Don't access PMSELR_EL0/PMUSERENR_EL0 when no PMU is available
  KVM: arm64: Rename __vgic_v3_get_ich_vtr_el2() to 
__vgic_v3_get_gic_config()
  KVM: arm64: Workaround firmware wrongly advertising GICv2-on-v3 
compatibility
  KVM: arm64: Ensure I-cache isolation between vcpus of a same VM
  KVM: arm64: Reject VM creation when the default IPA size is unsupported
  KVM: arm64: Fix exclusive limit for IPA size

Muhammad Usama Anjum (2):
  kvm: x86: use NULL instead of using plain integer as pointer
  kvm: x86: annotate RCU pointers

Sami Tolvanen (1):
  KVM: arm64: Don't use cbz/adr with external symbols

Sean Christopherson (3):
  KVM: x86: Ensure deadline timer has truly expired before posting its IRQ
  KVM: SVM: Connect 'npt' module param to KVM's internal 'npt_enabled'
  KVM: x86/mmu: Skip !MMU-present SPTEs when removing SP in exclusive mode

Suzuki K Poulose (1):
  KVM: arm64: nvhe: Save the SPE context early

Wanpeng Li (2):
  KVM: kvmclock: Fix vCPUs > 64 can't be online/hotpluged
  KVM: LAPIC: Advancing the timer expiration on guest initiated write

Will Deacon (1):
  KVM: arm64: Avoid corrupting vCPU context register in guest exit

 Documentation/virt/kvm/api.rst  |  3 +++
 arch/arm64/include/asm/kvm_asm.h|  8 +++
 arch/arm64/include/asm/kvm_hyp.h|  8 ++-
 arch/arm64/kernel/image-vars.h  |  3 +++
 arch/arm64/kvm/arm.c|  7 +-
 arch/arm64/kvm/hyp/entry.S  |  8 ---
 arch/arm64/kvm/hyp/include/hyp/switch.h |  9 +---
 arch/arm64/kvm/hyp/nvhe/debug-sr.c  | 12 --
 arch/arm64/kvm/hyp/nvhe/host.S  | 15 +++--
 arch/arm64/kvm/hyp/nvhe/hyp-main.c  | 12 +-
 arch/arm64/kvm/hyp/nvhe/switch.c| 14 +---
 arch/arm64/kvm/hyp/nvhe/tlb.c   |  3 ++-
 arch/arm64/kvm/hyp/pgtable.c|  1 +
 arch/arm64/kvm/hyp/vgic-v3-sr.c | 40 +++--
 arch/arm64/kvm/hyp/vhe/tlb.c|  3 ++-
 arch/arm64/kvm/mmu.c|  3 +--
 arch/arm64/kvm/perf.c   | 10 +
 arch/arm64/kvm/pmu-emul.c   | 10 -
 arch/arm64/kvm/reset.c  | 12 ++
 arch/arm64/kvm/vgic/vgic-v3.c   | 12 +++---
 arch/x86/include/asm/kvm_host.h |  4 ++--
 arch/x86/kernel/kvmclock.c  | 19 
 arch/x86/kvm/lapic.c| 12 +-
 arch/x86/kvm/mmu/tdp_mmu.c  | 11 +
 arch/x86/kvm/svm/svm.c  | 25 +++--
 arch/x86/kvm/x86.c  |  2 +-
 include/kvm/arm_pmu.h   |  9 ++--
 27 files changed, 194 insertions(+), 81 deletions(-)

Re: linux-next: Tree for Mar 10 (lib/test_printf.c)

[Yafang Shao]

On Wed, Mar 10, 2021 at 5:52 PM Petr Mladek  wrote:
>
> On Tue 2021-03-09 21:57:48, Randy Dunlap wrote:
> > On 3/9/21 8:02 PM, Stephen Rothwell wrote:
> > > Hi all,
> > >
> >
> > on i386 (at least):
> >
> > ../lib/test_printf.c: In function 'page_flags_test':
> > ../lib/test_printf.c:595:17: error: 'sec' undeclared (first use in this 
> > function); did you mean 'sem'?
> >   page_flags |= (sec & SECTIONS_MASK) << SECTIONS_PGSHIFT;
> >  ^~~
> >
> >
> > Should that be 'section'?
>
> Yup, it looks like.
>
> There seems to be one more problem found by the test robot:
>
>lib/test_printf.c:595:17: note: each undeclared identifier is reported 
> only once for each function it appears in
> >> lib/test_printf.c:612:17: error: 'tag' undeclared (first use in this 
> >> function)
>  612 |  page_flags |= (tag & KASAN_TAG_MASK) << KASAN_TAG_PGSHIFT;
>
>
> Yafang is going to send a fix. I have temporary removed the
> problematic patch from printk/linux.git, for-next branch.
>
> I am sorry for the troubles. Anyway, it is great that linux-next
> and all the test robots are around.
>

Hi Petr,

I sent a new version v6[1] to fix the test failure and build failure
report by kernel test robot.

Sorry for the late fix as I'm very busy recently.

[1]. 
https://lore.kernel.org/linux-mm/20210314083717.96380-1-laoar.s...@gmail.com/T/#t


-- 
Thanks
Yafang

[PATCH 4/4] staging:r8188eu: use ieee80211_is_ctl instead IsFrameTypeCtrl

[Ivan Safonov]

IsFrameTypeCtrl() duplicate ieee80211_is_ctl().

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c | 8 +---
 drivers/staging/rtl8188eu/include/wifi.h| 8 
 2 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c 
b/drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c
index 4fae75fc3dd5..8669bf097479 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c
@@ -133,6 +133,8 @@ void update_recvframe_phyinfo_88e(struct recv_frame 
*precvframe,
struct rx_pkt_attrib *pattrib = &precvframe->attrib;
struct odm_phy_status_info *pPHYInfo  = (struct odm_phy_status_info 
*)(&pattrib->phy_info);
u8 *wlanhdr;
+   struct ieee80211_hdr *hdr =
+   (struct ieee80211_hdr *)precvframe->pkt->data;
struct odm_per_pkt_info pkt_info;
u8 *sa = NULL;
struct sta_priv *pstapriv;
@@ -144,13 +146,13 @@ void update_recvframe_phyinfo_88e(struct recv_frame 
*precvframe,
 
wlanhdr = precvframe->pkt->data;
 
-   pkt_info.bPacketMatchBSSID = ((!IsFrameTypeCtrl(wlanhdr)) &&
+   pkt_info.bPacketMatchBSSID = (!ieee80211_is_ctl(hdr->frame_control) &&
!pattrib->icv_err && !pattrib->crc_err &&
!memcmp(get_hdr_bssid(wlanhdr),
 get_bssid(&padapter->mlmepriv), ETH_ALEN));
 
pkt_info.bPacketToSelf = pkt_info.bPacketMatchBSSID &&
-(!memcmp(ieee80211_get_DA((struct 
ieee80211_hdr *)wlanhdr),
+(!memcmp(ieee80211_get_DA(hdr),
  myid(&padapter->eeprompriv), ETH_ALEN));
 
pkt_info.bPacketBeacon = pkt_info.bPacketMatchBSSID &&
@@ -161,7 +163,7 @@ void update_recvframe_phyinfo_88e(struct recv_frame 
*precvframe,
sa = padapter->mlmepriv.cur_network.network.MacAddress;
/* to do Ad-hoc */
} else {
-   sa = ieee80211_get_SA((struct ieee80211_hdr *)wlanhdr);
+   sa = ieee80211_get_SA(hdr);
}
 
pstapriv = &padapter->stapriv;
diff --git a/drivers/staging/rtl8188eu/include/wifi.h 
b/drivers/staging/rtl8188eu/include/wifi.h
index d65a0a88a69a..84e17330628e 100644
--- a/drivers/staging/rtl8188eu/include/wifi.h
+++ b/drivers/staging/rtl8188eu/include/wifi.h
@@ -197,14 +197,6 @@ static inline unsigned char *get_hdr_bssid(unsigned char 
*pframe)
return sa;
 }
 
-static inline int IsFrameTypeCtrl(unsigned char *pframe)
-{
-   if (GetFrameType(pframe) == WIFI_CTRL_TYPE)
-   return true;
-   else
-   return false;
-}
-
 /*-
Below is for the security related definition
 
--*/
-- 
2.26.2

[PATCH 3/4] staging:r8188eu: replace cap_* definitions with native kernel WLAN_CAPABILITY_*

[Ivan Safonov]

cap_* definitions duplicate WLAN_CAPABILITY_*. Remove cap_* definitions,
improve code consistency.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_ieee80211.c |  6 +++---
 drivers/staging/rtl8188eu/core/rtw_mlme_ext.c  |  6 +++---
 drivers/staging/rtl8188eu/include/wifi.h   | 12 
 3 files changed, 6 insertions(+), 18 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c 
b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
index ec5b8be14c2b..7a706fe11750 100644
--- a/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
+++ b/drivers/staging/rtl8188eu/core/rtw_ieee80211.c
@@ -223,13 +223,13 @@ int rtw_generate_ie(struct registry_priv *pregistrypriv)
/* capability info */
*(u16 *)ie = 0;
 
-   *(__le16 *)ie |= cpu_to_le16(cap_IBSS);
+   *(__le16 *)ie |= cpu_to_le16(WLAN_CAPABILITY_IBSS);
 
if (pregistrypriv->preamble == PREAMBLE_SHORT)
-   *(__le16 *)ie |= cpu_to_le16(cap_ShortPremble);
+   *(__le16 *)ie |= cpu_to_le16(WLAN_CAPABILITY_SHORT_PREAMBLE);
 
if (pdev_network->Privacy)
-   *(__le16 *)ie |= cpu_to_le16(cap_Privacy);
+   *(__le16 *)ie |= cpu_to_le16(WLAN_CAPABILITY_PRIVACY);
 
sz += 2;
ie += 2;
diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index bee19d5b22c0..50d3c3631be0 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -2188,7 +2188,7 @@ static void start_create_ibss(struct adapter *padapter)
/* update capability */
caps = rtw_get_capability(pnetwork);
update_capinfo(padapter, caps);
-   if (caps & cap_IBSS) {/* adhoc master */
+   if (caps & WLAN_CAPABILITY_IBSS) {/* adhoc master */
val8 = 0xcf;
rtw_hal_set_hwreg(padapter, HW_VAR_SEC_CFG, (u8 *)(&val8));
 
@@ -2240,7 +2240,7 @@ static void start_clnt_join(struct adapter *padapter)
/* update capability */
caps = rtw_get_capability(pnetwork);
update_capinfo(padapter, caps);
-   if (caps & cap_ESS) {
+   if (caps & WLAN_CAPABILITY_ESS) {
Set_MSR(padapter, WIFI_FW_STATION_STATE);
 
val8 = (pmlmeinfo->auth_algo == dot11AuthAlgrthm_8021X) ? 0xcc 
: 0xcf;
@@ -2258,7 +2258,7 @@ static void start_clnt_join(struct adapter *padapter)
  msecs_to_jiffies((REAUTH_TO * REAUTH_LIMIT) + 
(REASSOC_TO * REASSOC_LIMIT) + beacon_timeout));
 
pmlmeinfo->state = WIFI_FW_AUTH_NULL | WIFI_FW_STATION_STATE;
-   } else if (caps & cap_IBSS) { /* adhoc client */
+   } else if (caps & WLAN_CAPABILITY_IBSS) { /* adhoc client */
Set_MSR(padapter, WIFI_FW_ADHOC_STATE);
 
val8 = 0xcf;
diff --git a/drivers/staging/rtl8188eu/include/wifi.h 
b/drivers/staging/rtl8188eu/include/wifi.h
index f03359602db7..d65a0a88a69a 100644
--- a/drivers/staging/rtl8188eu/include/wifi.h
+++ b/drivers/staging/rtl8188eu/include/wifi.h
@@ -238,18 +238,6 @@ static inline int IsFrameTypeCtrl(unsigned char *pframe)
 #define AUTH_ODD_TO0
 #define AUTH_EVEN_TO   1
 
-#define cap_ESSBIT(0)
-#define cap_IBSS   BIT(1)
-#define cap_CFPollable BIT(2)
-#define cap_CFRequest  BIT(3)
-#define cap_PrivacyBIT(4)
-#define cap_ShortPremble BIT(5)
-#define cap_PBCC   BIT(6)
-#define cap_ChAgility  BIT(7)
-#define cap_SpecMgmt   BIT(8)
-#define cap_QoSi   BIT(9)
-#define cap_ShortSlot  BIT(10)
-
 /*-
Below is the definition for 802.11i / 802.1x
 
--*/
-- 
2.26.2

[PATCH 2/4] staging:r8188eu: remove unused definitions from wifi.h

[Ivan Safonov]

These definitions are not used and will not be useful in the future.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/include/wifi.h | 92 
 1 file changed, 92 deletions(-)

diff --git a/drivers/staging/rtl8188eu/include/wifi.h 
b/drivers/staging/rtl8188eu/include/wifi.h
index 5ee4d02e293c..f03359602db7 100644
--- a/drivers/staging/rtl8188eu/include/wifi.h
+++ b/drivers/staging/rtl8188eu/include/wifi.h
@@ -7,21 +7,8 @@
 #ifndef _WIFI_H_
 #define _WIFI_H_
 
-#define WLAN_IEEE_OUI_LEN  3
-#define WLAN_CRC_LEN   4
-#define WLAN_BSSID_LEN 6
-#define WLAN_BSS_TS_LEN8
 #define WLAN_HDR_A3_LEN24
-#define WLAN_HDR_A4_LEN30
 #define WLAN_HDR_A3_QOS_LEN26
-#define WLAN_HDR_A4_QOS_LEN32
-#define WLAN_DATA_MAXLEN   2312
-
-#define WLAN_A3_PN_OFFSET  24
-#define WLAN_A4_PN_OFFSET  30
-
-#define WLAN_MIN_ETHFRM_LEN60
-#define WLAN_MAX_ETHFRM_LEN1514
 
 #define P80211CAPTURE_VERSION  0x80211001
 
@@ -74,20 +61,6 @@ enum WIFI_FRAME_SUBTYPE {
WIFI_QOS_DATA_NULL  = (BIT(6) | WIFI_QOS_DATA_TYPE),
 };
 
-enum WIFI_REG_DOMAIN {
-   DOMAIN_FCC  = 1,
-   DOMAIN_IC   = 2,
-   DOMAIN_ETSI = 3,
-   DOMAIN_SPA  = 4,
-   DOMAIN_FRANCE   = 5,
-   DOMAIN_MKK  = 6,
-   DOMAIN_ISRAEL   = 7,
-   DOMAIN_MKK1 = 8,
-   DOMAIN_MKK2 = 9,
-   DOMAIN_MKK3 = 10,
-   DOMAIN_MAX
-};
-
 #define SetToDs(pbuf)  \
*(__le16 *)(pbuf) |= cpu_to_le16(IEEE80211_FCTL_TODS)
 
@@ -199,8 +172,6 @@ enum WIFI_REG_DOMAIN {
 
 #define GetAddr3Ptr(pbuf)  ((unsigned char *)((size_t)(pbuf) + 16))
 
-#define GetAddr4Ptr(pbuf)  ((unsigned char *)((size_t)(pbuf) + 24))
-
 static inline unsigned char *get_hdr_bssid(unsigned char *pframe)
 {
unsigned char   *sa;
@@ -237,19 +208,6 @@ static inline int IsFrameTypeCtrl(unsigned char *pframe)
 /*-
Below is for the security related definition
 
--*/
-#define _RESERVED_FRAME_TYPE_  0
-#define _SKB_FRAME_TYPE_   2
-#define _PRE_ALLOCMEM_ 1
-#define _PRE_ALLOCHDR_ 3
-#define _PRE_ALLOCLLCHDR_  4
-#define _PRE_ALLOCICVHDR_  5
-#define _PRE_ALLOCMICHDR_  6
-
-#define _SIFSTIME_ \
-   ((priv->pmib->dot11BssType.net_work_type & WIRELESS_11A) ? 16 : 10)
-#define _ACKCTSLNG_14  /* 14 bytes long, including crclng */
-#define _CRCLNG_   4
-
 #define _ASOCREQ_IE_OFFSET_4   /*  excluding wlan_hdr */
 #define_ASOCRSP_IE_OFFSET_ 6
 #define _REASOCREQ_IE_OFFSET_  10
@@ -280,10 +238,6 @@ static inline int IsFrameTypeCtrl(unsigned char *pframe)
 #define AUTH_ODD_TO0
 #define AUTH_EVEN_TO   1
 
-#define WLAN_ETHCONV_ENCAP 1
-#define WLAN_ETHCONV_RFC1042   2
-#define WLAN_ETHCONV_8021h 3
-
 #define cap_ESSBIT(0)
 #define cap_IBSS   BIT(1)
 #define cap_CFPollable BIT(2)
@@ -316,7 +270,6 @@ static inline int IsFrameTypeCtrl(unsigned char *pframe)
Below is the definition for WMM
 
--*/
 #define _WMM_IE_Length_7  /*  for WMM STA */
-#define _WMM_Para_Element_Length_  24
 
 /*-
Below is the definition for 802.11n
@@ -388,13 +341,6 @@ enum ht_cap_ampdu_factor {
 #define HT_INFO_OPERATION_MODE_TRANSMIT_BURST_LIMIT((u8)BIT(3))
 #define HT_INFO_OPERATION_MODE_NON_HT_STA_PRESENT  ((u8)BIT(4))
 
-#define HT_INFO_STBC_PARAM_DUAL_BEACON ((u16)BIT(6))
-#define HT_INFO_STBC_PARAM_DUAL_STBC_PROTECT   ((u16)BIT(7))
-#define HT_INFO_STBC_PARAM_SECONDARY_BC((u16)BIT(8))
-#define HT_INFO_STBC_PARAM_LSIG_TXOP_PROTECT_ALLOWED   ((u16)BIT(9))
-#define HT_INFO_STBC_PARAM_PCO_ACTIVE  ((u16)BIT(10))
-#define HT_INFO_STBC_PARAM_PCO_PHASE   ((u16)BIT(11))
-
 /* ===WPS Section=== */
 /* For WPSv1.0 */
 #define WPSOUI 0x0050f204
@@ -453,48 +399,10 @@ enum ht_cap_ampdu_factor {
 #define WPS_CONFIG_METHOD_VDISPLAY 0x2008
 #define WPS_CONFIG_METHOD_PDISPLAY 0x4008
 
-/* Value of Category ID of WPS Primary Device Type Attribute */
-#define WPS_PDT_CID_DISPLAYS   0x0007
-#define WPS_PDT_CID_MULIT_MEDIA0x0008
-#define WPS_PDT_CID_RTK_WIDI   WPS_PDT_CID_MULIT_MEDIA
-
-/* Value of Sub Category ID of WPS Primary Device Type Attribute */
-#define WPS_PDT_SCID_MEDIA_SERVER  0x0005
-#define WPS_PDT_SCID_RTK_DMP   WPS_PDT_SCID_MEDIA_SERVER
-
-

[PATCH 0/4] staging:r8188eu: remove unnecessary definitions from wifi.h

[Ivan Safonov]

wifi.h contains unnecessary definitions. Some of them are not used
at all, some can be replaced with native definitions.

Ivan Safonov (4):
  staging:r8188eu: replace get_(d|s)a with ieee80211_get_(D|S)A
  staging:r8188eu: remove unused definitions from wifi.h
  staging:r8188eu: replace cap_* definitions with native kernel
WLAN_CAPABILITY_*
  staging:r8188eu: use ieee80211_is_ctl instead IsFrameTypeCtrl

 .../staging/rtl8188eu/core/rtw_ieee80211.c|   6 +-
 drivers/staging/rtl8188eu/core/rtw_mlme_ext.c |  12 +-
 drivers/staging/rtl8188eu/core/rtw_recv.c |   4 +-
 .../staging/rtl8188eu/hal/rtl8188e_rxdesc.c   |   8 +-
 drivers/staging/rtl8188eu/include/wifi.h  | 156 --
 5 files changed, 16 insertions(+), 170 deletions(-)

-- 
2.26.2

[PATCH 1/4] staging:r8188eu: replace get_(d|s)a with ieee80211_get_(D|S)A

[Ivan Safonov]

get_da()/get_sa() duplicate native ieee80211_get_(D|S)A functions.
Remove get_(d|s)a, use ieee80211_get_(D|S)A instead.

Signed-off-by: Ivan Safonov 
---
 drivers/staging/rtl8188eu/core/rtw_mlme_ext.c |  6 +--
 drivers/staging/rtl8188eu/core/rtw_recv.c |  4 +-
 .../staging/rtl8188eu/hal/rtl8188e_rxdesc.c   |  4 +-
 drivers/staging/rtl8188eu/include/wifi.h  | 44 ---
 4 files changed, 7 insertions(+), 51 deletions(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
index ebd9b96a8211..bee19d5b22c0 100644
--- a/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8188eu/core/rtw_mlme_ext.c
@@ -2526,7 +2526,7 @@ static unsigned int OnProbeReq(struct adapter *padapter,
 
if (check_fwstate(pmlmepriv, _FW_LINKED) &&
pmlmepriv->cur_network.join_res)
-   issue_probersp(padapter, get_sa(pframe));
+   issue_probersp(padapter, ieee80211_get_SA((struct 
ieee80211_hdr *)pframe));
}
return _SUCCESS;
 }
@@ -2819,7 +2819,7 @@ static unsigned int OnAuthClient(struct adapter *padapter,
DBG_88E("%s\n", __func__);
 
/* check A1 matches or not */
-   if (memcmp(myid(&padapter->eeprompriv), get_da(pframe), ETH_ALEN))
+   if (memcmp(myid(&padapter->eeprompriv), ieee80211_get_DA((struct 
ieee80211_hdr *)pframe), ETH_ALEN))
return _SUCCESS;
 
if (!(pmlmeinfo->state & WIFI_FW_AUTH_STATE))
@@ -3332,7 +3332,7 @@ static unsigned int OnAssocRsp(struct adapter *padapter,
DBG_88E("%s\n", __func__);
 
/* check A1 matches or not */
-   if (memcmp(myid(&padapter->eeprompriv), get_da(pframe), ETH_ALEN))
+   if (memcmp(myid(&padapter->eeprompriv), ieee80211_get_DA((struct 
ieee80211_hdr *)pframe), ETH_ALEN))
return _SUCCESS;
 
if (!(pmlmeinfo->state & (WIFI_FW_AUTH_SUCCESS | WIFI_FW_ASSOC_STATE)))
diff --git a/drivers/staging/rtl8188eu/core/rtw_recv.c 
b/drivers/staging/rtl8188eu/core/rtw_recv.c
index 36bcbe635cf4..b9b4bc435037 100644
--- a/drivers/staging/rtl8188eu/core/rtw_recv.c
+++ b/drivers/staging/rtl8188eu/core/rtw_recv.c
@@ -1029,8 +1029,8 @@ static int validate_recv_data_frame(struct adapter 
*adapter,
int ret = _SUCCESS;
 
bretry = GetRetry(ptr);
-   pda = get_da(ptr);
-   psa = get_sa(ptr);
+   pda = ieee80211_get_DA((struct ieee80211_hdr *)ptr);
+   psa = ieee80211_get_SA((struct ieee80211_hdr *)ptr);
pbssid = get_hdr_bssid(ptr);
 
if (!pbssid) {
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c 
b/drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c
index 0d06cb54b1ad..4fae75fc3dd5 100644
--- a/drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c
+++ b/drivers/staging/rtl8188eu/hal/rtl8188e_rxdesc.c
@@ -150,7 +150,7 @@ void update_recvframe_phyinfo_88e(struct recv_frame 
*precvframe,
 get_bssid(&padapter->mlmepriv), ETH_ALEN));
 
pkt_info.bPacketToSelf = pkt_info.bPacketMatchBSSID &&
-(!memcmp(get_da(wlanhdr),
+(!memcmp(ieee80211_get_DA((struct 
ieee80211_hdr *)wlanhdr),
  myid(&padapter->eeprompriv), ETH_ALEN));
 
pkt_info.bPacketBeacon = pkt_info.bPacketMatchBSSID &&
@@ -161,7 +161,7 @@ void update_recvframe_phyinfo_88e(struct recv_frame 
*precvframe,
sa = padapter->mlmepriv.cur_network.network.MacAddress;
/* to do Ad-hoc */
} else {
-   sa = get_sa(wlanhdr);
+   sa = ieee80211_get_SA((struct ieee80211_hdr *)wlanhdr);
}
 
pstapriv = &padapter->stapriv;
diff --git a/drivers/staging/rtl8188eu/include/wifi.h 
b/drivers/staging/rtl8188eu/include/wifi.h
index 1b9006879a11..5ee4d02e293c 100644
--- a/drivers/staging/rtl8188eu/include/wifi.h
+++ b/drivers/staging/rtl8188eu/include/wifi.h
@@ -201,50 +201,6 @@ enum WIFI_REG_DOMAIN {
 
 #define GetAddr4Ptr(pbuf)  ((unsigned char *)((size_t)(pbuf) + 24))
 
-static inline unsigned char *get_da(unsigned char *pframe)
-{
-   unsigned char   *da;
-   unsigned int to_fr_ds = (GetToDs(pframe) << 1) | GetFrDs(pframe);
-
-   switch (to_fr_ds) {
-   case 0x00:  /*  ToDs=0, FromDs=0 */
-   da = GetAddr1Ptr(pframe);
-   break;
-   case 0x01:  /*  ToDs=0, FromDs=1 */
-   da = GetAddr1Ptr(pframe);
-   break;
-   case 0x02:  /*  ToDs=1, FromDs=0 */
-   da = GetAddr3Ptr(pframe);
-   break;
-   default:/*  ToDs=1, FromDs=1 */
-   da = GetAddr3Ptr(pframe);
-   break;
-   }
-   return da;
-}
-
-static inline unsigned char *get_sa(unsigned char *pframe)
-{
-   unsigned char   *sa;
-   unsigned intto_fr_ds = (GetToDs(pframe) << 1) | GetFrDs(pframe);
-
-   switch (to_fr_ds) {
-   case 0x00:

Re: [Linux-stm32] [PATCH v9 22/33] counter: Internalize sysfs interface code

[William Breathitt Gray]

On Sun, Mar 14, 2021 at 04:56:44PM +0900, William Breathitt Gray wrote:
> On Fri, Mar 12, 2021 at 04:02:42PM +0100, Fabrice Gasnier wrote:
> > On 3/9/21 2:19 PM, William Breathitt Gray wrote:
> > > +static ssize_t enums_available_show(const u32 *const enums,
> > > + const size_t num_enums,
> > > + const char *const strs[], char *buf)
> > > +{
> > > + size_t len = 0;
> > > + size_t index;
> > > +
> > > + for (index = 0; index < num_enums; index++)
> > > + len += sysfs_emit(buf + len, "%s\n", strs[enums[index]]);
> > > +
> > > + return len;
> > > +}
> > > +
> > > +static ssize_t strs_available_show(const struct counter_available *const 
> > > avail,
> > > +char *buf)
> > > +{
> > > + size_t len = 0;
> > > + size_t index;
> > > +
> > > + for (index = 0; index < avail->num_items; index++)
> > > + len += sysfs_emit(buf + len, "%s\n", avail->strs[index]);
> > > +
> > > + return len;
> > > +}
> > 
> > Hi William,
> > 
> > I was willing to do some testing on this series, on the stm32 counter
> > drivers, since we released few fixes around them.
> > 
> > I tried to apply this series against current testing branch, with few
> > patches applied (so it applies cleanly):
> > - dt-bindings: counter: add interrupt-counter binding
> > - counter: add IRQ or GPIO based counter
> > - counter: stm32-timer-cnt: fix ceiling miss-alignment with reload register
> > - counter: stm32-timer-cnt: fix ceiling write max value
> >  counter: stm32-timer-cnt: Report count function when SLAVE_MODE_DISABLED
> > 
> > 
> > For both the "stm32-lptimer-cnt" and "stm32-timer-cnt" drivers, I get a
> > warning message and stack dump in "sysfs_emit" when reading the
> > available functions from sysfs.
> > I started to do some testing on v8 of this series last week. I didn't
> > noticed that.
> > 
> > For both the "stm32-lptimer-cnt", there are 2 functions currently I get
> > 1 stack dump. Only the "increase" function is printed correctly.
> > 
> > For the "stm32-timer-cnt", there are 4 functions currently, I get 3
> > stack dumps. Only the "increase" function is printed correctly
> > 
> > Sample log for "stm32-timer-cnt:
> > 
> > root@stm32mp1:/sys/devices/platform/soc/4400.timer/4400.timer:counter/counter0#
> > cat count0/function_available
> > [ 4689.195506] [ cut here ]
> > [ 4689.198747] WARNING: CPU: 1 PID: 5841 at fs/sysfs/file.c:737
> > sysfs_emit+0x88/0x94
> > [ 4689.206233] invalid sysfs_emit: buf:f4a66208
> > [ 4689.210553] Modules linked in: sha256_generic libsha256 sha256_arm
> > cfg80211 panel_orisetech_otm8009a snd_soc_hdmi_codec
> > snd_soc_stm32_sai_sub stm32_lptimers
> > [ 4689.261444] CPU: 1 PID: 5841 Comm: cat Tainted: GW
> > 5.12.0-rc1 #534
> > [ 4689.268999] Hardware name: STM32 (Device Tree Support)
> > [ 4689.274166] [] (unwind_backtrace) from []
> > (show_stack+0x10/0x14)
> > [ 4689.281942] [] (show_stack) from []
> > (dump_stack+0xc0/0xd4)
> > [ 4689.289199] [] (dump_stack) from []
> > (__warn+0xec/0x148)
> > [ 4689.296194] [] (__warn) from []
> > (warn_slowpath_fmt+0x98/0xbc)
> > [ 4689.303714] [] (warn_slowpath_fmt) from []
> > (sysfs_emit+0x88/0x94)
> > [ 4689.311586] [] (sysfs_emit) from []
> > (counter_comp_available_show+0x11c/0x1a4 [counter])
> > [ 4689.321382] [] (counter_comp_available_show [counter]) from
> > [] (dev_attr_show+0x18/0x48)
> > [ 4689.331263] [] (dev_attr_show) from []
> > (sysfs_kf_seq_show+0x88/0xf0)
> > [ 4689.339394] [] (sysfs_kf_seq_show) from []
> > (seq_read_iter+0x1a4/0x554)
> > [ 4689.347703] [] (seq_read_iter) from []
> > (vfs_read+0x1ac/0x2c4)
> > [ 4689.355224] [] (vfs_read) from []
> > (ksys_read+0x64/0xdc)
> > [ 4689.362219] [] (ksys_read) from []
> > (ret_fast_syscall+0x0/0x58)
> > [ 4689.369827] Exception stack(0xc7261fa8 to 0xc7261ff0)
> > [ 4689.374906] 1fa0:    0002 0003
> > b6f35000 0002 
> > [ 4689.383126] 1fc0:  0002 b6f56ce0 0003 0003
> >  0002 
> > [ 4689.391344] 1fe0: 0003 be8239a8 410bff27 4104c066
> > ...
> > 2 more stack dumps follow
> > ...
> > [ 4689.810479] ---[ end trace 59ed79949efe984c ]---
> > increase
> > 
> > I get similar backtrace with other _available attributes:
> > $ cat signal0_action_available
> > $ cat signal1_action_available
> > 
> > Do you think I'm doing something wrong ?
> > 
> > I tested then "quadrature x4" on the timer driver... It seems all fine.
> > 
> > Best regards
> > Fabrice
> > 
> > > +
> > > +static ssize_t counter_comp_available_show(struct device *dev,
> > > +struct device_attribute *attr,
> > > +char *buf)
> > > +{
> > > + const struct counter_attribute *const a = to_counter_attribute(attr);
> > > + const struct counter_count *const count = a->parent;
> > > + const struct counter_synapse *const synapse = a->comp.priv;
> > > + const struct coun

[PATCH v3 0/3] Move kernel mapping outside the linear mapping

[Alexandre Ghiti]

I decided to split sv48 support in small series to ease the review.

This patchset pushes the kernel mapping (modules and BPF too) to the last
4GB of the 64bit address space, this allows to:
- implement relocatable kernel (that will come later in another
  patchset) that requires to move the kernel mapping out of the linear
  mapping to avoid to copy the kernel at a different physical address.
- have a single kernel that is not relocatable (and then that avoids the
  performance penalty imposed by PIC kernel) for both sv39 and sv48.

The first patch implements this behaviour, the second patch introduces a
documentation that describes the virtual address space layout of the 64bit
kernel and the last patch is taken from my sv48 series where I simply added
the dump of the modules/kernel/BPF mapping.

I removed the Reviewed-by on the first patch since it changed enough from
last time and deserves a second look.

Changes in v3:
- Fix broken nommu build as reported by kernel test robot by protecting
  the kernel mapping only in 64BIT and MMU configs, by reverting the
  introduction of load_sz_pmd and by not exporting load_sz/load_pa anymore
  since they were not initialized in nommu config. 

Changes in v2:
- Fix documentation about direct mapping size which is 124GB instead
  of 126GB.
- Fix SPDX missing header in documentation.
- Fix another checkpatch warning about EXPORT_SYMBOL which was not
  directly below variable declaration.

Alexandre Ghiti (3):
  riscv: Move kernel mapping outside of linear mapping
  Documentation: riscv: Add documentation that describes the VM layout
  riscv: Prepare ptdump for vm layout dynamic addresses

 Documentation/riscv/index.rst   |  1 +
 Documentation/riscv/vm-layout.rst   | 63 +++
 arch/riscv/boot/loader.lds.S|  3 +-
 arch/riscv/include/asm/page.h   | 17 ++-
 arch/riscv/include/asm/pgtable.h| 37 ++
 arch/riscv/include/asm/set_memory.h |  1 +
 arch/riscv/kernel/head.S|  3 +-
 arch/riscv/kernel/module.c  |  6 +--
 arch/riscv/kernel/setup.c   |  5 ++
 arch/riscv/kernel/vmlinux.lds.S |  3 +-
 arch/riscv/mm/fault.c   | 13 +
 arch/riscv/mm/init.c| 78 ++---
 arch/riscv/mm/kasan_init.c  |  9 
 arch/riscv/mm/physaddr.c|  2 +-
 arch/riscv/mm/ptdump.c  | 67 -
 15 files changed, 258 insertions(+), 50 deletions(-)
 create mode 100644 Documentation/riscv/vm-layout.rst

-- 
2.20.1

Re: [PATCH v10 1/2] scsi: ufs: Enable power management for wlun

[Adrian Hunter]

On 10/03/21 5:04 am, Asutosh Das (asd) wrote:
> On 3/9/2021 7:56 AM, Asutosh Das (asd) wrote:
>> On 3/8/2021 9:17 AM, Rafael J. Wysocki wrote:
>>> On Mon, Mar 8, 2021 at 5:21 PM Rafael J. Wysocki  wrote:

 On Sat, Mar 6, 2021 at 5:17 PM Alan Stern  
 wrote:
>
> On Fri, Mar 05, 2021 at 06:54:24PM -0800, Asutosh Das (asd) wrote:
>
>> Now during my testing I see a weird issue sometimes (1 in 7).
>> Scenario - bootups
>>
>> Issue:
>> The supplier 'ufs_device_wlun 0:0:0:49488' goes into runtime suspend even
>> when one/more of its consumers are in RPM_ACTIVE state.
>>
>> *Log:
>> [   10.056379][  T206] sd 0:0:0:1: [sdb] Synchronizing SCSI cache
>> [   10.062497][  T113] sd 0:0:0:5: [sdf] Synchronizing SCSI cache
>> [   10.356600][   T32] sd 0:0:0:7: [sdh] Synchronizing SCSI cache
>> [   10.362944][  T174] sd 0:0:0:3: [sdd] Synchronizing SCSI cache
>> [   10.696627][   T83] sd 0:0:0:2: [sdc] Synchronizing SCSI cache
>> [   10.704562][  T170] sd 0:0:0:6: [sdg] Synchronizing SCSI cache
>> [   10.980602][    T5] sd 0:0:0:0: [sda] Synchronizing SCSI cache
>>
>> /** Printing all the consumer nodes of supplier **/
>> [   10.987327][    T5] ufs_device_wlun 0:0:0:49488: usage-count @ 
>> suspend: 0
>> <-- this is the usage_count
>> [   10.994440][    T5] ufs_rpmb_wlun 0:0:0:49476: PM state - 2
>> [   11.000402][    T5] scsi 0:0:0:49456: PM state - 2
>> [   11.005453][    T5] sd 0:0:0:0: PM state - 2
>> [   11.009958][    T5] sd 0:0:0:1: PM state - 2
>> [   11.014469][    T5] sd 0:0:0:2: PM state - 2
>> [   11.019072][    T5] sd 0:0:0:3: PM state - 2
>> [   11.023595][    T5] sd 0:0:0:4: PM state - 0 << RPM_ACTIVE
>> [   11.353298][    T5] sd 0:0:0:5: PM state - 2
>> [   11.357726][    T5] sd 0:0:0:6: PM state - 2
>> [   11.362155][    T5] sd 0:0:0:7: PM state - 2
>> [   11.366584][    T5] ufshcd-qcom 1d84000.ufshc: __ufshcd_wl_suspend - 
>> 8709
>> [   11.374366][    T5] ufs_device_wlun 0:0:0:49488: __ufshcd_wl_suspend -
>> (0) has rpm_active flags

 Do you mean that rpm_active of the link between the consumer and the
 supplier is greater than 0 at this point and the consumer is
>>>
>>> I mean is rpm_active of the link greater than 1 (because 1 means "no
>>> active references to the supplier")?
>> Hi Rafael:
>> No - it is not greater than 1.
>>
>> I'm trying to understand what's going on in it; will update when I've 
>> something.
>>
>>>
 RPM_ACTIVE, but the supplier suspends successfully nevertheless?

>> [   11.383376][    T5] ufs_device_wlun 0:0:0:49488:
>> ufshcd_wl_runtime_suspend <-- Supplier suspends fine.
>> [   12.977318][  T174] sd 0:0:0:4: [sde] Synchronizing SCSI cache
>>
>> And the the suspend of sde is stuck now:
>> schedule+0x9c/0xe0
>> schedule_timeout+0x40/0x128
>> io_schedule_timeout+0x44/0x68
>> wait_for_common_io+0x7c/0x100
>> wait_for_completion_io+0x14/0x20
>> blk_execute_rq+0x90/0xcc
>> __scsi_execute+0x104/0x1c4
>> sd_sync_cache+0xf8/0x2a0
>> sd_suspend_common+0x74/0x11c
>> sd_suspend_runtime+0x14/0x20
>> scsi_runtime_suspend+0x64/0x94
>> __rpm_callback+0x80/0x2a4
>> rpm_suspend+0x308/0x614
>> pm_runtime_work+0x98/0xa8
>>
>> I added 'DL_FLAG_RPM_ACTIVE' while creating links.
>>    if (hba->sdev_ufs_device) {
>>    link = device_link_add(&sdev->sdev_gendev,
>>    &hba->sdev_ufs_device->sdev_gendev,
>>   DL_FLAG_PM_RUNTIME|DL_FLAG_RPM_ACTIVE);
>> I didn't expect this to resolve the issue anyway and it didn't.
>>
>> Another interesting point here is when I resume any of the above 
>> suspended
>> consumers, it all goes back to normal, which is kind of expected. I tried
>> resuming the consumer and the supplier is resumed and the supplier is
>> suspended when all the consumers are suspended.
>>
>> Any pointers on this issue please?
>>
>> @Bart/@Alan - Do you've any pointers please?
>
> It's very noticeable that although you seem to have isolated a bug in
> the power management subsystem (supplier goes into runtime suspend
> even when one of its consumers is still active), you did not CC the
> power management maintainer or mailing list.
>
> I have added the appropriate CC's.

 Thanks Alan!
>>
>>
> 
> Hello
> I & Can (thanks CanG) debugged this further:
> 
> Looks like this issue can occur if the sd probe is asynchronous.
> 
> Essentially, the sd_probe() is done asynchronously and driver_probe_device() 
> invokes pm_runtime_get_suppliers() before invoking sd_probe().
> 
> But scsi_probe_and_add_lun() runs in a separate context.
> So the scsi_autopm_put_device() invoked from scsi_scan_host() context reduces 
> the link->rpm_active to 1. And sd_probe() invokes scsi_autopm

[PATCH v3 1/3] riscv: Move kernel mapping outside of linear mapping

[Alexandre Ghiti]

This is a preparatory patch for relocatable kernel and sv48 support.

The kernel used to be linked at PAGE_OFFSET address therefore we could use
the linear mapping for the kernel mapping. But the relocated kernel base
address will be different from PAGE_OFFSET and since in the linear mapping,
two different virtual addresses cannot point to the same physical address,
the kernel mapping needs to lie outside the linear mapping so that we don't
have to copy it at the same physical offset.

The kernel mapping is moved to the last 2GB of the address space, BPF
is now always after the kernel and modules use the 2GB memory range right
before the kernel, so BPF and modules regions do not overlap. KASLR
implementation will simply have to move the kernel in the last 2GB range
and just take care of leaving enough space for BPF.

In addition, by moving the kernel to the end of the address space, both
sv39 and sv48 kernels will be exactly the same without needing to be
relocated at runtime.

Suggested-by: Arnd Bergmann 
Signed-off-by: Alexandre Ghiti 
---
 arch/riscv/boot/loader.lds.S|  3 +-
 arch/riscv/include/asm/page.h   | 17 ++-
 arch/riscv/include/asm/pgtable.h| 37 ++
 arch/riscv/include/asm/set_memory.h |  1 +
 arch/riscv/kernel/head.S|  3 +-
 arch/riscv/kernel/module.c  |  6 +--
 arch/riscv/kernel/setup.c   |  5 ++
 arch/riscv/kernel/vmlinux.lds.S |  3 +-
 arch/riscv/mm/fault.c   | 13 +
 arch/riscv/mm/init.c| 78 ++---
 arch/riscv/mm/kasan_init.c  |  9 
 arch/riscv/mm/physaddr.c|  2 +-
 12 files changed, 139 insertions(+), 38 deletions(-)

diff --git a/arch/riscv/boot/loader.lds.S b/arch/riscv/boot/loader.lds.S
index 47a5003c2e28..62d94696a19c 100644
--- a/arch/riscv/boot/loader.lds.S
+++ b/arch/riscv/boot/loader.lds.S
@@ -1,13 +1,14 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 
 #include 
+#include 
 
 OUTPUT_ARCH(riscv)
 ENTRY(_start)
 
 SECTIONS
 {
-   . = PAGE_OFFSET;
+   . = KERNEL_LINK_ADDR;
 
.payload : {
*(.payload)
diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
index adc9d26f3d75..0cdd0c4db941 100644
--- a/arch/riscv/include/asm/page.h
+++ b/arch/riscv/include/asm/page.h
@@ -90,15 +90,28 @@ typedef struct page *pgtable_t;
 
 #ifdef CONFIG_MMU
 extern unsigned long va_pa_offset;
+extern unsigned long va_kernel_pa_offset;
 extern unsigned long pfn_base;
 #define ARCH_PFN_OFFSET(pfn_base)
 #else
 #define va_pa_offset   0
+#define va_kernel_pa_offset0
 #define ARCH_PFN_OFFSET(PAGE_OFFSET >> PAGE_SHIFT)
 #endif /* CONFIG_MMU */
 
-#define __pa_to_va_nodebug(x)  ((void *)((unsigned long) (x) + va_pa_offset))
-#define __va_to_pa_nodebug(x)  ((unsigned long)(x) - va_pa_offset)
+extern unsigned long kernel_virt_addr;
+
+#define linear_mapping_pa_to_va(x) ((void *)((unsigned long)(x) + 
va_pa_offset))
+#define __pa_to_va_nodebug(x)  linear_mapping_pa_to_va(x)
+
+#define linear_mapping_va_to_pa(x) ((unsigned long)(x) - va_pa_offset)
+#define kernel_mapping_va_to_pa(x) \
+   ((unsigned long)(x) - va_kernel_pa_offset)
+#define __va_to_pa_nodebug(x)  ({  
\
+   unsigned long _x = x;   
\
+   (_x < kernel_virt_addr) ?   
\
+   linear_mapping_va_to_pa(_x) : kernel_mapping_va_to_pa(_x);  
\
+   })
 
 #ifdef CONFIG_DEBUG_VIRTUAL
 extern phys_addr_t __virt_to_phys(unsigned long x);
diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index ebf817c1bdf4..80e63a93e903 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -11,23 +11,30 @@
 
 #include 
 
-#ifndef __ASSEMBLY__
-
-/* Page Upper Directory not used in RISC-V */
-#include 
-#include 
-#include 
-#include 
+#ifndef CONFIG_MMU
+#define KERNEL_LINK_ADDR   PAGE_OFFSET
+#else
 
-#ifdef CONFIG_MMU
+#define ADDRESS_SPACE_END  (UL(-1))
+/*
+ * Leave 2GB for kernel and BPF at the end of the address space
+ */
+#define KERNEL_LINK_ADDR   (ADDRESS_SPACE_END - SZ_2G + 1)
 
 #define VMALLOC_SIZE (KERN_VIRT_SIZE >> 1)
 #define VMALLOC_END  (PAGE_OFFSET - 1)
 #define VMALLOC_START(PAGE_OFFSET - VMALLOC_SIZE)
 
+/* KASLR should leave at least 128MB for BPF after the kernel */
 #define BPF_JIT_REGION_SIZE(SZ_128M)
-#define BPF_JIT_REGION_START   (PAGE_OFFSET - BPF_JIT_REGION_SIZE)
-#define BPF_JIT_REGION_END (VMALLOC_END)
+#define BPF_JIT_REGION_START   PFN_ALIGN((unsigned long)&_end)
+#define BPF_JIT_REGION_END (BPF_JIT_REGION_START + BPF_JIT_REGION_SIZE)
+
+/* Modules always live before the kernel */
+#ifdef CONFIG_64BIT
+#define MODULES_VADDR  (PFN_ALIGN((unsigned long)&_end) - SZ_2G)
+#define MODULES_END(PFN_ALIGN((unsigned long)&_start))
+#endif
 
 /*

[PATCH v3 2/3] Documentation: riscv: Add documentation that describes the VM layout

[Alexandre Ghiti]

This new document presents the RISC-V virtual memory layout and is based
one the x86 one: it describes the different limits of the different regions
of the virtual address space.

Signed-off-by: Alexandre Ghiti 
---
 Documentation/riscv/index.rst |  1 +
 Documentation/riscv/vm-layout.rst | 63 +++
 2 files changed, 64 insertions(+)
 create mode 100644 Documentation/riscv/vm-layout.rst

diff --git a/Documentation/riscv/index.rst b/Documentation/riscv/index.rst
index 6e6e39482502..ea915c196048 100644
--- a/Documentation/riscv/index.rst
+++ b/Documentation/riscv/index.rst
@@ -6,6 +6,7 @@ RISC-V architecture
 :maxdepth: 1
 
 boot-image-header
+vm-layout
 pmu
 patch-acceptance
 
diff --git a/Documentation/riscv/vm-layout.rst 
b/Documentation/riscv/vm-layout.rst
new file mode 100644
index ..329d32098af4
--- /dev/null
+++ b/Documentation/riscv/vm-layout.rst
@@ -0,0 +1,63 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+=
+Virtual Memory Layout on RISC-V Linux
+=
+
+:Author: Alexandre Ghiti 
+:Date: 12 February 2021
+
+This document describes the virtual memory layout used by the RISC-V Linux
+Kernel.
+
+RISC-V Linux Kernel 32bit
+=
+
+RISC-V Linux Kernel SV32
+
+
+TODO
+
+RISC-V Linux Kernel 64bit
+=
+
+The RISC-V privileged architecture document states that the 64bit addresses
+"must have bits 63–48 all equal to bit 47, or else a page-fault exception will
+occur.": that splits the virtual address space into 2 halves separated by a 
very
+big hole, the lower half is where the userspace resides, the upper half is 
where
+the RISC-V Linux Kernel resides.
+
+RISC-V Linux Kernel SV39
+
+
+::
+
+  

+  Start addr|   Offset   | End addr |  Size   | VM area 
description
+  

+||  | |
+    |0   | 003f |  256 GB | user-space 
virtual memory, different per mm
+  
__||__|_|___
+||  | |
+   0040 | +256GB | ffbf | ~16M TB | ... huge, 
almost 64 bits wide hole of non-canonical
+||  | | virtual 
memory addresses up to the -256 GB
+||  | | starting 
offset of kernel mappings.
+  
__||__|_|___
+  |
+  | Kernel-space 
virtual memory, shared between all processes:
+  
|___
+||  | |
+   ffc0 | -256GB | ffc7 |   32 GB | kasan
+   ffcefee0 | -196GB | ffcefeff |2 MB | fixmap
+   ffceff00 | -196GB | ffce |   16 MB | PCI io
+   ffcf | -196GB | ffcf |4 GB | vmemmap
+   ffd0 | -192GB | ffdf |   64 GB | 
vmalloc/ioremap space
+   ffe0 | -128GB | 7fff |  124 GB | direct mapping 
of all physical memory
+  
__||__|_|
+  |
+  |
+  
|
+||  | |
+    |   -4GB | 7fff |2 GB | modules
+   8000 |   -2GB |  |2 GB | kernel, BPF
+  
__||__|_|
-- 
2.20.1

[PATCH v3 3/3] riscv: Prepare ptdump for vm layout dynamic addresses

[Alexandre Ghiti]

This is a preparatory patch for sv48 support that will introduce
dynamic PAGE_OFFSET.

Dynamic PAGE_OFFSET implies that all zones (vmalloc, vmemmap, fixaddr...)
whose addresses depend on PAGE_OFFSET become dynamic and can't be used
to statically initialize the array used by ptdump to identify the
different zones of the vm layout.

Signed-off-by: Alexandre Ghiti 
Reviewed-by: Anup Patel 
---
 arch/riscv/mm/ptdump.c | 67 ++
 1 file changed, 55 insertions(+), 12 deletions(-)

diff --git a/arch/riscv/mm/ptdump.c b/arch/riscv/mm/ptdump.c
index ace74dec7492..aa1b3bce61ab 100644
--- a/arch/riscv/mm/ptdump.c
+++ b/arch/riscv/mm/ptdump.c
@@ -58,29 +58,52 @@ struct ptd_mm_info {
unsigned long end;
 };
 
+enum address_markers_idx {
+#ifdef CONFIG_KASAN
+   KASAN_SHADOW_START_NR,
+   KASAN_SHADOW_END_NR,
+#endif
+   FIXMAP_START_NR,
+   FIXMAP_END_NR,
+   PCI_IO_START_NR,
+   PCI_IO_END_NR,
+#ifdef CONFIG_SPARSEMEM_VMEMMAP
+   VMEMMAP_START_NR,
+   VMEMMAP_END_NR,
+#endif
+   VMALLOC_START_NR,
+   VMALLOC_END_NR,
+   PAGE_OFFSET_NR,
+   MODULES_MAPPING_NR,
+   KERNEL_MAPPING_NR,
+   END_OF_SPACE_NR
+};
+
 static struct addr_marker address_markers[] = {
 #ifdef CONFIG_KASAN
-   {KASAN_SHADOW_START,"Kasan shadow start"},
-   {KASAN_SHADOW_END,  "Kasan shadow end"},
+   {0, "Kasan shadow start"},
+   {0, "Kasan shadow end"},
 #endif
-   {FIXADDR_START, "Fixmap start"},
-   {FIXADDR_TOP,   "Fixmap end"},
-   {PCI_IO_START,  "PCI I/O start"},
-   {PCI_IO_END,"PCI I/O end"},
+   {0, "Fixmap start"},
+   {0, "Fixmap end"},
+   {0, "PCI I/O start"},
+   {0, "PCI I/O end"},
 #ifdef CONFIG_SPARSEMEM_VMEMMAP
-   {VMEMMAP_START, "vmemmap start"},
-   {VMEMMAP_END,   "vmemmap end"},
+   {0, "vmemmap start"},
+   {0, "vmemmap end"},
 #endif
-   {VMALLOC_START, "vmalloc() area"},
-   {VMALLOC_END,   "vmalloc() end"},
-   {PAGE_OFFSET,   "Linear mapping"},
+   {0, "vmalloc() area"},
+   {0, "vmalloc() end"},
+   {0, "Linear mapping"},
+   {0, "Modules mapping"},
+   {0, "Kernel mapping (kernel, BPF)"},
{-1, NULL},
 };
 
 static struct ptd_mm_info kernel_ptd_info = {
.mm = &init_mm,
.markers= address_markers,
-   .base_addr  = KERN_VIRT_START,
+   .base_addr  = 0,
.end= ULONG_MAX,
 };
 
@@ -335,6 +358,26 @@ static int ptdump_init(void)
 {
unsigned int i, j;
 
+#ifdef CONFIG_KASAN
+   address_markers[KASAN_SHADOW_START_NR].start_address = 
KASAN_SHADOW_START;
+   address_markers[KASAN_SHADOW_END_NR].start_address = KASAN_SHADOW_END;
+#endif
+   address_markers[FIXMAP_START_NR].start_address = FIXADDR_START;
+   address_markers[FIXMAP_END_NR].start_address = FIXADDR_TOP;
+   address_markers[PCI_IO_START_NR].start_address = PCI_IO_START;
+   address_markers[PCI_IO_END_NR].start_address = PCI_IO_END;
+#ifdef CONFIG_SPARSEMEM_VMEMMAP
+   address_markers[VMEMMAP_START_NR].start_address = VMEMMAP_START;
+   address_markers[VMEMMAP_END_NR].start_address = VMEMMAP_END;
+#endif
+   address_markers[VMALLOC_START_NR].start_address = VMALLOC_START;
+   address_markers[VMALLOC_END_NR].start_address = VMALLOC_END;
+   address_markers[PAGE_OFFSET_NR].start_address = PAGE_OFFSET;
+   address_markers[MODULES_MAPPING_NR].start_address = MODULES_VADDR;
+   address_markers[KERNEL_MAPPING_NR].start_address = kernel_virt_addr;
+
+   kernel_ptd_info.base_addr = KERN_VIRT_START;
+
for (i = 0; i < ARRAY_SIZE(pg_level); i++)
for (j = 0; j < ARRAY_SIZE(pte_bits); j++)
pg_level[i].mask |= pte_bits[j].mask;
-- 
2.20.1

Re: [PATCH v7 1/3] block: add blk_mq_is_queue_frozen()

[Christoph Hellwig]

On Fri, Mar 12, 2021 at 02:06:41PM -0500, Mike Snitzer wrote:
> This is returning a frozen state that is immediately stale.  I don't
> think any code calling this is providing the guarantees you think it
> does due to the racey nature of this state once the mutex is dropped.

The code only uses it for asserts in the form of WARN_ONs.

Re: [PATCH] firewire: Use bitwise instead of arithmetic operator for flags

[Stefan Richter]

On Mar 09 Jiapeng Chong wrote:
> Fix the following coccicheck warnings:
> 
> ./drivers/firewire/core-device.c:973:22-23: WARNING: sum of probable
> bitmasks, consider |.
> 
> ./drivers/firewire/core-device.c:954:22-23: WARNING: sum of probable
> bitmasks, consider |.
> 
> Reported-by: Abaci Robot 
> Signed-off-by: Jiapeng Chong 
> ---
>  drivers/firewire/core-device.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/firewire/core-device.c b/drivers/firewire/core-device.c
> index 6821698..e04832d 100644
> --- a/drivers/firewire/core-device.c
> +++ b/drivers/firewire/core-device.c
> @@ -951,7 +951,7 @@ static void set_broadcast_channel(struct fw_device 
> *device, int generation)
>   if (device->bc_implemented == BC_UNKNOWN) {
>   rcode = fw_run_transaction(card, TCODE_READ_QUADLET_REQUEST,
>   device->node_id, generation, device->max_speed,
> - CSR_REGISTER_BASE + CSR_BROADCAST_CHANNEL,
> + CSR_REGISTER_BASE | CSR_BROADCAST_CHANNEL,
>   &data, 4);
>   switch (rcode) {
>   case RCODE_COMPLETE:
> @@ -970,7 +970,7 @@ static void set_broadcast_channel(struct fw_device 
> *device, int generation)
>  BROADCAST_CHANNEL_VALID);
>   fw_run_transaction(card, TCODE_WRITE_QUADLET_REQUEST,
>   device->node_id, generation, device->max_speed,
> - CSR_REGISTER_BASE + CSR_BROADCAST_CHANNEL,
> + CSR_REGISTER_BASE | CSR_BROADCAST_CHANNEL,
>   &data, 4);
>   }
>  }

It's "base address + address offset". The arithmetic operator is correct.
-- 
Stefan Richter
-==--=-= --== -===-
http://arcgraph.de/sr/

[linux-stable-rc CI] Test report for 5.10.24-rc1 /arm64

[hulkrobot]

Kernel repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-5.10.y
Arch: arm64
Version: 5.10.24-rc1
Commit: 7496dbd02b27316275e097a4e52cebcd2ca5a5c0
Compiler: gcc version 7.3.0 (GCC)

Failed cases :
ltp test_robind29
ltp test_robind30
ltp test_robind31
ltp test_robind32
ltp test_robind33
ltp test_robind34
ltp test_robind36
ltp test_robind37

Testcase Result Summary:
total_num: 4693
succeed_num: 4685
failed_num: 8
timeout_num: 0

Tested-by: Hulk Robot 

Re: [PATCH v7 2/3] block: add bdev_interposer

[Christoph Hellwig]

On Fri, Mar 12, 2021 at 06:44:54PM +0300, Sergei Shtepa wrote:
> bdev_interposer allows to redirect bio requests to another devices.

I think this warrants a somewhat more detailed description.

The code itself looks pretty good to me now, a bunch of nitpicks and
a question below:

> +static noinline blk_qc_t submit_bio_interposed(struct bio *bio)
> +{
> + blk_qc_t ret = BLK_QC_T_NONE;
> + struct bio_list bio_list[2] = { };
> + struct gendisk *orig_disk;
> +
> + if (current->bio_list) {
> + bio_list_add(¤t->bio_list[0], bio);
> + return BLK_QC_T_NONE;
> + }

I don't think this case can ever happen:

 - current->bio_list != NULL means a ->submit_bio or blk_mq_submit_bio
   is active.  But if this device is being interposed this means the
   interposer recurses into itself, which should never happen.  So
   I think we'll want a WARN_ON_ONCE here as a debug check instead.

> +
> + orig_disk = bio->bi_bdev->bd_disk;
> + if (unlikely(bio_queue_enter(bio)))
> + return BLK_QC_T_NONE;
> +
> + current->bio_list = bio_list;
> +
> + do {
> + struct block_device *interposer = bio->bi_bdev->bd_interposer;
> +
> + if (unlikely(!interposer)) {
> + /* interposer was removed */
> + bio_list_add(¤t->bio_list[0], bio);
> + break;
> + }
> + /* assign bio to interposer device */
> + bio_set_dev(bio, interposer);
> + bio_set_flag(bio, BIO_INTERPOSED);

Reassigning the bi_bdev here means the original source is lost by the
time we reach the interposer.  This initially seemed a little limiting,
but I guess the interposer driver can just record that information
locally, so we should be fine.  The big upside of this is that no
extra argument to submit_bio_checks, which means less changes to the
normal fast path, so if this works for everyone that is a nice
improvement over my draft.

> +
> + if (!submit_bio_checks(bio))
> + break;
> + /*
> +  * Because the current->bio_list is initialized,
> +  * the submit_bio callback will always return BLK_QC_T_NONE.
> +  */
> + interposer->bd_disk->fops->submit_bio(bio);
> + } while (false);

I find the do { ... } while (false) idiom here a little strange.  Normal
kernel style would be a goto done instead of the breaks.

> +int bdev_interposer_attach(struct block_device *original,
> +struct block_device *interposer)

A kerneldoc comment for bdev_interposer_attach (and
bdev_interposer_detach) would be nice to explain the API a little more.

> +{
> + int ret = 0;
> +
> + if (WARN_ON(((!original) || (!interposer
> + return -EINVAL;

No need for the inner two levels of braces.

> +  * interposer should be simple, no a multi-queue device
> +  */
> + if (!interposer->bd_disk->fops->submit_bio)

Please use queue_is_mq() instead.

> + if (bdev_has_interposer(original))
> + ret = -EBUSY;
> + else {
> + original->bd_interposer = bdgrab(interposer);

Just thinking out a loud:  what happens if the interposed device
goes away?  Shouldn't we at very least also make sure this
gabs another refererence on bdev as well?

> +struct bdev_interposer;

Not needed any more.

> +static inline bool bdev_has_interposer(struct block_device *bdev)
> +{
> + return (bdev->bd_interposer != NULL);
> +};

No need for the braces.

[PATCH v7 0/2] hwspinlock: add sun6i hardware spinlock support

[Wilken Gottwalt]

Most of the Allwinner sun6i compatible devices contain a spinlock unit
which can be used to sync access to devices shared between the ARM cores
and the embedded companion core. According to the datasheets at least 32
spinlocks are supported. The implementation supports 32, 64, 128 and 256
spinlock setups, but there is no known SoC yet, which implements more
than 32 spinlocks.

This driver adds support for this hardware spinlock unit to Linux
including all 4 possible setups. The driver reports the found setup via
debugfs. It can be build as a builtin and normal module by using the
HWSPINLOCK_SUN8I symbol.

This driver is the first step to enable hwspinlock support in Linux, but
also requires support in the firmware of the companion core. This patch
provides the driver and binding documentation but is not yet included
into the sunxi files. Also not every sunxi seem to have support for this
hardware, but it can be found in sun6i, sun8i, sun9i and sun50i devices.

The spinlock hardware has two ways to figure out if a lock is taken. The
lock can simply be readi, or bits of a 32bit wide status register can be
checked. The status register only supports the first 32 locks and may
not cover bigger spinlock setups. Therefore reading/writing a specific
spinlock is used in the driver for checking the status of a lock.

The status register is now free for debugging/testing purposes and can
completely bypass the Linux hwspinlock ABI. This status register will be
used in some additional kernel modules to test the hwspinlock driver.

Testing the driver.

To run all tests it is necessary to take locks on the companion core and
show on the Linux side that the locks were taken by an external event.
This can be achived by using an Allwinner SoC which includes an OpenRisc
companion core and can use the free crust firmware. For this the crust
firmware needs to be changed to take and release spinlocks (a simple
MMIO operation on the hwlock registers), which is currently not
supported by the current crust firmware. The necessary crust fork can
be found here https://github.com/wgottwalt/crust (hwspinlock branch).
It is also necessary to build u-boot with support for this crust/SCP
firmware. This u-boot fork can be found here
https://github.com/crust-firmware/u-boot (crust branch).

To test this driver it is also necessary to pick a device that is fully
supported by the crust firmware. For this the H5 based Friendlyarm
NanoPi NEO2 was used. It is fully supported by u-boot (and the fork),
the crust firmware (via H5 target) and current Linux kernels. In the
crust fork it is necessary to go into debug menu of "make nconfig" and
select the hwspinlock test loop. This debug option enables a loop that
goes through the first 32 spinlocks. It takes/releases a lock one after
another using the timeout functions (and hw timers) of the crust
firmware. A timeout can be set in the debug menu.

Test 1:

This test was done using a mainline u-boot and a crust enabled u-boot.
For this a simple second kernel module was used, which can be found here
https://github.com/wgottwalt/sunxi_hwspinlock/tree/main/test.

Using mainline u-boot it shows that the Linux side correctly takes a
lock, tries to recursively take a lock again (which does not happen) and
releases a lock. This is done for all 32 locks several times.

# modprobe sun6i_hwspinlock_test
[  472.182172] [init]--- SUN6I HWSPINLOCK DRIVER TEST ---
[  472.187491] [run ]--- testing locks 0 to 31 ---
[  472.192058] [test] testing lock 0
[  472.195371] [test]+++ attempt #0 succeded
[  472.199394] [test]+++ attempt #1 succeded
[  472.203411] [test]+++ attempt #2 succeded
[  472.207433] [test] testing lock 1
[  472.210755] [test]+++ attempt #0 succeded
...
[  472.665684] [test]+++ attempt #2 succeded
[  472.669704] [test] testing lock 31
[  472.673117] [test]+++ attempt #0 succeded
[  472.677137] [test]+++ attempt #1 succeded
[  472.681152] [test]+++ attempt #2 succeded

If the same test is done with the hwspinlock loop enabled crust firmware
and the crust enabled u-boot fork, the Linux test kernel module hits the
one lock taken by the crust firmware.

# modprobe sun6i_hwspinlock_test
...
[  945.871840] [test]+++ attempt #1 succeded
[  945.875854] [test]+++ attempt #2 succeded
[  945.879875] [test] testing lock 18
[  945.883273] [test]+++ attempt #0 succeded
[  945.887293] [test]+++ attempt #1 succeded
[  945.891310] [test]+++ attempt #2 succeded
[  945.895329] [test] testing lock 19
[  945.898738] [test] taking lock attempt #0 failed (-16)
[  945.903886] [run ]--- testing specific lock 19 failed (-14) ---
[  945.909811] [test] testing lock 20
[  945.913224] [test]+++ attempt #0 succeded
[  945.917245] [test]+++ attempt #1 succeded
[  945.921265] [test]+++ attempt #2 succeded
[  945.925281] [test] testing lock 21
[  945.928694] [test]+++ attempt #0 succeded
[  945.932709] [test]+++ attempt #1 succeded
...

Test 2:

This is a more complex test which uses the status register to bypass the
Linux hwspinlock 

[PATCH v7 1/2] dt-bindings: hwlock: add sun6i_hwspinlock

[Wilken Gottwalt]

Adds documentation on how to use the sun6i_hwspinlock driver for sun6i
compatible series SoCs.

Signed-off-by: Wilken Gottwalt 
---
Changes in v7:
  - changed dt documentation to the name of the compatible string

Changes in v6:
  - fixed formating and name issues in dt documentation

Changes in v5:
  - changed binding to earliest known supported SoC sun6i-a31
  - dropped unnecessary entries

Changes in v4:
  - changed binding to sun8i-a33-hwpinlock
  - added changes suggested by Maxime Ripard

Changes in v3:
  - changed symbols from sunxi to sun8i

Changes in v2:
  - fixed memory ranges
---
 .../allwinner,sun6i-a31-hwspinlock.yaml   | 45 +++
 1 file changed, 45 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml

diff --git 
a/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml 
b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml
new file mode 100644
index ..733c3d01e56c
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml
@@ -0,0 +1,45 @@
+# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwlock/allwinner,sun6i-hwspinlock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SUN6I hardware spinlock driver for Allwinner sun6i compatible SoCs
+
+maintainers:
+  - Wilken Gottwalt 
+
+description:
+  The hardware unit provides semaphores between the ARM cores and the embedded
+  companion core on the SoC.
+
+properties:
+  compatible:
+const: allwinner,sun6i-a31-hwspinlock
+
+  reg:
+maxItems: 1
+
+  clocks:
+maxItems: 1
+
+  resets:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+  - clocks
+  - resets
+
+additionalProperties: false
+
+examples:
+  - |
+hwlock@1c18000 {
+compatible = "allwinner,sun6i-a31-hwspinlock";
+reg = <0x01c18000 0x1000>;
+clocks = <&ccu CLK_BUS_SPINLOCK>;
+resets = <&ccu RST_BUS_SPINLOCK>;
+};
+...
-- 
2.30.2

Re: [PATCH v7 3/3] dm: add DM_INTERPOSED_FLAG

[Christoph Hellwig]

On Fri, Mar 12, 2021 at 06:44:55PM +0300, Sergei Shtepa wrote:
> DM_INTERPOSED_FLAG allow to create DM targets on "the fly".
> Underlying block device opens without a flag FMODE_EXCL.
> DM target receives bio from the original device via
> bdev_interposer.

This is more of a philopical comment, but the idea of just letting the
interposed reopen the device by itself seems like a bad idea.  I think
that is probably better hidden in the block layer interposer attachment
function, which could do the extra blkdev_get_by_dev for the caller.

[PATCH v7 2/2] hwspinlock: add sun6i hardware spinlock support

[Wilken Gottwalt]

Adds the sun6i_hwspinlock driver for the hardware spinlock unit found in
most of the sun6i compatible SoCs.

This unit provides at least 32 spinlocks in hardware. The implementation
supports 32, 64, 128 or 256 32bit registers. A lock can be taken by
reading a register and released by writing a 0 to it. This driver
supports all 4 spinlock setups, but for now only the first setup (32
locks) seem to exist in available devices. This spinlock unit is shared
between all ARM cores and the embedded companion core. All of them can
take/release a lock with a single cycle operation. It can be used to
sync access to devices shared by the ARM cores and the companion core.

There are two ways to check if a lock is taken. The first way is to read
a lock. If a 0 is returned, the lock was free and is taken now. If an 1
is returned, the caller has to try again. Which means the lock is taken.
The second way is to read a 32bit wide status register where every bit
represents one of the 32 first locks. According to the datasheets this
status register supports only the 32 first locks. This is the reason the
first way (lock read/write) approach is used to be able to cover all 256
locks in future devices. The driver also reports the amount of supported
locks via debugfs.

Signed-off-by: Wilken Gottwalt 
---
Changes in v7:
  - changed probe to use to devm_* and devm_add_action_* function

Changes in v6:
  - changed probe/remove function to use classic functions to better
handle failure situations

Changes in v5:
  - changed symbols to the earliest known supported SoC (sun6i/a31)
  - changed init back to classic probe/remove callbacks

Changes in v4:
  - further simplified driver
  - fixed an add_action_and_reset_ function issue
  - changed bindings from sun8i-hwspinlock to sun8i-a33-hwspinlock

Changes in v3:
  - moved test description to cover letter
  - changed name and symbols from sunxi to sun8i
  - improved driver description
  - further simplified driver
  - fully switched to devm_* and devm_add_action_* functions

Changes in v2:
  - added suggestions from Bjorn Andersson and Maxime Ripard
  - provided better driver and test description
---
 MAINTAINERS   |   6 +
 drivers/hwspinlock/Kconfig|   9 ++
 drivers/hwspinlock/Makefile   |   1 +
 drivers/hwspinlock/sun6i_hwspinlock.c | 210 ++
 4 files changed, 226 insertions(+)
 create mode 100644 drivers/hwspinlock/sun6i_hwspinlock.c

diff --git a/MAINTAINERS b/MAINTAINERS
index d92f85ca831d..d5821c52c502 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -734,6 +734,12 @@ L: linux-cry...@vger.kernel.org
 S: Maintained
 F: drivers/crypto/allwinner/
 
+ALLWINNER HARDWARE SPINLOCK SUPPORT
+M: Wilken Gottwalt 
+S: Maintained
+F: Documentation/devicetree/bindings/hwlock/allwinner,sun6i-hwspinlock.yaml
+F: drivers/hwspinlock/sun6i_hwspinlock.c
+
 ALLWINNER THERMAL DRIVER
 M: Vasily Khoruzhick 
 M: Yangtao Li 
diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
index 32cd26352f38..56ecc1aa3166 100644
--- a/drivers/hwspinlock/Kconfig
+++ b/drivers/hwspinlock/Kconfig
@@ -55,6 +55,15 @@ config HWSPINLOCK_STM32
 
  If unsure, say N.
 
+config HWSPINLOCK_SUN6I
+   tristate "SUN6I Hardware Spinlock device"
+   depends on ARCH_SUNXI || COMPILE_TEST
+   help
+ Say y here to support the SUN6I Hardware Spinlock device which can be
+ found in most of the sun6i compatible Allwinner SoCs.
+
+ If unsure, say N.
+
 config HSEM_U8500
tristate "STE Hardware Semaphore functionality"
depends on ARCH_U8500 || COMPILE_TEST
diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
index ed053e3f02be..83ec4f03decc 100644
--- a/drivers/hwspinlock/Makefile
+++ b/drivers/hwspinlock/Makefile
@@ -9,4 +9,5 @@ obj-$(CONFIG_HWSPINLOCK_QCOM)   += qcom_hwspinlock.o
 obj-$(CONFIG_HWSPINLOCK_SIRF)  += sirf_hwspinlock.o
 obj-$(CONFIG_HWSPINLOCK_SPRD)  += sprd_hwspinlock.o
 obj-$(CONFIG_HWSPINLOCK_STM32) += stm32_hwspinlock.o
+obj-$(CONFIG_HWSPINLOCK_SUN6I) += sun6i_hwspinlock.o
 obj-$(CONFIG_HSEM_U8500)   += u8500_hsem.o
diff --git a/drivers/hwspinlock/sun6i_hwspinlock.c 
b/drivers/hwspinlock/sun6i_hwspinlock.c
new file mode 100644
index ..c2d314588046
--- /dev/null
+++ b/drivers/hwspinlock/sun6i_hwspinlock.c
@@ -0,0 +1,210 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * sun6i_hwspinlock.c - hardware spinlock driver for sun6i compatible 
Allwinner SoCs
+ * Copyright (C) 2020 Wilken Gottwalt 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "hwspinlock_internal.h"
+
+#define DRIVER_NAME"sun6i_hwspinlock"
+
+#define SPINLOCK_BASE_ID   0 /* there is only one hwspinlock device per 
SoC */
+#define SPINLOCK_SYSSTATUS_REG 0x
+#define SPINLOCK_LOCK_REGN  

[PATCH] iio:dac:max517: Use devm_iio_device_register()

[Mugilraj Dhavachelvan]

Use devm_iio_device_register() to avoid remove function and 
drop explicit call to iio_device_unregister().

Signed-off-by: Mugilraj Dhavachelvan 
---
 drivers/iio/dac/max517.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/iio/dac/max517.c b/drivers/iio/dac/max517.c
index 7e01838ef4d0..5f72f126162d 100644
--- a/drivers/iio/dac/max517.c
+++ b/drivers/iio/dac/max517.c
@@ -189,13 +189,7 @@ static int max517_probe(struct i2c_client *client,
data->vref_mv[chan] = platform_data->vref_mv[chan];
}
 
-   return iio_device_register(indio_dev);
-}
-
-static int max517_remove(struct i2c_client *client)
-{
-   iio_device_unregister(i2c_get_clientdata(client));
-   return 0;
+   return devm_iio_device_register(&client->dev, indio_dev);
 }
 
 static const struct i2c_device_id max517_id[] = {
@@ -214,7 +208,6 @@ static struct i2c_driver max517_driver = {
.pm = &max517_pm_ops,
},
.probe  = max517_probe,
-   .remove = max517_remove,
.id_table   = max517_id,
 };
 module_i2c_driver(max517_driver);
-- 
2.25.1

[linux-stable-rc CI] Test report for 5.4.106-rc1 /x86

[hulkrobot]

Kernel repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
Branch: linux-5.4.y
Arch: x86
Version: 5.4.106-rc1
Commit: 2bcbae06b8fb9030973ee996e1b8ed43f3bfd4ab
Compiler: gcc version 7.3.0 (GCC)

All testcases PASSED.

Testcase Result Summary:
total_num: 4693
succeed_num: 4693
failed_num: 0
timeout_num: 0

Tested-by: Hulk Robot 

Re: [PATCH V4] clk: imx: Fix reparenting of UARTs not associated with stdout

[Ahmad Fatoum]

On 13.03.21 16:16, Ahmad Fatoum wrote:
>> +/* i.MX boards use device trees now.  For build tests without CONFIG_OF, do 
>> nothing */
>> +#ifdef CONFIG_OF
>>  if (imx_keep_uart_clocks) {
>>  int i;
>>  
>> -imx_uart_clocks = clks;
>> -for (i = 0; imx_uart_clocks[i]; i++)
>> -clk_prepare_enable(*imx_uart_clocks[i]);
>> +imx_uart_clocks = kcalloc(clk_count, sizeof(struct clk *), 
>> GFP_KERNEL);
>> +
>> +if (!of_stdout)
>> +return;
> 
> Memory leak. Just do if (imx_keep_uart_clocks && of_stdout)

Please dismiss. I overlooked that you free it in a later initcall.

>>  static int __init imx_clk_disable_uart(void)
>>  {
>> -if (imx_keep_uart_clocks && imx_uart_clocks) {
>> +if (imx_keep_uart_clocks && imx_enabled_uart_clocks) {
>>  int i;
>>  
>> -for (i = 0; imx_uart_clocks[i]; i++)
>> -clk_disable_unprepare(*imx_uart_clocks[i]);
>> +for (i = 0; i < imx_enabled_uart_clocks; i++) {
>> +clk_disable_unprepare(imx_uart_clocks[i]);
>> +clk_put(imx_uart_clocks[i]);
>> +};
>> +kfree(imx_uart_clocks);
>>  }

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH net-next] mfd: Add Renesas Synchronization Management Unit (SMU) support

[Pavel Machek]

Hi!
On Sat 2021-03-13 11:42:27, min.li...@renesas.com wrote:
> From: Min Li 
> 
> Add support for ClockMatrix(TM) and 82P33xxx families of timing
> and synchronization devices. The access interface can be either
> SPI or I2C. Currently, it will create 2 types of MFD devices,
> which are to be used by the corresponding rsmu character device
> driver and the PTP hardware clock driver, respectively.


> @@ -2131,7 +2158,7 @@ config RAVE_SP_CORE
> device found on several devices in RAVE line of hardware.
>  
>  config SGI_MFD_IOC3
> - bool "SGI IOC3 core driver"
> + tristate "SGI IOC3 core driver"
>   depends on PCI && MIPS && 64BIT
>   select MFD_CORE
>   help

This probably should not be here.

BR,
Pavel

-- 
http://www.livejournal.com/~pavelmachek


signature.asc
Description: PGP signature

Re: [PATCH] net: mellanox: mlx5: fix error return code of mlx5e_stats_flower()

[Roi Dayan]

On 2021-03-12 12:47 AM, Saeed Mahameed wrote:

On Tue, 2021-03-09 at 11:44 +0200, Roi Dayan wrote:



On 2021-03-09 10:32 AM, Jia-Ju Bai wrote:



On 2021/3/9 16:24, Roi Dayan wrote:



On 2021-03-09 10:20 AM, Roi Dayan wrote:



On 2021-03-06 3:47 PM, Jia-Ju Bai wrote:

When mlx5e_tc_get_counter() returns NULL to counter or
mlx5_devcom_get_peer_data() returns NULL to peer_esw, no
error return
code of mlx5e_stats_flower() is assigned.
To fix this bug, err is assigned with -EINVAL in these cases.

Reported-by: TOTE Robot 


Hey Jia-Ju, What are the conditions for this robot to raise a flag?
sometimes it is totally normal to abort a function and return 0.. i am
just curious to know ?



Signed-off-by: Jia-Ju Bai 
---
   drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 12
+---
   1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 0da69b98f38f..1f2c9da7bd35 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -4380,8 +4380,10 @@ int mlx5e_stats_flower(struct
net_device
*dev, struct mlx5e_priv *priv,
   if (mlx5e_is_offloaded_flow(flow) ||
flow_flag_test(flow, CT)) {
   counter = mlx5e_tc_get_counter(flow);
-    if (!counter)
+    if (!counter) {
+    err = -EINVAL;
   goto errout;
+    }
   mlx5_fc_query_cached(counter, &bytes, &packets,
&lastuse);
   }
@@ -4390,8 +4392,10 @@ int mlx5e_stats_flower(struct
net_device
*dev, struct mlx5e_priv *priv,
    * un-offloaded while the other rule is offloaded.
    */
   peer_esw = mlx5_devcom_get_peer_data(devcom,
MLX5_DEVCOM_ESW_OFFLOADS);
-    if (!peer_esw)
+    if (!peer_esw) {
+    err = -EINVAL;




This is not an error flow, i am curious what are the thresholds of this
robot ?


note here it's not an error. it could be there is no peer esw
so just continue with the stats update.


   goto out;
+    }
   if (flow_flag_test(flow, DUP) &&
   flow_flag_test(flow->peer_flow, OFFLOADED)) {
@@ -4400,8 +4404,10 @@ int mlx5e_stats_flower(struct
net_device
*dev, struct mlx5e_priv *priv,
   u64 lastuse2;
   counter = mlx5e_tc_get_counter(flow->peer_flow);
-    if (!counter)
+    if (!counter) {
+    err = -EINVAL;


this change is problematic. the current goto is to do stats
update with
the first counter stats we got but if you now want to return an
error
then you probably should not do any update at all.


Thanks for your reply :)
I am not sure whether an error code should be returned here?
If so, flow_stats_update(...) should not be called here?


Best wishes,
Jia-Ju Bai



basically flow and peer_flow should be valid and protected from
changes,
and counter should be valid.
it looks like the check here is more of a sanity check if something
goes
wrong but shouldn't. you can just let it be, update the stats from
the
first queried counter.



Roi, let's consider returning an error code here, we shouldn't be
silently returning if we are not expecting these errors,

why would mlx5e_stats_flower() be called if stats are not offloaded ?

Thanks,
Saeed.




yes we can return an error if peer counter missing.
I just pointed out we should probably not call flow_stats_update() if
we do return an error.
the other option, as today, is updating the stats with first counter
stats and because of that we didn't return an error.

Re: [PATCH v2 1/5] thermal/drivers/core: Use a char pointer for the cooling device name

[Ido Schimmel]

On Fri, Mar 12, 2021 at 06:03:12PM +0100, Daniel Lezcano wrote:
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 996c038f83a4..9ef8090eb645 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -960,10 +960,7 @@ __thermal_cooling_device_register(struct device_node *np,
>  {
>   struct thermal_cooling_device *cdev;
>   struct thermal_zone_device *pos = NULL;
> - int result;
> -
> - if (type && strlen(type) >= THERMAL_NAME_LENGTH)
> - return ERR_PTR(-EINVAL);
> + int ret;
>  
>   if (!ops || !ops->get_max_state || !ops->get_cur_state ||
>   !ops->set_cur_state)
> @@ -973,14 +970,17 @@ __thermal_cooling_device_register(struct device_node 
> *np,
>   if (!cdev)
>   return ERR_PTR(-ENOMEM);
>  
> - result = ida_simple_get(&thermal_cdev_ida, 0, 0, GFP_KERNEL);
> - if (result < 0) {
> - kfree(cdev);
> - return ERR_PTR(result);
> + ret = ida_simple_get(&thermal_cdev_ida, 0, 0, GFP_KERNEL);
> + if (ret < 0)
> + goto out_kfree_cdev;
> + cdev->id = ret;
> +
> + cdev->type = kstrdup(type ? type : "", GFP_KERNEL);
> + if (!cdev->type) {
> + ret = -ENOMEM;
> + goto out_ida_remove;
>   }
>  
> - cdev->id = result;
> - strlcpy(cdev->type, type ? : "", sizeof(cdev->type));
>   mutex_init(&cdev->lock);
>   INIT_LIST_HEAD(&cdev->thermal_instances);
>   cdev->np = np;
> @@ -990,12 +990,9 @@ __thermal_cooling_device_register(struct device_node *np,
>   cdev->devdata = devdata;
>   thermal_cooling_device_setup_sysfs(cdev);
>   dev_set_name(&cdev->device, "cooling_device%d", cdev->id);
> - result = device_register(&cdev->device);
> - if (result) {
> - ida_simple_remove(&thermal_cdev_ida, cdev->id);
> - put_device(&cdev->device);
> - return ERR_PTR(result);
> - }
> + ret = device_register(&cdev->device);
> + if (ret)
> + goto out_kfree_type;
>  
>   /* Add 'this' new cdev to the global cdev list */
>   mutex_lock(&thermal_list_lock);
> @@ -1013,6 +1010,14 @@ __thermal_cooling_device_register(struct device_node 
> *np,
>   mutex_unlock(&thermal_list_lock);
>  
>   return cdev;
> +
> +out_kfree_type:
> + kfree(cdev->type);
> + put_device(&cdev->device);
> +out_ida_remove:
> + ida_simple_remove(&thermal_cdev_ida, cdev->id);
> +out_kfree_cdev:
> + return ERR_PTR(ret);
>  }
>  
>  /**
> @@ -1172,6 +1177,7 @@ void thermal_cooling_device_unregister(struct 
> thermal_cooling_device *cdev)
>   device_del(&cdev->device);
>   thermal_cooling_device_destroy_sysfs(cdev);
>   put_device(&cdev->device);
> + kfree(cdev->type);
>  }
>  EXPORT_SYMBOL_GPL(thermal_cooling_device_unregister);

I'm getting the following user-after-free with this patch [1]. Fixed by:

diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 9ef8090eb645..c8d4010940ef 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -1176,8 +1176,8 @@ void thermal_cooling_device_unregister(struct 
thermal_cooling_device *cdev)
ida_simple_remove(&thermal_cdev_ida, cdev->id);
device_del(&cdev->device);
thermal_cooling_device_destroy_sysfs(cdev);
-   put_device(&cdev->device);
kfree(cdev->type);
+   put_device(&cdev->device);
 }
 EXPORT_SYMBOL_GPL(thermal_cooling_device_unregister);

[1]
[  148.601815] 
==
[  148.610260] BUG: KASAN: use-after-free in 
thermal_cooling_device_unregister+0x6ca/0x6e0
[  148.619304] Read of size 8 at addr 8881510a0808 by task devlink/574
[  148.626768]
[  148.628477] CPU: 2 PID: 574 Comm: devlink Not tainted 
5.12.0-rc2-custom-12525-g7ba8a2feee15 #3301
[  148.638463] Hardware name: Mellanox Technologies Ltd. 
MSN2100-CB2FO/SA001017, BIOS 5.6.5 06/07/2016
[  148.648625] Call Trace:
[  148.651408]  dump_stack+0xfa/0x151
[  148.661701]  print_address_description.constprop.0+0x18/0x130
[  148.681014]  kasan_report.cold+0x7f/0x111
[  148.692003]  thermal_cooling_device_unregister+0x6ca/0x6e0
[  148.703984]  mlxsw_thermal_fini+0xd2/0x1f0
[  148.708664]  mlxsw_core_bus_device_unregister+0x158/0x8d0
[  148.714794]  mlxsw_devlink_core_bus_device_reload_down+0x93/0xc0
[  148.721594]  devlink_reload+0x15f/0x5e0
[  148.749669]  devlink_nl_cmd_reload+0x7fc/0x1210
[  148.775992]  genl_family_rcv_msg_doit+0x22a/0x320
[  148.799789]  genl_rcv_msg+0x341/0x5a0
[  148.818789]  netlink_rcv_skb+0x14d/0x430
[  148.836450]  genl_rcv+0x29/0x40
[  148.840034]  netlink_unicast+0x539/0x7e0
[  148.859219]  netlink_sendmsg+0x8d7/0xe10
[  148.879271]  __sys_sendto+0x23f/0x350
[  148.904178]  __x64_sys_sendto+0xe2/0x1b0
[  148.919297]  do_syscall_64+0x2d/0x40
[  148.923365]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[  148.929081] RIP: 0033:0x7f17c0dbaefa
[  1

Re: [PATCH] powerpc/syscall: Force inlining of __prep_irq_for_enabled_exit()

[Michael Ellerman]

On Wed, 24 Feb 2021 06:34:22 + (UTC), Christophe Leroy wrote:
> As reported by kernel test robot, a randconfig with high amount of
> debuging options can lead to build failure for undefined reference
> to replay_soft_interrupts() on ppc32.
> 
> This is due to gcc not seeing that __prep_irq_for_enabled_exit()
> always returns true on ppc32 because it doesn't inline it for
> some reason.
> 
> [...]

Applied to powerpc/fixes.

[1/1] powerpc/syscall: Force inlining of __prep_irq_for_enabled_exit()
  https://git.kernel.org/powerpc/c/91b6c5dbe9e072dbdb181eed89c5c824e92ac0f5

cheers

Re: [PATCH] powerpc: Fix missing declaration of [en/dis]able_kernel_vsx()

[Michael Ellerman]

On Tue, 9 Mar 2021 08:39:39 + (UTC), Christophe Leroy wrote:
> Add stub instances of enable_kernel_vsx() and disable_kernel_vsx()
> when CONFIG_VSX is not set, to avoid following build failure.
> 
>   CC [M]  drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o
> In file included from 
> ./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:29,
>  from 
> ./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:37,
>  from 
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:27:
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c: In function 
> 'dcn_bw_apply_registry_override':
> ./drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:64:3: error: implicit 
> declaration of function 'enable_kernel_vsx'; did you mean 'enable_kernel_fp'? 
> [-Werror=implicit-function-declaration]
>64 |   enable_kernel_vsx(); \
>   |   ^
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:640:2: note: in 
> expansion of macro 'DC_FP_START'
>   640 |  DC_FP_START();
>   |  ^~~
> ./drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:75:3: error: implicit 
> declaration of function 'disable_kernel_vsx'; did you mean 
> 'disable_kernel_fp'? [-Werror=implicit-function-declaration]
>75 |   disable_kernel_vsx(); \
>   |   ^~
> drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:676:2: note: in 
> expansion of macro 'DC_FP_END'
>   676 |  DC_FP_END();
>   |  ^
> cc1: some warnings being treated as errors
> make[5]: *** [drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o] 
> Error 1

Applied to powerpc/fixes.

[1/1] powerpc: Fix missing declaration of [en/dis]able_kernel_vsx()
  https://git.kernel.org/powerpc/c/bd73758803c2eedc037c2268b65a19542a832594

cheers

Re: [PATCH] powerpc/603: Fix protection of user pages mapped with PROT_NONE

[Michael Ellerman]

On Mon, 1 Feb 2021 06:29:50 + (UTC), Christophe Leroy wrote:
> On book3s/32, page protection is defined by the PP bits in the PTE
> which provide the following protection depending on the access
> keys defined in the matching segment register:
> - PP 00 means RW with key 0 and N/A with key 1.
> - PP 01 means RW with key 0 and RO with key 1.
> - PP 10 means RW with both key 0 and key 1.
> - PP 11 means RO with both key 0 and key 1.
> 
> [...]

Applied to powerpc/fixes.

[1/1] powerpc/603: Fix protection of user pages mapped with PROT_NONE
  https://git.kernel.org/powerpc/c/c119565a15a628efdfa51352f9f6c5186e506a1c

cheers

Re: [PATCH] powerpc: Force inlining of mmu_has_feature to fix build failure

[Michael Ellerman]

On Sat, 27 Feb 2021 16:30:48 + (UTC), Christophe Leroy wrote:
> The test robot has managed to generate a random config leading
> to following build failure:
> 
>   LD  .tmp_vmlinux.kallsyms1
> powerpc64-linux-ld: arch/powerpc/mm/pgtable.o: in function 
> `ptep_set_access_flags':
> pgtable.c:(.text.ptep_set_access_flags+0xf0): undefined reference to 
> `hash__flush_tlb_page'
> powerpc64-linux-ld: arch/powerpc/mm/book3s32/mmu.o: in function 
> `MMU_init_hw_patch':
> mmu.c:(.init.text+0x452): undefined reference to `patch__hash_page_A0'
> powerpc64-linux-ld: mmu.c:(.init.text+0x45e): undefined reference to 
> `patch__hash_page_A0'
> powerpc64-linux-ld: mmu.c:(.init.text+0x46a): undefined reference to 
> `patch__hash_page_A1'
> powerpc64-linux-ld: mmu.c:(.init.text+0x476): undefined reference to 
> `patch__hash_page_A1'
> powerpc64-linux-ld: mmu.c:(.init.text+0x482): undefined reference to 
> `patch__hash_page_A2'
> powerpc64-linux-ld: mmu.c:(.init.text+0x48e): undefined reference to 
> `patch__hash_page_A2'
> powerpc64-linux-ld: mmu.c:(.init.text+0x49e): undefined reference to 
> `patch__hash_page_B'
> powerpc64-linux-ld: mmu.c:(.init.text+0x4aa): undefined reference to 
> `patch__hash_page_B'
> powerpc64-linux-ld: mmu.c:(.init.text+0x4b6): undefined reference to 
> `patch__hash_page_C'
> powerpc64-linux-ld: mmu.c:(.init.text+0x4c2): undefined reference to 
> `patch__hash_page_C'
> powerpc64-linux-ld: mmu.c:(.init.text+0x4ce): undefined reference to 
> `patch__flush_hash_A0'
> powerpc64-linux-ld: mmu.c:(.init.text+0x4da): undefined reference to 
> `patch__flush_hash_A0'
> powerpc64-linux-ld: mmu.c:(.init.text+0x4e6): undefined reference to 
> `patch__flush_hash_A1'
> powerpc64-linux-ld: mmu.c:(.init.text+0x4f2): undefined reference to 
> `patch__flush_hash_A1'
> powerpc64-linux-ld: mmu.c:(.init.text+0x4fe): undefined reference to 
> `patch__flush_hash_A2'
> powerpc64-linux-ld: mmu.c:(.init.text+0x50a): undefined reference to 
> `patch__flush_hash_A2'
> powerpc64-linux-ld: mmu.c:(.init.text+0x522): undefined reference to 
> `patch__flush_hash_B'
> powerpc64-linux-ld: mmu.c:(.init.text+0x532): undefined reference to 
> `patch__flush_hash_B'
> powerpc64-linux-ld: arch/powerpc/mm/book3s32/mmu.o: in function 
> `update_mmu_cache':
> mmu.c:(.text.update_mmu_cache+0xa0): undefined reference to `add_hash_page'
> powerpc64-linux-ld: mm/memory.o: in function `zap_pte_range':
> memory.c:(.text.zap_pte_range+0x160): undefined reference to 
> `flush_hash_pages'
> powerpc64-linux-ld: mm/memory.o: in function `handle_pte_fault':
> memory.c:(.text.handle_pte_fault+0x180): undefined reference to 
> `hash__flush_tlb_page'
> 
> [...]

Applied to powerpc/fixes.

[1/1] powerpc: Force inlining of mmu_has_feature to fix build failure
  https://git.kernel.org/powerpc/c/acdad8fb4a1574323db88f98a38b630691574e16

cheers

Re: [PATCH v2 00/43] powerpc/32: Switch to interrupt entry/exit in C

[Michael Ellerman]

On Tue, 9 Mar 2021 12:09:25 + (UTC), Christophe Leroy wrote:
> This series aims at porting interrupt entry/exit in C on PPC32, using
> the work already merged for PPC64.
> 
> First two patches are a fix and an optimisation of unrecoverable_exception() 
> function.
> 
> Six following patches do minimal changes in 40x in order to be able to enable 
> MMU
> earlier in exception entry.
> 
> [...]

Patch 1 applied to powerpc/fixes.

[01/43] powerpc/traps: unrecoverable_exception() is not an interrupt handler

https://git.kernel.org/powerpc/c/0b736881c8f1a6cd912f7a9162b9e097b28c1c30

cheers

Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl

[Dmitry Vyukov]

On Wed, Mar 10, 2021 at 7:53 PM Dmitry Vyukov  wrote:
>
> On Wed, Mar 10, 2021 at 7:28 PM syzbot
>  wrote:
> >
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit:0d7588ab riscv: process: Fix no prototype for arch_dup_tas..
> > git tree:   
> > git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes
> > console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad0
> > kernel config:  https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136
> > dashboard link: https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849
> > userspace arch: riscv64
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+c23c5421600e9b454...@syzkaller.appspotmail.com
>
> +riscv maintainers
>
> Another case of put_user crashing.

There are 58 crashes in sock_ioctl already. Somehow there is a very
significant skew towards crashing with this "user memory without
uaccess routines" in schedule_tail and sock_ioctl of all places in the
kernel that use put_user... This looks very strange... Any ideas
what's special about these 2 locations?


> > Unable to handle kernel access to user memory without uaccess routines at 
> > virtual address 2300
> > Oops [#1]
> > Modules linked in:
> > CPU: 1 PID: 4488 Comm: syz-executor.0 Not tainted 
> > 5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0
> > Hardware name: riscv-virtio,qemu (DT)
> > epc : sock_ioctl+0x424/0x6ac net/socket.c:1124
> >  ra : sock_ioctl+0x424/0x6ac net/socket.c:1124
> > epc : ffe002aeeb3e ra : ffe002aeeb3e sp : ffe023867da0
> >  gp : ffe005d25378 tp : ffe007e116c0 t0 : 
> >  t1 : 0001 t2 : 003fb8035e44 s0 : ffe023867e30
> >  s1 : 0004 a0 :  a1 : 0007
> >  a2 : 1ffc00fc22d8 a3 : ffe003bc1d02 a4 : 
> >  a5 :  a6 : 00f0 a7 : ffe82eba
> >  s2 :  s3 : 8902 s4 : 2300
> >  s5 : ffe005d2b0d0 s6 : ffe010facfc0 s7 : ffe008e0
> >  s8 : 8903 s9 : ffe010fad080 s10: 
> >  s11: 0002 t3 : 982de389919f6300 t4 : ffc401175688
> >  t5 : ffc401175691 t6 : 0007
> > status: 0120 badaddr: 2300 cause: 000f
> > Call Trace:
> > [] sock_ioctl+0x424/0x6ac net/socket.c:1124
> > [] vfs_ioctl fs/ioctl.c:48 [inline]
> > [] __do_sys_ioctl fs/ioctl.c:753 [inline]
> > [] sys_ioctl+0x5c2/0xd56 fs/ioctl.c:739
> > [] ret_from_syscall+0x0/0x2
> > Dumping ftrace buffer:
> >(ftrace buffer empty)
> > ---[ end trace a5f91e70f37b907b ]---
> >
> >
> > ---
> > This report is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkal...@googlegroups.com.
> >
> > syzbot will keep track of this issue. See:
> > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

[PATCH] backlight: qcom-wled: Use sink_addr for sync toggle

[Marijn Suijten]

From: Obeida Shamoun 

WLED3_SINK_REG_SYNC is, as the name implies, a sink register offset.
Therefore, use the sink address as base instead of the ctrl address.

This fixes the sync toggle on wled4, which can be observed by the fact
that adjusting brightness now works.

It has no effect on wled3 because sink and ctrl base addresses are the
same.  This allows adjusting the brightness without having to disable
then reenable the module.

Signed-off-by: Obeida Shamoun 
Signed-off-by: Konrad Dybcio 
Signed-off-by: Marijn Suijten 
---
 drivers/video/backlight/qcom-wled.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/qcom-wled.c 
b/drivers/video/backlight/qcom-wled.c
index 091f07e7c145..fc8b443d10fd 100644
--- a/drivers/video/backlight/qcom-wled.c
+++ b/drivers/video/backlight/qcom-wled.c
@@ -336,13 +336,13 @@ static int wled3_sync_toggle(struct wled *wled)
unsigned int mask = GENMASK(wled->max_string_count - 1, 0);
 
rc = regmap_update_bits(wled->regmap,
-   wled->ctrl_addr + WLED3_SINK_REG_SYNC,
+   wled->sink_addr + WLED3_SINK_REG_SYNC,
mask, mask);
if (rc < 0)
return rc;
 
rc = regmap_update_bits(wled->regmap,
-   wled->ctrl_addr + WLED3_SINK_REG_SYNC,
+   wled->sink_addr + WLED3_SINK_REG_SYNC,
mask, WLED3_SINK_REG_SYNC_CLEAR);
 
return rc;
-- 
2.30.2

[syzbot] KASAN: slab-out-of-bounds Read in riscv_intc_irq

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:0d7588ab riscv: process: Fix no prototype for arch_dup_tas..
git tree:   git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git 
fixes
console output: https://syzkaller.appspot.com/x/log.txt?x=15a35756d0
kernel config:  https://syzkaller.appspot.com/x/.config?x=81c0b708b31626cc
dashboard link: https://syzkaller.appspot.com/bug?extid=005654dd9b8f26bd4c07
userspace arch: riscv64

Unfortunately, I don't have any reproducer for this issue yet.

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

==
BUG: KASAN: slab-out-of-bounds in riscv_intc_irq+0x24/0xcc 
drivers/irqchip/irq-riscv-intc.c:24
Read of size 8 at addr ffe00c963bd0 by task kworker/1:1/4388

CPU: 1 PID: 4388 Comm: kworker/1:1 Not tainted 
5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0
Hardware name: riscv-virtio,qemu (DT)
Workqueue: events nsim_dev_trap_report_work
Call Trace:
[] walk_stackframe+0x0/0x23c arch/riscv/kernel/traps.c:201

Allocated by task 76347056:
(stack is not available)

Last potentially related work creation:


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

[GIT PULL] Please pull powerpc/linux.git powerpc-5.12-3 tag

[Michael Ellerman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Linus,

Please pull some more powerpc fixes for 5.12:

The following changes since commit fbda7904302499dd7ffc073a3c84eb7c9275db0a:

  Merge tag 'powerpc-5.12-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux (2021-03-07 
13:24:44 -0800)

are available in the git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git 
tags/powerpc-5.12-3

for you to fetch changes up to 0b736881c8f1a6cd912f7a9162b9e097b28c1c30:

  powerpc/traps: unrecoverable_exception() is not an interrupt handler 
(2021-03-12 11:02:12 +1100)

- --
powerpc fixes for 5.12 #3

Fix wrong instruction encoding for lis in ppc_function_entry(), which could
potentially lead to missed kprobes.

Fix SET_FULL_REGS on 32-bit and 64e, which prevented ptrace of non-volatile GPRs
immediately after exec.

Clean up a missed SRR specifier in the recent interrupt rework.

Don't treat unrecoverable_exception() as an interrupt handler, it's called from
other handlers so shouldn't do the interrupt entry/exit accounting itself.

Fix build errors caused by missing declaration of [en/dis]able_kernel_vsx().

Thanks to Christophe Leroy, Daniel Axtens, Geert Uytterhoeven, Jiri Olsa, Naveen
N. Rao, Nicholas Piggin.

- --
Christophe Leroy (2):
  powerpc: Fix missing declaration of [en/dis]able_kernel_vsx()
  powerpc/traps: unrecoverable_exception() is not an interrupt handler

Daniel Axtens (1):
  powerpc/64s/exception: Clean up a missed SRR specifier

Michael Ellerman (1):
  powerpc/64s: Use symbolic macros for function entry encoding

Naveen N. Rao (1):
  powerpc/64s: Fix instruction encoding for lis in ppc_function_entry()

Nicholas Piggin (1):
  powerpc: Fix inverted SET_FULL_REGS bitop


 arch/powerpc/include/asm/code-patching.h |  7 ---
 arch/powerpc/include/asm/interrupt.h |  3 ++-
 arch/powerpc/include/asm/ptrace.h|  4 ++--
 arch/powerpc/include/asm/switch_to.h | 10 ++
 arch/powerpc/kernel/exceptions-64s.S |  2 +-
 arch/powerpc/kernel/interrupt.c  |  1 -
 arch/powerpc/kernel/traps.c  |  2 +-
 7 files changed, 20 insertions(+), 9 deletions(-)
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmBN4hAACgkQUevqPMjh
pYADeQ//SfFd0biPa2ZroIqshVWDwY+CW+lHt0NIMiAcyaAS6VXOhgV27kFM4K72
bPgwQ4x4pa3ZoUiHD2Otp0EHYyFWPleY+8Jz9Sl6QBmySQ1ZllFppg92DiTP8RdF
ZItidFbP6+i8gvnoLkVyGCVzZky4x6Om34+r2emNr2Ju6SEw1ok/LFQUjxEmOGpV
+hCLXENPH76KP3dvLVklOtLJStFY7XFzuS0/c9yM33WgFVdYArGx/Wy6365Mg+wy
bg74oZmfU3IRpSNkErwkWSHTVLPQOq1wQUbFKXhMGvAp82C793ExSoGy/0EELlGW
fjgQMyNlGc0IhJAf6JeN18wgOwx5uBfbzEX5GTMu3A+WacQqod0kPeWx7FOZan6U
5ikNwyeg//dHUokbscfqvHhEL4Wp4REVO8d1smLQk7ycLpw4/6saYd9GC1HXE2r4
xJrPCYAtBn2lZl5ra6InO+zyac40fVP1oac7gJWaDkYmOmSQ1gghCjQpGfQGRO8H
fEnnfR5aqtgeYRnE53rb7BRTjgxsMXo4kLI2T2W10i3ezm/KmUhD9M3D0Ov/5nTv
DoqTZWhs6yEx2cgvIc4IBgUZb+R7QIbPa/zcq4DIBNsTUJRwbvDfK+8e/abnTGkR
/RfOqMA8z28h8UFR6tPojPgxG/0dp9WqGB7ryCWpdNCSiYrheIk=
=WdJ7
-END PGP SIGNATURE-

Re: [PATCH v2 net-next 0/6] skbuff: micro-optimize flow dissection

[Alexander Lobakin]

From: David Miller 
Date: Sat, 13 Mar 2021 18:10:00 -0800 (PST)

> None of these apply to net-next as per the patchwork automated checks.  Any 
> idea why?

No unfortunately. That'why I sent a follow-up mail. All of them
successfully apply to pure net-next on my machine.
Can it be a Git version conflict? I use 2.30.2, but also tried 2.30.1
and the latest development snapshot, and in either case they got
applied with no problems.

I could have more clue if NIPA provided more detailed log, but didn't
find any. And apply_patches stage doesn't seem to be present on NIPA
GitHub repo, so I couldn't reproduce it 1:1.

I can try again on Monday, not sure if it will help.
I also sent another series yesterday, and it has 15 green lights on
Patchwork, so this problem seems to take place only with this
particular series.

> Thanks.

Thanks,
Al

Re: [PATCH RFC] net: sched: implement TCQ_F_CAN_BYPASS for lockless qdisc

[Marc Kleine-Budde]

Cc += linux-...@vger.kernel.org

On 3/14/21 1:03 AM, Vladimir Oltean wrote:
> On Sat, Mar 13, 2021 at 10:47:47AM +0800, Yunsheng Lin wrote:
>> Currently pfifo_fast has both TCQ_F_CAN_BYPASS and TCQ_F_NOLOCK
>> flag set, but queue discipline by-pass does not work for lockless
>> qdisc because skb is always enqueued to qdisc even when the qdisc
>> is empty, see __dev_xmit_skb().
>>
>> This patch calles sch_direct_xmit() to transmit the skb directly
>> to the driver for empty lockless qdisc too, which aviod enqueuing
>> and dequeuing operation. qdisc->empty is set to false whenever a
>> skb is enqueued, and is set to true when skb dequeuing return NULL,
>> see pfifo_fast_dequeue().
>>
>> Also, qdisc is scheduled at the end of qdisc_run_end() when q->empty
>> is false to avoid packet stuck problem.
>>
>> The performance for ip_forward test increases about 10% with this
>> patch.
>>
>> Signed-off-by: Yunsheng Lin 
>> ---
> 
> I can confirm the ~10% IP forwarding throughput improvement brought by
> this patch, but as you might be aware, there was a previous attempt to
> add qdisc bypass to pfifo_fast by Paolo Abeni:
> https://lore.kernel.org/netdev/661cc33a-5f65-2769-cc1a-65791cb4b...@pengutronix.de/
> It was reverted because TX reordering was observed with SocketCAN
> (although, presumably it should also be seen with Ethernet and such).

Thanks for testing that, I just stumbled over this patch by accident.

Marc

-- 
Pengutronix e.K. | Marc Kleine-Budde   |
Embedded Linux   | https://www.pengutronix.de  |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917- |



signature.asc
Description: OpenPGP digital signature

Re: [PATCH v1 0/4] ALSA: hda/cirrus: Make CS8409 driver more generic by using fixups

[Vitaly Rodionov]

On 14/03/2021 8:36 am, Takashi Iwai wrote:

On Sat, 13 Mar 2021 12:34:06 +0100,
Vitaly Rodionov wrote:

This series of patches will address comments by Pierre-Louis Bossart,
cleans up patch_cirrus.c source, reducing checkpatch.pl warnings from 19 to 0,
fixing an issue reported by Canonical: BugLink: 
https://bugs.launchpad.net/bugs/1918378,
and makes the CS8409 patch more generic by using fixups.

Stefan Binding (4):
   ALSA: hda/cirrus: Add error handling into CS8409 I2C functions
   ALSA: hda/cirrus: Cleanup patch_cirrus.c code.
   ALSA: hda/cirrus: Fix CS42L42 Headset Mic volume control name
   ALSA: hda/cirrus: Make CS8409 driver more generic by using fixups.

Is this the same content as the series you've already submitted in
20210312184452.3288-1-vita...@opensource.cirrus.com ?


Hi Takashi,

Yes, this is second version of same series, where we have fixed warnings 
from 0-day bot.


Thanks,

Vitaly




thanks,

Takashi

[PATCH net] net: hdlc_x25: Prevent racing between "x25_close" and "x25_xmit"/"x25_rx"

[Xie He]

"x25_close" is called by "hdlc_close" in "hdlc.c", which is called by
hardware drivers' "ndo_stop" function.
"x25_xmit" is called by "hdlc_start_xmit" in "hdlc.c", which is hardware
drivers' "ndo_start_xmit" function.
"x25_rx" is called by "hdlc_rcv" in "hdlc.c", which receives HDLC frames
from "net/core/dev.c".

"x25_close" races with "x25_xmit" and "x25_rx" because their callers race.

However, we need to ensure that the LAPB APIs called in "x25_xmit" and
"x25_rx" are called before "lapb_unregister" is called in "x25_close".

This patch adds locking to ensure when "x25_xmit" and "x25_rx" are doing
their work, "lapb_unregister" is not yet called in "x25_close".

Reasons for not solving the racing between "x25_close" and "x25_xmit" by
calling "netif_tx_disable" in "x25_close":
1. We still need to solve the racing between "x25_close" and "x25_rx";
2. The design of the HDLC subsystem assumes the HDLC hardware drivers
have full control over the TX queue, and the HDLC protocol drivers (like
this driver) have no control. Controlling the queue here in the protocol
driver may interfere with hardware drivers' control of the queue.

Signed-off-by: Xie He 
---
 drivers/net/wan/hdlc_x25.c | 42 +-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wan/hdlc_x25.c b/drivers/net/wan/hdlc_x25.c
index 4aaa6388b9ee..5a6a945f6c81 100644
--- a/drivers/net/wan/hdlc_x25.c
+++ b/drivers/net/wan/hdlc_x25.c
@@ -23,6 +23,8 @@
 
 struct x25_state {
x25_hdlc_proto settings;
+   bool up;
+   spinlock_t up_lock; /* Protects "up" */
 };
 
 static int x25_ioctl(struct net_device *dev, struct ifreq *ifr);
@@ -104,6 +106,8 @@ static void x25_data_transmit(struct net_device *dev, 
struct sk_buff *skb)
 
 static netdev_tx_t x25_xmit(struct sk_buff *skb, struct net_device *dev)
 {
+   hdlc_device *hdlc = dev_to_hdlc(dev);
+   struct x25_state *x25st = state(hdlc);
int result;
 
/* There should be a pseudo header of 1 byte added by upper layers.
@@ -114,11 +118,19 @@ static netdev_tx_t x25_xmit(struct sk_buff *skb, struct 
net_device *dev)
return NETDEV_TX_OK;
}
 
+   spin_lock_bh(&x25st->up_lock);
+   if (!x25st->up) {
+   spin_unlock_bh(&x25st->up_lock);
+   kfree_skb(skb);
+   return NETDEV_TX_OK;
+   }
+
switch (skb->data[0]) {
case X25_IFACE_DATA:/* Data to be transmitted */
skb_pull(skb, 1);
if ((result = lapb_data_request(dev, skb)) != LAPB_OK)
dev_kfree_skb(skb);
+   spin_unlock_bh(&x25st->up_lock);
return NETDEV_TX_OK;
 
case X25_IFACE_CONNECT:
@@ -147,6 +159,7 @@ static netdev_tx_t x25_xmit(struct sk_buff *skb, struct 
net_device *dev)
break;
}
 
+   spin_unlock_bh(&x25st->up_lock);
dev_kfree_skb(skb);
return NETDEV_TX_OK;
 }
@@ -164,6 +177,7 @@ static int x25_open(struct net_device *dev)
.data_transmit = x25_data_transmit,
};
hdlc_device *hdlc = dev_to_hdlc(dev);
+   struct x25_state *x25st = state(hdlc);
struct lapb_parms_struct params;
int result;
 
@@ -190,6 +204,10 @@ static int x25_open(struct net_device *dev)
if (result != LAPB_OK)
return -EINVAL;
 
+   spin_lock_bh(&x25st->up_lock);
+   x25st->up = true;
+   spin_unlock_bh(&x25st->up_lock);
+
return 0;
 }
 
@@ -197,6 +215,13 @@ static int x25_open(struct net_device *dev)
 
 static void x25_close(struct net_device *dev)
 {
+   hdlc_device *hdlc = dev_to_hdlc(dev);
+   struct x25_state *x25st = state(hdlc);
+
+   spin_lock_bh(&x25st->up_lock);
+   x25st->up = false;
+   spin_unlock_bh(&x25st->up_lock);
+
lapb_unregister(dev);
 }
 
@@ -205,15 +230,28 @@ static void x25_close(struct net_device *dev)
 static int x25_rx(struct sk_buff *skb)
 {
struct net_device *dev = skb->dev;
+   hdlc_device *hdlc = dev_to_hdlc(dev);
+   struct x25_state *x25st = state(hdlc);
 
if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL) {
dev->stats.rx_dropped++;
return NET_RX_DROP;
}
 
-   if (lapb_data_received(dev, skb) == LAPB_OK)
+   spin_lock_bh(&x25st->up_lock);
+   if (!x25st->up) {
+   spin_unlock_bh(&x25st->up_lock);
+   kfree_skb(skb);
+   dev->stats.rx_dropped++;
+   return NET_RX_DROP;
+   }
+
+   if (lapb_data_received(dev, skb) == LAPB_OK) {
+   spin_unlock_bh(&x25st->up_lock);
return NET_RX_SUCCESS;
+   }
 
+   spin_unlock_bh(&x25st->up_lock);
dev->stats.rx_errors++;
dev_kfree_skb_any(skb);
return NET_RX_DROP;
@@ -298,6 +336,8 @@ static int x25_ioctl(struct net_device *dev, struct ifreq 
*ifr)
return result;
 
memcp

Panic after upgrading to 5.11.6 stable

[David R]

I attempted to upgrade my home server to 5.11 today. The system panics
soon after boot with the following :-



In iptables by the looks of the stack.

5.10.23 works fine.

Can provide config (and boot logs from 5.10.23) if required.

Cheers
David

Re: Panic after upgrading to 5.11.6 stable

[David R]

On 14/03/2021 10:30, David R wrote:
> I attempted to upgrade my home server to 5.11 today. The system panics
> soon after boot with the following :-
>
>
>
> In iptables by the looks of the stack.
>
> 5.10.23 works fine.
>
> Can provide config (and boot logs from 5.10.23) if required.
>
> Cheers
> David
Panic image attached

Re: [PATCH 2/3] net: ethernet: actions: Add Actions Semi Owl Ethernet MAC driver

[Cristian Ciocaltea]

On Sun, Mar 14, 2021 at 05:36:32AM +0100, Andrew Lunn wrote:
> > > > +   if (phy->interface != PHY_INTERFACE_MODE_RMII) {
> > > > +   netdev_err(netdev, "unsupported phy mode: %s\n",
> > > > +  phy_modes(phy->interface));
> > > > +   phy_disconnect(phy);
> > > > +   netdev->phydev = NULL;
> > > > +   return -EINVAL;
> > > > +   }
> > > 
> > > It looks like the MAC only supports symmetric pause. So you should
> > > call phy_set_sym_pause() to let the PHY know this.
> > 
> > I did not find any reference related to the supported pause types,
> > is this normally dependant on the PHY interface mode?
> 
> There is a MAC / PHY split there. The PHY is responsible for the
> negotiation for what each end can do. But it is the MAC which actually
> implements pause. The MAC needs to listen to pause frames and not send
> out data frames when the link peer indicates pause. And the MAC needs
> to send a pause frames when its receive buffers are full. The code you
> have in this MAC driver seems to indicate the MAC only supports
> symmetric pause. Hence you need to configure the PHY to only auto-neg
> symmetric pause.

Thanks for explaining this, I will implement the indicated PHY
configuration and, additionally, also enable the SMII interface.

> > > > +   ret = crypto_skcipher_encrypt(req);
> > > > +   if (ret) {
> > > > +   dev_err(dev, "failed to encrypt S/N: %d\n", ret);
> > > > +   goto err_free_tfm;
> > > > +   }
> > > > +
> > > > +   netdev->dev_addr[0] = 0xF4;
> > > > +   netdev->dev_addr[1] = 0x4E;
> > > > +   netdev->dev_addr[2] = 0xFD;
> > > 
> > > 0xF4 has the locally administered bit 0. So this is a true OUI. Who
> > > does it belong to? Ah!
> > > 
> > > F4:4E:FD Actions Semiconductor Co.,Ltd.(Cayman Islands)
> > > 
> > > Which makes sense. But is there any sort of agreement this is allowed?
> > > It is going to cause problems if they are giving out these MAC
> > > addresses in a controlled way.
> > 
> > Unfortunately this is another undocumented logic taken from the vendor
> > code. I have already disabled it from being built by default, although,
> > personally, I prefer to have it enabled in order to get a stable MAC
> > address instead of using a randomly generated one or manually providing
> > it via DT.
> > 
> > Just for clarification, I did not have any agreement or preliminary
> > discussion with the vendor. This is just a personal initiative to
> > improve the Owl SoC support in the mainline kernel.
> > 
> > > Maybe it would be better to set bit 1 of byte 0? And then you can use
> > > 5 bytes from enc_sn, not just 4.
> > 
> > I included the MAC generation feature in the driver to be fully
> > compatible with the original implementation, but I'm open for changes
> > if it raises concerns and compatibility is less important.
> 
> This is not a simple question to answer. If the vendor driver does
> this, then the vendor can never assign MAC addresses in a controlled
> way, unless they have a good idea how the algorithm turns serial
> numbers into MAC addresses, and they can avoid MAC addresses for
> serial numbers already issued.
> 
> But should the Linux kernel do the same? If all you want is a stable
> MAC address, my personal preference would be to set the locally
> administered bit, and fill the other 5 bytes from the hash
> algorithm. You then have a stable MAC addresses, but you clearly
> indicate it is not guaranteed to by globally unique, and you do not
> need to worry about what the vendor is doing.

I fully agree, so I'm going to set byte 0 to value 0xF6 and replace
bytes 1 & 2 with entries from the computed hash. I will also document
this modification and the rationale behind.

> > > Otherwise, this look a new clean driver.
> > 
> > Well, I tried to do my best, given my limited experience as a self-taught
> > kernel developer. Hopefully reviewing my code will not cause too many
> > headaches! :)
> 
> This is actually above average for a self-taught kernel
> developer. Well done.

Thank you, Andrew!

>  Andrew

Re: [PATCH 1/1] media: i2c: Add support for ov5693 sensor

[Jacopo Mondi]

Hi Daniel,

On Fri, Mar 12, 2021 at 10:32:39AM +, Daniel Scally wrote:
> The OV5693 is a 5 Mpx CMOS image sensor, connected via MIPI CSI-2. The
> chip is capable of a single lane configuration, but currently only two
> lanes are supported.
>
> Most of the sensor's features are supported, with the main exception
> being the lens correction algorithm.
>
> The driver provides all mandatory, optional and recommended V4L2 controls
> for maximum compatibility with libcamera.
>
> Signed-off-by: Daniel Scally 
> ---
>  MAINTAINERS|7 +
>  drivers/media/i2c/Kconfig  |   11 +
>  drivers/media/i2c/Makefile |1 +
>  drivers/media/i2c/ov5693.c | 1585 
>  4 files changed, 1604 insertions(+)
>  create mode 100644 drivers/media/i2c/ov5693.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cf44b3e77b90..34311d55b189 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -13140,6 +13140,13 @@ S:   Maintained
>  T:   git git://linuxtv.org/media_tree.git
>  F:   drivers/media/i2c/ov5675.c
>
> +OMNIVISION OV5693 SENSOR DRIVER
> +M:   Daniel Scally 
> +L:   linux-me...@vger.kernel.org
> +S:   Maintained
> +T:   git git://linuxtv.org/media_tree.git
> +F:   drivers/media/i2c/ov5693.c
> +
>  OMNIVISION OV5695 SENSOR DRIVER
>  M:   Shunqian Zheng 
>  L:   linux-me...@vger.kernel.org
> diff --git a/drivers/media/i2c/Kconfig b/drivers/media/i2c/Kconfig
> index 4c1ae687ab10..4da2278ec84c 100644
> --- a/drivers/media/i2c/Kconfig
> +++ b/drivers/media/i2c/Kconfig
> @@ -985,6 +985,17 @@ config VIDEO_OV5675
> To compile this driver as a module, choose M here: the
> module will be called ov5675.
>
> +config VIDEO_OV5693
> + tristate "OmniVision OV5693 sensor support"
> + depends on I2C && VIDEO_V4L2
> + select V4L2_FWNODE
> + help
> +   This is a Video4Linux2 sensor driver for the OmniVision
> +   OV5693 camera.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called ov5693.
> +
>  config VIDEO_OV5695
>   tristate "OmniVision OV5695 sensor support"
>   depends on I2C && VIDEO_V4L2
> diff --git a/drivers/media/i2c/Makefile b/drivers/media/i2c/Makefile
> index 65cfc94d25b6..7df680e110c9 100644
> --- a/drivers/media/i2c/Makefile
> +++ b/drivers/media/i2c/Makefile
> @@ -75,6 +75,7 @@ obj-$(CONFIG_VIDEO_OV5647) += ov5647.o
>  obj-$(CONFIG_VIDEO_OV5648) += ov5648.o
>  obj-$(CONFIG_VIDEO_OV5670) += ov5670.o
>  obj-$(CONFIG_VIDEO_OV5675) += ov5675.o
> +obj-$(CONFIG_VIDEO_OV5693) += ov5693.o
>  obj-$(CONFIG_VIDEO_OV5695) += ov5695.o
>  obj-$(CONFIG_VIDEO_OV6650) += ov6650.o
>  obj-$(CONFIG_VIDEO_OV7251) += ov7251.o
> diff --git a/drivers/media/i2c/ov5693.c b/drivers/media/i2c/ov5693.c
> new file mode 100644
> index ..0460371164ea
> --- /dev/null
> +++ b/drivers/media/i2c/ov5693.c
> @@ -0,0 +1,1585 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2013 Intel Corporation. All Rights Reserved.
> + *
> + * Adapted from the atomisp-ov5693 driver, with contributions from:
> + *
> + * Daniel Scally
> + * Jean-Michel Hautbois
> + * Fabian Wuthrich
> + * Tsuchiya Yuto
> + * Jordan Hand
> + * Jake Day
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* System Control */
> +#define OV5693_SW_RESET_REG  0x0103
> +#define OV5693_SW_STREAM_REG 0x0100
> +#define OV5693_START_STREAMING   0x01
> +#define OV5693_STOP_STREAMING0x00
> +#define OV5693_SW_RESET  0x01
> +
> +#define OV5693_REG_CHIP_ID_H 0x300A
> +#define OV5693_REG_CHIP_ID_L 0x300B

Please use lower case letters in hex identifiers

> +/* Yes, this is right. The datasheet for the OV5693 gives its ID as 0x5690 */
> +#define OV5693_CHIP_ID   0x5690
> +
> +/* Exposure */
> +#define OV5693_EXPOSURE_L_CTRL_HH_REG0x3500
> +#define OV5693_EXPOSURE_L_CTRL_H_REG 0x3501
> +#define OV5693_EXPOSURE_L_CTRL_L_REG 0x3502
> +#define OV5693_EXPOSURE_S_CTRL_HH_REG0x3506
> +#define OV5693_EXPOSURE_S_CTRL_H_REG 0x3507
> +#define OV5693_EXPOSURE_S_CTRL_L_REG 0x3508
> +#define OV5693_EXPOSURE_CTRL_HH(v)   (((v) & GENMASK(14, 12)) >> 12)
> +#define OV5693_EXPOSURE_CTRL_H(v)(((v) & GENMASK(11, 4)) >> 4)
> +#define OV5693_EXPOSURE_CTRL_L(v)(((v) & GENMASK(3, 0)) << 4)
> +#define OV5693_INTEGRATION_TIME_MARGIN   8
> +#define OV5693_EXPOSURE_MIN  1
> +#define OV5693_EXPOSURE_STEP 1
> +
> +/* Analogue Gain */
> +#define OV5693_GAIN_CTRL_H_REG   0x350A
> +#define OV5693_GAIN_CTRL_H(v)(((v) >> 4) & 
> GENMASK(2, 0))
> +#define OV5693_GAIN_CTRL_L_REG   0x350B

Re: [syzbot] KASAN: slab-out-of-bounds Read in riscv_intc_irq

[Dmitry Vyukov]

On Sun, Mar 14, 2021 at 11:14 AM syzbot
 wrote:
>
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:0d7588ab riscv: process: Fix no prototype for arch_dup_tas..
> git tree:   git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git 
> fixes
> console output: https://syzkaller.appspot.com/x/log.txt?x=15a35756d0
> kernel config:  https://syzkaller.appspot.com/x/.config?x=81c0b708b31626cc
> dashboard link: https://syzkaller.appspot.com/bug?extid=005654dd9b8f26bd4c07
> userspace arch: riscv64
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+005654dd9b8f26bd4...@syzkaller.appspotmail.com
>
> ==
> BUG: KASAN: slab-out-of-bounds in riscv_intc_irq+0x24/0xcc 
> drivers/irqchip/irq-riscv-intc.c:24
> Read of size 8 at addr ffe00c963bd0 by task kworker/1:1/4388
>
> CPU: 1 PID: 4388 Comm: kworker/1:1 Not tainted 
> 5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0
> Hardware name: riscv-virtio,qemu (DT)
> Workqueue: events nsim_dev_trap_report_work
> Call Trace:
> [] walk_stackframe+0x0/0x23c arch/riscv/kernel/traps.c:201
>
> Allocated by task 76347056:
> (stack is not available)
>
> Last potentially related work creation:

There seems to be some issue with riscv stack unwinder.
This does not have stacks.
"BUG: unable to handle kernel access to user memory in schedule_tail"
does not have proper stacks:
https://syzkaller.appspot.com/bug?id=9de8c24d24004fd5e482555f5ad8314da2fb1cee

I also found 2 riscv reports in "KASAN: use-after-free Read in
idr_for_each (2)":
https://syzkaller.appspot.com/bug?id=7f84dfc3902878befc22e52eb5c7298d0ad70cf3

both don't have any stacks:

==
BUG: KASAN: use-after-free in radix_tree_next_slot
include/linux/radix-tree.h:422 [inline]
BUG: KASAN: use-after-free in idr_for_each+0xf4/0x160 lib/idr.c:202
Read of size 8 at addr ffe010c00878 by task syz-executor.1/4828

CPU: 0 PID: 4828 Comm: syz-executor.1 Not tainted
5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0
Hardware name: riscv-virtio,qemu (DT)
Call Trace:
[] walk_stackframe+0x0/0x23c arch/riscv/kernel/traps.c:201

Allocated by task 4828:
(stack is not available)

Freed by task 4473:
(stack is not available)


> ---
> This report is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkal...@googlegroups.com.
>
> syzbot will keep track of this issue. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Re: [PATCH v2 1/5] thermal/drivers/core: Use a char pointer for the cooling device name

[Daniel Lezcano]

Hi Ido,

On 14/03/2021 10:53, Ido Schimmel wrote:
> On Fri, Mar 12, 2021 at 06:03:12PM +0100, Daniel Lezcano wrote:
>> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
>> index 996c038f83a4..9ef8090eb645 100644
>> --- a/drivers/thermal/thermal_core.c
>> +++ b/drivers/thermal/thermal_core.c
>> @@ -960,10 +960,7 @@ __thermal_cooling_device_register(struct device_node 
>> *np,

[ ... ]

>>  /**
>> @@ -1172,6 +1177,7 @@ void thermal_cooling_device_unregister(struct 
>> thermal_cooling_device *cdev)
>>  device_del(&cdev->device);
>>  thermal_cooling_device_destroy_sysfs(cdev);
>>  put_device(&cdev->device);
>> +kfree(cdev->type);
>>  }
>>  EXPORT_SYMBOL_GPL(thermal_cooling_device_unregister);
> 
> I'm getting the following user-after-free with this patch [1]. Fixed by:
> 
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index 9ef8090eb645..c8d4010940ef 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -1176,8 +1176,8 @@ void thermal_cooling_device_unregister(struct 
> thermal_cooling_device *cdev)
> ida_simple_remove(&thermal_cdev_ida, cdev->id);
> device_del(&cdev->device);
> thermal_cooling_device_destroy_sysfs(cdev);
> -   put_device(&cdev->device);
> kfree(cdev->type);
> +   put_device(&cdev->device);

Indeed 'thermal_release' frees the cdev pointer and is called by
put_device, then kfree use the pointer right after.

Thanks for the fix

  -- Daniel




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

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH v2] ASoC: Intel: Skylake: skl-topology: fix -frame-larger-than

[Andy Shevchenko]

On Sun, Mar 14, 2021 at 10:08 AM Nick Desaulniers
 wrote:
>
> Fixes:
> sound/soc/intel/skylake/skl-topology.c:3613:13: warning: stack frame
> size of 1304 bytes in function 'skl_tplg_complete'
> [-Wframe-larger-than=]
>
> struct snd_ctl_elem_value is 1224 bytes in my configuration.
>
> Heap allocate it, then free it within the current frame.
>
> Signed-off-by: Nick Desaulniers 
> ---
> Changes V1 -> V2: rebased on mainline.
>
>  sound/soc/intel/skylake/skl-topology.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/sound/soc/intel/skylake/skl-topology.c 
> b/sound/soc/intel/skylake/skl-topology.c
> index b824086203b9..566d07b4b523 100644
> --- a/sound/soc/intel/skylake/skl-topology.c
> +++ b/sound/soc/intel/skylake/skl-topology.c
> @@ -3613,10 +3613,15 @@ static int skl_manifest_load(struct snd_soc_component 
> *cmpnt, int index,
>  static void skl_tplg_complete(struct snd_soc_component *component)
>  {
> struct snd_soc_dobj *dobj;
> -   struct snd_soc_acpi_mach *mach =
> -   dev_get_platdata(component->card->dev);
> +   struct snd_soc_acpi_mach *mach;
> +   struct snd_ctl_elem_value *val;
> int i;
>
> +   val = kzalloc(sizeof(*val), GFP_KERNEL);
> +   if (!val)
> +   return;
> +
> +   mach = dev_get_platdata(component->card->dev);
> list_for_each_entry(dobj, &component->dobj_list, list) {
> struct snd_kcontrol *kcontrol = dobj->control.kcontrol;
> struct soc_enum *se;
> @@ -3632,14 +3637,13 @@ static void skl_tplg_complete(struct 
> snd_soc_component *component)
> sprintf(chan_text, "c%d", mach->mach_params.dmic_num);
>
> for (i = 0; i < se->items; i++) {
> -   struct snd_ctl_elem_value val = {};


Shouldn't you use rather kmalloc() + memset(). Otherwise I don't see
how possible this won't be garbage on the second iteration of the
outer loop.

> -
> if (strstr(texts[i], chan_text)) {
> -   val.value.enumerated.item[0] = i;
> -   kcontrol->put(kcontrol, &val);
> +   val->value.enumerated.item[0] = i;
> +   kcontrol->put(kcontrol, val);
> }
> }
> }
> +   kfree(val);
>  }
>
>  static struct snd_soc_tplg_ops skl_tplg_ops  = {
>
> base-commit: 88fe49249c99de14e543c632a46248d85411ab9e
> --
> 2.25.1
>


-- 
With Best Regards,
Andy Shevchenko

Re: Panic after upgrading to 5.11.6 stable

[Pablo Neira Ayuso]

On Sun, Mar 14, 2021 at 10:30:55AM +, David R wrote:
> I attempted to upgrade my home server to 5.11 today. The system panics
> soon after boot with the following :-
> 
> In iptables by the looks of the stack.
> 
> 5.10.23 works fine.
> 
> Can provide config (and boot logs from 5.10.23) if required.

Please have a look at:

https://bugzilla.kernel.org/show_bug.cgi?id=211911

[PATCH] mfd: rn5t618: Do not cache various USB related registers

[Andreas Kemnade]

These register get reset to their OTP defaults after USB plugging.
And while at it, also add a missing register for detecting the
charger type.

Signed-off-by: Andreas Kemnade 
---
 drivers/mfd/rn5t618.c   | 3 +++
 include/linux/mfd/rn5t618.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/mfd/rn5t618.c b/drivers/mfd/rn5t618.c
index dc452df1f1bf..6ed04e6dbc78 100644
--- a/drivers/mfd/rn5t618.c
+++ b/drivers/mfd/rn5t618.c
@@ -45,8 +45,11 @@ static bool rn5t618_volatile_reg(struct device *dev, 
unsigned int reg)
case RN5T618_INTMON:
case RN5T618_RTC_CTRL1 ... RN5T618_RTC_CTRL2:
case RN5T618_RTC_SECONDS ... RN5T618_RTC_YEAR:
+   case RN5T618_CHGCTL1:
+   case RN5T618_REGISET1 ... RN5T618_REGISET2:
case RN5T618_CHGSTATE:
case RN5T618_CHGCTRL_IRR ... RN5T618_CHGERR_MONI:
+   case RN5T618_GCHGDET:
case RN5T618_CONTROL ... RN5T618_CC_AVEREG0:
return true;
default:
diff --git a/include/linux/mfd/rn5t618.h b/include/linux/mfd/rn5t618.h
index fba0df13d9a8..8aa0bda1af4f 100644
--- a/include/linux/mfd/rn5t618.h
+++ b/include/linux/mfd/rn5t618.h
@@ -188,6 +188,7 @@
 #define RN5T618_CHGOSCSCORESET30xd7
 #define RN5T618_CHGOSCFREQSET1 0xd8
 #define RN5T618_CHGOSCFREQSET2 0xd9
+#define RN5T618_GCHGDET0xda
 #define RN5T618_CONTROL0xe0
 #define RN5T618_SOC0xe1
 #define RN5T618_RE_CAP_H   0xe2
-- 
2.29.2

Re: [syzbot] BUG: unable to handle kernel access to user memory in sock_ioctl

[Dmitry Vyukov]

On Sun, Mar 14, 2021 at 11:01 AM Dmitry Vyukov  wrote:
> > On Wed, Mar 10, 2021 at 7:28 PM syzbot
> >  wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following issue on:
> > >
> > > HEAD commit:0d7588ab riscv: process: Fix no prototype for 
> > > arch_dup_tas..
> > > git tree:   
> > > git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git fixes
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=122c343ad0
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=e3c595255fb2d136
> > > dashboard link: 
> > > https://syzkaller.appspot.com/bug?extid=c23c5421600e9b454849
> > > userspace arch: riscv64
> > >
> > > Unfortunately, I don't have any reproducer for this issue yet.
> > >
> > > IMPORTANT: if you fix the issue, please add the following tag to the 
> > > commit:
> > > Reported-by: syzbot+c23c5421600e9b454...@syzkaller.appspotmail.com
> >
> > +riscv maintainers
> >
> > Another case of put_user crashing.
>
> There are 58 crashes in sock_ioctl already. Somehow there is a very
> significant skew towards crashing with this "user memory without
> uaccess routines" in schedule_tail and sock_ioctl of all places in the
> kernel that use put_user... This looks very strange... Any ideas
> what's special about these 2 locations?

I could imagine if such a crash happens after a previous stack
overflow and now task data structures are corrupted. But f_getown does
not look like a function that consumes way more than other kernel
syscalls...



> > > Unable to handle kernel access to user memory without uaccess routines at 
> > > virtual address 2300
> > > Oops [#1]
> > > Modules linked in:
> > > CPU: 1 PID: 4488 Comm: syz-executor.0 Not tainted 
> > > 5.12.0-rc2-syzkaller-00467-g0d7588ab9ef9 #0
> > > Hardware name: riscv-virtio,qemu (DT)
> > > epc : sock_ioctl+0x424/0x6ac net/socket.c:1124
> > >  ra : sock_ioctl+0x424/0x6ac net/socket.c:1124
> > > epc : ffe002aeeb3e ra : ffe002aeeb3e sp : ffe023867da0
> > >  gp : ffe005d25378 tp : ffe007e116c0 t0 : 
> > >  t1 : 0001 t2 : 003fb8035e44 s0 : ffe023867e30
> > >  s1 : 0004 a0 :  a1 : 0007
> > >  a2 : 1ffc00fc22d8 a3 : ffe003bc1d02 a4 : 
> > >  a5 :  a6 : 00f0 a7 : ffe82eba
> > >  s2 :  s3 : 8902 s4 : 2300
> > >  s5 : ffe005d2b0d0 s6 : ffe010facfc0 s7 : ffe008e0
> > >  s8 : 8903 s9 : ffe010fad080 s10: 
> > >  s11: 0002 t3 : 982de389919f6300 t4 : ffc401175688
> > >  t5 : ffc401175691 t6 : 0007
> > > status: 0120 badaddr: 2300 cause: 000f
> > > Call Trace:
> > > [] sock_ioctl+0x424/0x6ac net/socket.c:1124
> > > [] vfs_ioctl fs/ioctl.c:48 [inline]
> > > [] __do_sys_ioctl fs/ioctl.c:753 [inline]
> > > [] sys_ioctl+0x5c2/0xd56 fs/ioctl.c:739
> > > [] ret_from_syscall+0x0/0x2
> > > Dumping ftrace buffer:
> > >(ftrace buffer empty)
> > > ---[ end trace a5f91e70f37b907b ]---
> > >
> > >
> > > ---
> > > This report is generated by a bot. It may contain errors.
> > > See https://goo.gl/tpsmEJ for more information about syzbot.
> > > syzbot engineers can be reached at syzkal...@googlegroups.com.
> > >
> > > syzbot will keep track of this issue. See:
> > > https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

Re: Panic after upgrading to 5.11.6 stable

[David R]

On 14/03/2021 10:53, Pablo Neira Ayuso wrote:
> On Sun, Mar 14, 2021 at 10:30:55AM +, David R wrote:
>> I attempted to upgrade my home server to 5.11 today. The system panics
>> soon after boot with the following :-
>>
>> In iptables by the looks of the stack.
>>
>> 5.10.23 works fine.
>>
>> Can provide config (and boot logs from 5.10.23) if required.
> Please have a look at:
>
> https://bugzilla.kernel.org/show_bug.cgi?id=211911
Looks like I upgraded just before a fix is merged. Just my luck.

Thanks for replying anyway!

David

Re: [PATCH] clk: socfpga: fix iomem pointer cast on 64-bit

[Krzysztof Kozlowski]

On 13/03/2021 22:10, Stephen Boyd wrote:
> Quoting Krzysztof Kozlowski (2021-03-11 06:48:33)
>> Pointers should be cast to unsigned long instead of integer.  This fixes
>> warning when compile testing on ARM64:
>>
>>   drivers/clk/socfpga/clk-gate.c: In function ‘socfpga_clk_recalc_rate’:
>>   drivers/clk/socfpga/clk-gate.c:102:7: warning: cast from pointer to 
>> integer of different size [-Wpointer-to-int-cast]
>>
>> Signed-off-by: Krzysztof Kozlowski 
> 
> Any Fixes tag?

I'll add it.

> 
>> ---
>>  drivers/clk/socfpga/clk-gate.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c
>> index 43ecd507bf83..c876523d5d51 100644
>> --- a/drivers/clk/socfpga/clk-gate.c
>> +++ b/drivers/clk/socfpga/clk-gate.c
>> @@ -99,7 +99,7 @@ static unsigned long socfpga_clk_recalc_rate(struct clk_hw 
>> *hwclk,
>> val = readl(socfpgaclk->div_reg) >> socfpgaclk->shift;
>> val &= GENMASK(socfpgaclk->width - 1, 0);
>> /* Check for GPIO_DB_CLK by its offset */
>> -   if ((int) socfpgaclk->div_reg & SOCFPGA_GPIO_DB_CLK_OFFSET)
>> +   if ((unsigned long) socfpgaclk->div_reg & 
>> SOCFPGA_GPIO_DB_CLK_OFFSET)
> 
> Should it be uintptr_t casted instead?

Good point, thanks!

> his isn't a very great code
> pattern given the way we store information in the iomem pointer about
> which clk type it is and then have to cast the pointer and assume
> alignment. Would be nice to get rid of it but I understand.

Best regards,
Krzysztof

[PATCH v2] clk: socfpga: fix iomem pointer cast on 64-bit

[Krzysztof Kozlowski]

Pointers should be cast with uintptr_t instead of integer.  This fixes
warning when compile testing on ARM64:

  drivers/clk/socfpga/clk-gate.c: In function ‘socfpga_clk_recalc_rate’:
  drivers/clk/socfpga/clk-gate.c:102:7: warning: cast from pointer to integer 
of different size [-Wpointer-to-int-cast]

Fixes: b7cec13f082f ("clk: socfpga: Look for the GPIO_DB_CLK by its offset")
Signed-off-by: Krzysztof Kozlowski 
Acked-by: Dinh Nguyen 

---

Changes since v1:
1. Add Fixes and Ack.
2. Use uintptr_t (Stephen Boyd).
---
 drivers/clk/socfpga/clk-gate.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/socfpga/clk-gate.c b/drivers/clk/socfpga/clk-gate.c
index 43ecd507bf83..cf94a12459ea 100644
--- a/drivers/clk/socfpga/clk-gate.c
+++ b/drivers/clk/socfpga/clk-gate.c
@@ -99,7 +99,7 @@ static unsigned long socfpga_clk_recalc_rate(struct clk_hw 
*hwclk,
val = readl(socfpgaclk->div_reg) >> socfpgaclk->shift;
val &= GENMASK(socfpgaclk->width - 1, 0);
/* Check for GPIO_DB_CLK by its offset */
-   if ((int) socfpgaclk->div_reg & SOCFPGA_GPIO_DB_CLK_OFFSET)
+   if ((uintptr_t) socfpgaclk->div_reg & 
SOCFPGA_GPIO_DB_CLK_OFFSET)
div = val + 1;
else
div = (1 << val);
-- 
2.25.1

Re: [PATCH] iio:dac:max517: Use devm_iio_device_register()

[Alexandru Ardelean]

On Sun, Mar 14, 2021 at 11:34 AM Mugilraj Dhavachelvan
 wrote:
>
> Use devm_iio_device_register() to avoid remove function and
> drop explicit call to iio_device_unregister().
>
> Signed-off-by: Mugilraj Dhavachelvan 
> ---
>  drivers/iio/dac/max517.c | 9 +
>  1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/iio/dac/max517.c b/drivers/iio/dac/max517.c
> index 7e01838ef4d0..5f72f126162d 100644
> --- a/drivers/iio/dac/max517.c
> +++ b/drivers/iio/dac/max517.c
> @@ -189,13 +189,7 @@ static int max517_probe(struct i2c_client *client,
> data->vref_mv[chan] = platform_data->vref_mv[chan];
> }
>
> -   return iio_device_register(indio_dev);
> -}
> -

In this case you can also remove the line with
 i2c_set_clientdata(client, indio_dev);

A lot of times, when functions like i2c_get_clientdata() get removed,
the i2c_set_clientdata() function becomes useless.
i.e. it stores some data that will never be used in the lifetime of the driver.

It isn't always the case that you can do that; so, some care must be
taken to avoid special cases.
But in this case, you can remove the i2c_set_clientdata() call.


> -static int max517_remove(struct i2c_client *client)
> -{
> -   iio_device_unregister(i2c_get_clientdata(client));
> -   return 0;
> +   return devm_iio_device_register(&client->dev, indio_dev);
>  }
>
>  static const struct i2c_device_id max517_id[] = {
> @@ -214,7 +208,6 @@ static struct i2c_driver max517_driver = {
> .pm = &max517_pm_ops,
> },
> .probe  = max517_probe,
> -   .remove = max517_remove,
> .id_table   = max517_id,
>  };
>  module_i2c_driver(max517_driver);
> --
> 2.25.1
>

[syzbot] KASAN: use-after-free Read in disk_part_iter_next (2)

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit:280d542f Merge tag 'drm-fixes-2021-03-05' of git://anongit..
git tree:   upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15ade5aed0
kernel config:  https://syzkaller.appspot.com/x/.config?x=952047a9dbff6a6a
dashboard link: https://syzkaller.appspot.com/bug?extid=8fede7e30c7cee0de139

Unfortunately, I don't have any reproducer for this issue yet.

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

==
BUG: KASAN: use-after-free in bdev_nr_sectors include/linux/genhd.h:266 [inline]
BUG: KASAN: use-after-free in disk_part_iter_next+0x49d/0x530 block/genhd.c:207
Read of size 8 at addr 88804b0022e8 by task systemd-udevd/9804

CPU: 1 PID: 9804 Comm: systemd-udevd Not tainted 5.12.0-rc1-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
Call Trace:
 __dump_stack lib/dump_stack.c:79 [inline]
 dump_stack+0xfa/0x151 lib/dump_stack.c:120
 print_address_description.constprop.0.cold+0x5b/0x2c6 mm/kasan/report.c:232
 __kasan_report mm/kasan/report.c:399 [inline]
 kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416
 bdev_nr_sectors include/linux/genhd.h:266 [inline]
 disk_part_iter_next+0x49d/0x530 block/genhd.c:207
 blk_drop_partitions+0x10a/0x180 block/partitions/core.c:543
 bdev_disk_changed+0x238/0x430 fs/block_dev.c:1237
 __loop_clr_fd+0x7c7/0xff0 drivers/block/loop.c:1271
 lo_release+0x1ac/0x1f0 drivers/block/loop.c:1923
 __blkdev_put+0x54e/0x800 fs/block_dev.c:1579
 blkdev_put+0x92/0x580 fs/block_dev.c:1632
 blkdev_close+0x8c/0xb0 fs/block_dev.c:1640
 __fput+0x288/0x920 fs/file_table.c:280
 task_work_run+0xdd/0x1a0 kernel/task_work.c:140
 tracehook_notify_resume include/linux/tracehook.h:189 [inline]
 exit_to_user_mode_loop kernel/entry/common.c:174 [inline]
 exit_to_user_mode_prepare+0x249/0x250 kernel/entry/common.c:208
 __syscall_exit_to_user_mode_work kernel/entry/common.c:290 [inline]
 syscall_exit_to_user_mode+0x19/0x50 kernel/entry/common.c:301
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f8141652270
Code: 73 01 c3 48 8b 0d 38 7d 20 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 
00 00 83 3d 59 c1 20 00 00 75 10 b8 03 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 
c3 48 83 ec 08 e8 ee fb ff ff 48 89 04 24
RSP: 002b:7ffe05d67588 EFLAGS: 0246 ORIG_RAX: 0003
RAX:  RBX: 0007 RCX: 7f8141652270
RDX:  RSI:  RDI: 0007
RBP: 7f814250c710 R08: 55e767969790 R09: 55e767968300
R10: 7f814250c8c0 R11: 0246 R12: 
R13: 55e767979eb0 R14: 0003 R15: 000e

Allocated by task 9582:
 kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
 kasan_set_track mm/kasan/common.c:46 [inline]
 set_alloc_info mm/kasan/common.c:427 [inline]
 __kasan_slab_alloc+0x73/0x90 mm/kasan/common.c:460
 kasan_slab_alloc include/linux/kasan.h:223 [inline]
 slab_post_alloc_hook mm/slab.h:516 [inline]
 slab_alloc mm/slab.c:3325 [inline]
 kmem_cache_alloc+0x1c3/0x4f0 mm/slab.c:3502
 bdev_alloc_inode+0x18/0x80 fs/block_dev.c:786
 alloc_inode+0x61/0x230 fs/inode.c:234
 new_inode_pseudo fs/inode.c:928 [inline]
 new_inode+0x27/0x2f0 fs/inode.c:957
 bdev_alloc+0x20/0x2f0 fs/block_dev.c:876
 add_partition+0x1ab/0x8a0 block/partitions/core.c:348
 bdev_add_partition+0xb6/0x130 block/partitions/core.c:451
 blkpg_do_ioctl+0x2d0/0x340 block/ioctl.c:43
 blkpg_ioctl block/ioctl.c:60 [inline]
 blkdev_ioctl+0x577/0x6d0 block/ioctl.c:548
 block_ioctl+0xf9/0x140 fs/block_dev.c:1658
 vfs_ioctl fs/ioctl.c:48 [inline]
 __do_sys_ioctl fs/ioctl.c:753 [inline]
 __se_sys_ioctl fs/ioctl.c:739 [inline]
 __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xae

Freed by task 8676:
 kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
 kasan_set_track+0x1c/0x30 mm/kasan/common.c:46
 kasan_set_free_info+0x20/0x30 mm/kasan/generic.c:357
 kasan_slab_free mm/kasan/common.c:360 [inline]
 kasan_slab_free mm/kasan/common.c:325 [inline]
 __kasan_slab_free+0xc7/0x100 mm/kasan/common.c:367
 kasan_slab_free include/linux/kasan.h:199 [inline]
 __cache_free mm/slab.c:3440 [inline]
 kmem_cache_free+0x6f/0x1d0 mm/slab.c:3733
 i_callback+0x3f/0x70 fs/inode.c:223
 rcu_do_batch kernel/rcu/tree.c:2559 [inline]
 rcu_core+0x722/0x1280 kernel/rcu/tree.c:2794
 __do_softirq+0x29b/0x9f6 kernel/softirq.c:345

Last potentially related work creation:
 kasan_save_stack+0x1b/0x40 mm/kasan/common.c:38
 kasan_record_aux_stack+0xa4/0xd0 mm/kasan/generic.c:345
 __call_rcu kernel/rcu/tree.c:3039 [inline]
 call_rcu+0xb1/0x700 kernel/rcu/tree.c:3114
 destroy_inode+0x129/0x1b0 fs/inode.c:289
 iput_final fs/inode.c:1654 [inline]
 iput.part.0+0x57e/0x810 fs/inode.c:1680
 iput+0x58/0x70 fs/inode.c:167

[PATCH v3 net-next 2/6] skbuff: make __skb_header_pointer()'s data argument const

[Alexander Lobakin]

The function never modifies the input buffer, so 'data' argument
can be marked as const.
This implies one harmless cast-away.

Signed-off-by: Alexander Lobakin 
---
 include/linux/skbuff.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 483e89348f78..d6ea3dc3eddb 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3678,11 +3678,11 @@ __wsum skb_checksum(const struct sk_buff *skb, int 
offset, int len,
__wsum csum);

 static inline void * __must_check
-__skb_header_pointer(const struct sk_buff *skb, int offset,
-int len, void *data, int hlen, void *buffer)
+__skb_header_pointer(const struct sk_buff *skb, int offset, int len,
+const void *data, int hlen, void *buffer)
 {
if (hlen - offset >= len)
-   return data + offset;
+   return (void *)data + offset;

if (!skb ||
skb_copy_bits(skb, offset, buffer, len) < 0)
--
2.30.2

[PATCH v3 net-next 0/6] skbuff: micro-optimize flow dissection

[Alexander Lobakin]

This little number makes all of the flow dissection functions take
raw input data pointer as const (1-5) and shuffles the branches in
__skb_header_pointer() according to their hit probability.

The result is +20 Mbps per flow/core with one Flow Dissector pass
per packet. This affects RPS (with software hashing), drivers that
use eth_get_headlen() on their Rx path and so on.

>From v2 [1]:
 - reword some commit messages as a potential fix for NIPA;
 - no functional changes.

>From v1 [0]:
 - rebase on top of the latest net-next. This was super-weird, but
   I double-checked that the series applies with no conflicts, and
   then on Patchwork it didn't;
 - no other changes.

[0] https://lore.kernel.org/netdev/20210312194538.337504-1-aloba...@pm.me
[1] https://lore.kernel.org/netdev/20210313113645.5949-1-aloba...@pm.me

Alexander Lobakin (6):
  flow_dissector: constify bpf_flow_dissector's data pointers
  skbuff: make __skb_header_pointer()'s data argument const
  flow_dissector: constify raw input data argument
  linux/etherdevice.h: misc trailing whitespace cleanup
  ethernet: constify eth_get_headlen()'s data argument
  skbuff: micro-optimize {,__}skb_header_pointer()

 include/linux/etherdevice.h  |  4 ++--
 include/linux/skbuff.h   | 26 +++
 include/net/flow_dissector.h |  6 +++---
 net/core/flow_dissector.c| 41 +++-
 net/ethernet/eth.c   |  2 +-
 5 files changed, 40 insertions(+), 39 deletions(-)

--
2.30.2

[PATCH v3 net-next 1/6] flow_dissector: constify bpf_flow_dissector's data pointers

[Alexander Lobakin]

BPF Flow dissection programs are read-only and don't touch input
buffers.
Mark 'data' and 'data_end' in struct bpf_flow_dissector as const
in preparation for global input constifying.

Signed-off-by: Alexander Lobakin 
---
 include/net/flow_dissector.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h
index cc10b10dc3a1..bf00e71816ed 100644
--- a/include/net/flow_dissector.h
+++ b/include/net/flow_dissector.h
@@ -368,8 +368,8 @@ static inline void *skb_flow_dissector_target(struct 
flow_dissector *flow_dissec
 struct bpf_flow_dissector {
struct bpf_flow_keys*flow_keys;
const struct sk_buff*skb;
-   void*data;
-   void*data_end;
+   const void  *data;
+   const void  *data_end;
 };

 static inline void
--
2.30.2

[PATCH v3 net-next 3/6] flow_dissector: constify raw input data argument

[Alexander Lobakin]

Flow Dissector code never modifies the input buffer, neither skb nor
raw data.
Make 'data' argument const for all of the Flow dissector's functions.

Signed-off-by: Alexander Lobakin 
---
 include/linux/skbuff.h   | 15 ++---
 include/net/flow_dissector.h |  2 +-
 net/core/flow_dissector.c| 41 +++-
 3 files changed, 30 insertions(+), 28 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index d6ea3dc3eddb..46c61e127e9f 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1292,10 +1292,10 @@ __skb_set_sw_hash(struct sk_buff *skb, __u32 hash, bool 
is_l4)
 void __skb_get_hash(struct sk_buff *skb);
 u32 __skb_get_hash_symmetric(const struct sk_buff *skb);
 u32 skb_get_poff(const struct sk_buff *skb);
-u32 __skb_get_poff(const struct sk_buff *skb, void *data,
+u32 __skb_get_poff(const struct sk_buff *skb, const void *data,
   const struct flow_keys_basic *keys, int hlen);
 __be32 __skb_flow_get_ports(const struct sk_buff *skb, int thoff, u8 ip_proto,
-   void *data, int hlen_proto);
+   const void *data, int hlen_proto);

 static inline __be32 skb_flow_get_ports(const struct sk_buff *skb,
int thoff, u8 ip_proto)
@@ -1314,9 +1314,8 @@ bool bpf_flow_dissect(struct bpf_prog *prog, struct 
bpf_flow_dissector *ctx,
 bool __skb_flow_dissect(const struct net *net,
const struct sk_buff *skb,
struct flow_dissector *flow_dissector,
-   void *target_container,
-   void *data, __be16 proto, int nhoff, int hlen,
-   unsigned int flags);
+   void *target_container, const void *data,
+   __be16 proto, int nhoff, int hlen, unsigned int flags);

 static inline bool skb_flow_dissect(const struct sk_buff *skb,
struct flow_dissector *flow_dissector,
@@ -1338,9 +1337,9 @@ static inline bool skb_flow_dissect_flow_keys(const 
struct sk_buff *skb,
 static inline bool
 skb_flow_dissect_flow_keys_basic(const struct net *net,
 const struct sk_buff *skb,
-struct flow_keys_basic *flow, void *data,
-__be16 proto, int nhoff, int hlen,
-unsigned int flags)
+struct flow_keys_basic *flow,
+const void *data, __be16 proto,
+int nhoff, int hlen, unsigned int flags)
 {
memset(flow, 0, sizeof(*flow));
return __skb_flow_dissect(net, skb, &flow_keys_basic_dissector, flow,
diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h
index bf00e71816ed..ffd386ea0dbb 100644
--- a/include/net/flow_dissector.h
+++ b/include/net/flow_dissector.h
@@ -350,7 +350,7 @@ static inline bool flow_keys_have_l4(const struct flow_keys 
*keys)
 u32 flow_hash_from_keys(struct flow_keys *keys);
 void skb_flow_get_icmp_tci(const struct sk_buff *skb,
   struct flow_dissector_key_icmp *key_icmp,
-  void *data, int thoff, int hlen);
+  const void *data, int thoff, int hlen);

 static inline bool dissector_uses_key(const struct flow_dissector 
*flow_dissector,
  enum flow_dissector_key_id key_id)
diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
index 2ef2224b3bff..2ed380d096ce 100644
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -114,7 +114,7 @@ int flow_dissector_bpf_prog_attach_check(struct net *net,
  * is the protocol port offset returned from proto_ports_offset
  */
 __be32 __skb_flow_get_ports(const struct sk_buff *skb, int thoff, u8 ip_proto,
-   void *data, int hlen)
+   const void *data, int hlen)
 {
int poff = proto_ports_offset(ip_proto);

@@ -161,7 +161,7 @@ static bool icmp_has_id(u8 type)
  */
 void skb_flow_get_icmp_tci(const struct sk_buff *skb,
   struct flow_dissector_key_icmp *key_icmp,
-  void *data, int thoff, int hlen)
+  const void *data, int thoff, int hlen)
 {
struct icmphdr *ih, _ih;

@@ -187,8 +187,8 @@ EXPORT_SYMBOL(skb_flow_get_icmp_tci);
  */
 static void __skb_flow_dissect_icmp(const struct sk_buff *skb,
struct flow_dissector *flow_dissector,
-   void *target_container,
-   void *data, int thoff, int hlen)
+   void *target_container, const void *data,
+   int thoff, int hlen)
 {
struct flow_dissector_key_icmp *key_icmp;

@@ -409,8 +409,8 @@ EXPORT_SYMBOL(skb_flow_dissect_hash);
 stat

[PATCH v3 net-next 5/6] ethernet: constify eth_get_headlen()'s data argument

[Alexander Lobakin]

It's used only for flow dissection, which now takes constant data
pointers.

Signed-off-by: Alexander Lobakin 
---
 include/linux/etherdevice.h | 2 +-
 net/ethernet/eth.c  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index bcb2f81baafb..330345b1be54 100644
--- a/include/linux/etherdevice.h
+++ b/include/linux/etherdevice.h
@@ -29,7 +29,7 @@ struct device;
 int eth_platform_get_mac_address(struct device *dev, u8 *mac_addr);
 unsigned char *arch_get_platform_mac_address(void);
 int nvmem_get_mac_address(struct device *dev, void *addrbuf);
-u32 eth_get_headlen(const struct net_device *dev, void *data, unsigned int 
len);
+u32 eth_get_headlen(const struct net_device *dev, const void *data, u32 len);
 __be16 eth_type_trans(struct sk_buff *skb, struct net_device *dev);
 extern const struct header_ops eth_header_ops;

diff --git a/net/ethernet/eth.c b/net/ethernet/eth.c
index 4106373180c6..e01cf766d2c5 100644
--- a/net/ethernet/eth.c
+++ b/net/ethernet/eth.c
@@ -122,7 +122,7 @@ EXPORT_SYMBOL(eth_header);
  * Make a best effort attempt to pull the length for all of the headers for
  * a given frame in a linear buffer.
  */
-u32 eth_get_headlen(const struct net_device *dev, void *data, unsigned int len)
+u32 eth_get_headlen(const struct net_device *dev, const void *data, u32 len)
 {
const unsigned int flags = FLOW_DISSECTOR_F_PARSE_1ST_FRAG;
const struct ethhdr *eth = (const struct ethhdr *)data;
--
2.30.2

[PATCH v3 net-next 4/6] linux/etherdevice.h: misc trailing whitespace cleanup

[Alexander Lobakin]

Caught by the text editor. Fix it separately from the actual changes.

Signed-off-by: Alexander Lobakin 
---
 include/linux/etherdevice.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/etherdevice.h b/include/linux/etherdevice.h
index 2e5debc0373c..bcb2f81baafb 100644
--- a/include/linux/etherdevice.h
+++ b/include/linux/etherdevice.h
@@ -11,7 +11,7 @@
  * Authors:Ross Biro
  * Fred N. van Kempen, 
  *
- * Relocated to include/linux where it belongs by Alan Cox
+ * Relocated to include/linux where it belongs by Alan Cox
  * 
  */
 #ifndef _LINUX_ETHERDEVICE_H
--
2.30.2

[PATCH v3 net-next 6/6] skbuff: micro-optimize {,__}skb_header_pointer()

[Alexander Lobakin]

{,__}skb_header_pointer() helpers exist mainly for preventing
accesses-beyond-end of the linear data.
In the vast majorify of cases, they bail out on the first condition.
All code going after is mostly a fallback.
Mark the most common branch as 'likely' one to move it in-line.
Also, skb_copy_bits() can return negative values only when the input
arguments are invalid, e.g. offset is greater than skb->len. It can
be safely marked as 'unlikely' branch, assuming that hotpath code
provides sane input to not fail here.

These two bump the throughput with a single Flow Dissector pass on
every packet (e.g. with RPS or driver that uses eth_get_headlen())
on 20 Mbps per flow/core.

Signed-off-by: Alexander Lobakin 
---
 include/linux/skbuff.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 46c61e127e9f..ecc029674ae4 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3680,11 +3680,10 @@ static inline void * __must_check
 __skb_header_pointer(const struct sk_buff *skb, int offset, int len,
 const void *data, int hlen, void *buffer)
 {
-   if (hlen - offset >= len)
+   if (likely(hlen - offset >= len))
return (void *)data + offset;

-   if (!skb ||
-   skb_copy_bits(skb, offset, buffer, len) < 0)
+   if (!skb || unlikely(skb_copy_bits(skb, offset, buffer, len) < 0))
return NULL;

return buffer;
--
2.30.2

[PATCH v3 4/5] thermal/drivers/cpuidle_cooling: Use device name instead of auto-numbering

[Daniel Lezcano]

Currently the naming of a cooling device is just a cooling technique
followed by a number. When there are multiple cooling devices using
the same technique, it is impossible to clearly identify the related
device as this one is just a number.

For instance:

 thermal-idle-0
 thermal-idle-1
 thermal-idle-2
 thermal-idle-3
 etc ...

The 'thermal' prefix is redundant with the subsystem namespace. This
patch removes the 'thermal prefix and changes the number by the device
name. So the naming above becomes:

 idle-cpu0
 idle-cpu1
 idle-cpu2
 idle-cpu3
 etc ...

Signed-off-by: Daniel Lezcano 
Reviewed-by: Lukasz Luba 
---
V2:
  - Removed idr.h header
  - Used kasprintf instead of fixed buffer length on the stack
  - Fixed typo in the log
---
 drivers/thermal/cpuidle_cooling.c | 33 +++
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/drivers/thermal/cpuidle_cooling.c 
b/drivers/thermal/cpuidle_cooling.c
index 7ecab4b16b29..f32976163bad 100644
--- a/drivers/thermal/cpuidle_cooling.c
+++ b/drivers/thermal/cpuidle_cooling.c
@@ -9,9 +9,9 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -26,8 +26,6 @@ struct cpuidle_cooling_device {
unsigned long state;
 };
 
-static DEFINE_IDA(cpuidle_ida);
-
 /**
  * cpuidle_cooling_runtime - Running time computation
  * @idle_duration_us: CPU idle time to inject in microseconds
@@ -174,10 +172,11 @@ static int __cpuidle_cooling_register(struct device_node 
*np,
struct idle_inject_device *ii_dev;
struct cpuidle_cooling_device *idle_cdev;
struct thermal_cooling_device *cdev;
+   struct device *dev;
unsigned int idle_duration_us = TICK_USEC;
unsigned int latency_us = UINT_MAX;
-   char dev_name[THERMAL_NAME_LENGTH];
-   int id, ret;
+   char *name;
+   int ret;
 
idle_cdev = kzalloc(sizeof(*idle_cdev), GFP_KERNEL);
if (!idle_cdev) {
@@ -185,16 +184,10 @@ static int __cpuidle_cooling_register(struct device_node 
*np,
goto out;
}
 
-   id = ida_simple_get(&cpuidle_ida, 0, 0, GFP_KERNEL);
-   if (id < 0) {
-   ret = id;
-   goto out_kfree;
-   }
-
ii_dev = idle_inject_register(drv->cpumask);
if (!ii_dev) {
ret = -EINVAL;
-   goto out_id;
+   goto out_kfree;
}
 
of_property_read_u32(np, "duration-us", &idle_duration_us);
@@ -205,24 +198,30 @@ static int __cpuidle_cooling_register(struct device_node 
*np,
 
idle_cdev->ii_dev = ii_dev;
 
-   snprintf(dev_name, sizeof(dev_name), "thermal-idle-%d", id);
+   dev = get_cpu_device(cpumask_first(drv->cpumask));
 
-   cdev = thermal_of_cooling_device_register(np, dev_name, idle_cdev,
+   name = kasprintf(GFP_KERNEL, "idle-%s", dev_name(dev));
+   if (!name) {
+   ret = -ENOMEM;
+   goto out_unregister;
+   }
+
+   cdev = thermal_of_cooling_device_register(np, name, idle_cdev,
  &cpuidle_cooling_ops);
+   kfree(name);
+
if (IS_ERR(cdev)) {
ret = PTR_ERR(cdev);
goto out_unregister;
}
 
pr_debug("%s: Idle injection set with idle duration=%u, latency=%u\n",
-dev_name, idle_duration_us, latency_us);
+name, idle_duration_us, latency_us);
 
return 0;
 
 out_unregister:
idle_inject_unregister(ii_dev);
-out_id:
-   ida_simple_remove(&cpuidle_ida, id);
 out_kfree:
kfree(idle_cdev);
 out:
-- 
2.17.1

[PATCH v3 2/5] thermal/drivers/cpufreq_cooling: Use device name instead of auto-numbering

[Daniel Lezcano]

Currently the naming of a cooling device is just a cooling technique
followed by a number. When there are multiple cooling devices using
the same technique, it is impossible to clearly identify the related
device as this one is just a number.

For instance:

 thermal-cpufreq-0
 thermal-cpufreq-1
 etc ...

The 'thermal' prefix is redundant with the subsystem namespace. This
patch removes the 'thermal' prefix and changes the number by the device
name. So the naming above becomes:

 cpufreq-cpu0
 cpufreq-cpu4
 etc ...

Signed-off-by: Daniel Lezcano 
Acked-by: Viresh Kumar 
Reviewed-by: Lukasz Luba 
---
V2:
  - Use kasprintf() instead of fixed array length on the stack
  - Fixed typo in the log
  - Removed idr.h inclusion
---
 drivers/thermal/cpufreq_cooling.c | 34 +++
 1 file changed, 12 insertions(+), 22 deletions(-)

diff --git a/drivers/thermal/cpufreq_cooling.c 
b/drivers/thermal/cpufreq_cooling.c
index 10af3341e5ea..3f5f1dce1320 100644
--- a/drivers/thermal/cpufreq_cooling.c
+++ b/drivers/thermal/cpufreq_cooling.c
@@ -13,10 +13,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -50,8 +50,6 @@ struct time_in_idle {
 
 /**
  * struct cpufreq_cooling_device - data for cooling device with cpufreq
- * @id: unique integer value corresponding to each cpufreq_cooling_device
- * registered.
  * @last_load: load measured by the latest call to 
cpufreq_get_requested_power()
  * @cpufreq_state: integer value representing the current state of cpufreq
  * cooling devices.
@@ -69,7 +67,6 @@ struct time_in_idle {
  * cpufreq_cooling_device.
  */
 struct cpufreq_cooling_device {
-   int id;
u32 last_load;
unsigned int cpufreq_state;
unsigned int max_level;
@@ -82,7 +79,6 @@ struct cpufreq_cooling_device {
struct freq_qos_request qos_req;
 };
 
-static DEFINE_IDA(cpufreq_ida);
 static DEFINE_MUTEX(cooling_list_lock);
 static LIST_HEAD(cpufreq_cdev_list);
 
@@ -528,11 +524,11 @@ __cpufreq_cooling_register(struct device_node *np,
 {
struct thermal_cooling_device *cdev;
struct cpufreq_cooling_device *cpufreq_cdev;
-   char dev_name[THERMAL_NAME_LENGTH];
unsigned int i;
struct device *dev;
int ret;
struct thermal_cooling_device_ops *cooling_ops;
+   char *name;
 
dev = get_cpu_device(policy->cpu);
if (unlikely(!dev)) {
@@ -567,16 +563,6 @@ __cpufreq_cooling_register(struct device_node *np,
/* max_level is an index, not a counter */
cpufreq_cdev->max_level = i - 1;
 
-   ret = ida_simple_get(&cpufreq_ida, 0, 0, GFP_KERNEL);
-   if (ret < 0) {
-   cdev = ERR_PTR(ret);
-   goto free_idle_time;
-   }
-   cpufreq_cdev->id = ret;
-
-   snprintf(dev_name, sizeof(dev_name), "thermal-cpufreq-%d",
-cpufreq_cdev->id);
-
cooling_ops = &cpufreq_cooling_ops;
 
 #ifdef CONFIG_THERMAL_GOV_POWER_ALLOCATOR
@@ -591,7 +577,7 @@ __cpufreq_cooling_register(struct device_node *np,
pr_err("%s: unsorted frequency tables are not supported\n",
   __func__);
cdev = ERR_PTR(-EINVAL);
-   goto remove_ida;
+   goto free_idle_time;
}
 
ret = freq_qos_add_request(&policy->constraints,
@@ -601,11 +587,18 @@ __cpufreq_cooling_register(struct device_node *np,
pr_err("%s: Failed to add freq constraint (%d)\n", __func__,
   ret);
cdev = ERR_PTR(ret);
-   goto remove_ida;
+   goto free_idle_time;
}
 
-   cdev = thermal_of_cooling_device_register(np, dev_name, cpufreq_cdev,
+   cdev = ERR_PTR(-ENOMEM);
+   name = kasprintf(GFP_KERNEL, "cpufreq-%s", dev_name(dev));
+   if (!name)
+   goto remove_qos_req;
+
+   cdev = thermal_of_cooling_device_register(np, name, cpufreq_cdev,
  cooling_ops);
+   kfree(name);
+
if (IS_ERR(cdev))
goto remove_qos_req;
 
@@ -617,8 +610,6 @@ __cpufreq_cooling_register(struct device_node *np,
 
 remove_qos_req:
freq_qos_remove_request(&cpufreq_cdev->qos_req);
-remove_ida:
-   ida_simple_remove(&cpufreq_ida, cpufreq_cdev->id);
 free_idle_time:
free_idle_time(cpufreq_cdev);
 free_cdev:
@@ -712,7 +703,6 @@ void cpufreq_cooling_unregister(struct 
thermal_cooling_device *cdev)
 
thermal_cooling_device_unregister(cdev);
freq_qos_remove_request(&cpufreq_cdev->qos_req);
-   ida_simple_remove(&cpufreq_ida, cpufreq_cdev->id);
free_idle_time(cpufreq_cdev);
kfree(cpufreq_cdev);
 }
-- 
2.17.1

[PATCH v3 5/5] thermal/drivers/cpufreq_cooling: Remove unused list

[Daniel Lezcano]

There is a list with the purpose of grouping the cpufreq cooling
device together as described in the comments but actually it is
unused, the code evolved since 2012 and the list was no longer needed.

Delete the remaining unused list related code.

Signed-off-by: Daniel Lezcano 
Reviewed-by: Lukasz Luba 
---
 drivers/thermal/cpufreq_cooling.c | 13 -
 1 file changed, 13 deletions(-)

diff --git a/drivers/thermal/cpufreq_cooling.c 
b/drivers/thermal/cpufreq_cooling.c
index 3f5f1dce1320..f3d308427665 100644
--- a/drivers/thermal/cpufreq_cooling.c
+++ b/drivers/thermal/cpufreq_cooling.c
@@ -59,7 +59,6 @@ struct time_in_idle {
  * @cdev: thermal_cooling_device pointer to keep track of the
  * registered cooling device.
  * @policy: cpufreq policy.
- * @node: list_head to link all cpufreq_cooling_device together.
  * @idle_time: idle time stats
  * @qos_req: PM QoS contraint to apply
  *
@@ -72,16 +71,12 @@ struct cpufreq_cooling_device {
unsigned int max_level;
struct em_perf_domain *em;
struct cpufreq_policy *policy;
-   struct list_head node;
 #ifndef CONFIG_SMP
struct time_in_idle *idle_time;
 #endif
struct freq_qos_request qos_req;
 };
 
-static DEFINE_MUTEX(cooling_list_lock);
-static LIST_HEAD(cpufreq_cdev_list);
-
 #ifdef CONFIG_THERMAL_GOV_POWER_ALLOCATOR
 /**
  * get_level: Find the level for a particular frequency
@@ -602,10 +597,6 @@ __cpufreq_cooling_register(struct device_node *np,
if (IS_ERR(cdev))
goto remove_qos_req;
 
-   mutex_lock(&cooling_list_lock);
-   list_add(&cpufreq_cdev->node, &cpufreq_cdev_list);
-   mutex_unlock(&cooling_list_lock);
-
return cdev;
 
 remove_qos_req:
@@ -697,10 +688,6 @@ void cpufreq_cooling_unregister(struct 
thermal_cooling_device *cdev)
 
cpufreq_cdev = cdev->devdata;
 
-   mutex_lock(&cooling_list_lock);
-   list_del(&cpufreq_cdev->node);
-   mutex_unlock(&cooling_list_lock);
-
thermal_cooling_device_unregister(cdev);
freq_qos_remove_request(&cpufreq_cdev->qos_req);
free_idle_time(cpufreq_cdev);
-- 
2.17.1

[PATCH v3 3/5] thermal/drivers/devfreq_cooling: Use device name instead of auto-numbering

[Daniel Lezcano]

Currently the naming of a cooling device is just a cooling technique
followed by a number. When there are multiple cooling devices using
the same technique, it is impossible to clearly identify the related
device as this one is just a number.

For instance:

 thermal-devfreq-0
 thermal-devfreq-1
 etc ...

The 'thermal' prefix is redundant with the subsystem namespace. This
patch removes the 'thermal' prefix and changes the number by the device
name. So the naming above becomes:

 devfreq-500.gpu
 devfreq-1d84000.ufshc
 etc ...

Signed-off-by: Daniel Lezcano 
Reviewed-by: Lukasz Luba 
---
V2:
 - Removed idr.h header
 - Used kasprintf instead of fixed buffer length on the stack
 - Fixed typo in the log
---
 drivers/thermal/devfreq_cooling.c | 25 -
 1 file changed, 8 insertions(+), 17 deletions(-)

diff --git a/drivers/thermal/devfreq_cooling.c 
b/drivers/thermal/devfreq_cooling.c
index fed3121ff2a1..fb250ac16f50 100644
--- a/drivers/thermal/devfreq_cooling.c
+++ b/drivers/thermal/devfreq_cooling.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -25,11 +24,8 @@
 #define HZ_PER_KHZ 1000
 #define SCALE_ERROR_MITIGATION 100
 
-static DEFINE_IDA(devfreq_ida);
-
 /**
  * struct devfreq_cooling_device - Devfreq cooling device
- * @id:unique integer value corresponding to each
  * devfreq_cooling_device registered.
  * @cdev:  Pointer to associated thermal cooling device.
  * @devfreq:   Pointer to associated devfreq device.
@@ -51,7 +47,6 @@ static DEFINE_IDA(devfreq_ida);
  * @em_pd: Energy Model for the associated Devfreq device
  */
 struct devfreq_cooling_device {
-   int id;
struct thermal_cooling_device *cdev;
struct devfreq *devfreq;
unsigned long cooling_state;
@@ -363,7 +358,7 @@ of_devfreq_cooling_register_power(struct device_node *np, 
struct devfreq *df,
struct thermal_cooling_device *cdev;
struct device *dev = df->dev.parent;
struct devfreq_cooling_device *dfc;
-   char dev_name[THERMAL_NAME_LENGTH];
+   char *name;
int err, num_opps;
 
dfc = kzalloc(sizeof(*dfc), GFP_KERNEL);
@@ -407,30 +402,27 @@ of_devfreq_cooling_register_power(struct device_node *np, 
struct devfreq *df,
if (err < 0)
goto free_table;
 
-   err = ida_simple_get(&devfreq_ida, 0, 0, GFP_KERNEL);
-   if (err < 0)
+   cdev = ERR_PTR(-ENOMEM);
+   name = kasprintf(GFP_KERNEL, "devfreq-%s", dev_name(dev));
+   if (!name)
goto remove_qos_req;
 
-   dfc->id = err;
-
-   snprintf(dev_name, sizeof(dev_name), "thermal-devfreq-%d", dfc->id);
-
-   cdev = thermal_of_cooling_device_register(np, dev_name, dfc,
+   cdev = thermal_of_cooling_device_register(np, name, dfc,
  &devfreq_cooling_ops);
+   kfree(name);
+
if (IS_ERR(cdev)) {
err = PTR_ERR(cdev);
dev_err(dev,
"Failed to register devfreq cooling device (%d)\n",
err);
-   goto release_ida;
+   goto remove_qos_req;
}
 
dfc->cdev = cdev;
 
return cdev;
 
-release_ida:
-   ida_simple_remove(&devfreq_ida, dfc->id);
 remove_qos_req:
dev_pm_qos_remove_request(&dfc->req_max_freq);
 free_table:
@@ -527,7 +519,6 @@ void devfreq_cooling_unregister(struct 
thermal_cooling_device *cdev)
dev = dfc->devfreq->dev.parent;
 
thermal_cooling_device_unregister(dfc->cdev);
-   ida_simple_remove(&devfreq_ida, dfc->id);
dev_pm_qos_remove_request(&dfc->req_max_freq);
 
em_dev_unregister_perf_domain(dev);
-- 
2.17.1

[PATCH v3 1/5] thermal/drivers/core: Use a char pointer for the cooling device name

[Daniel Lezcano]

We want to have any kind of name for the cooling devices as we do no
longer want to rely on auto-numbering. Let's replace the cooling
device's fixed array by a char pointer to be allocated dynamically
when registering the cooling device, so we don't limit the length of
the name.

Rework the error path at the same time as we have to rollback the
allocations in case of error.

Tested with a dummy device having the name:
 "Llanfairpwllgwyngyllgogerychwyrndrobwantysiliogogogoch"

A village on the island of Anglesey (Wales), known to have the longest
name in Europe.

Signed-off-by: Daniel Lezcano 
Reviewed-by: Lukasz Luba 
---
V3:
  - Inverted kfree() and put_device() when unregistering the cooling device
(Reported by Ido Schimmel)
---
 .../ethernet/mellanox/mlxsw/core_thermal.c|  2 +-
 drivers/thermal/thermal_core.c| 38 +++
 include/linux/thermal.h   |  2 +-
 3 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c 
b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
index bf85ce9835d7..7447c2a73cbd 100644
--- a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
+++ b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c
@@ -141,7 +141,7 @@ static int mlxsw_get_cooling_device_idx(struct 
mlxsw_thermal *thermal,
/* Allow mlxsw thermal zone binding to an external cooling device */
for (i = 0; i < ARRAY_SIZE(mlxsw_thermal_external_allowed_cdev); i++) {
if (strnstr(cdev->type, mlxsw_thermal_external_allowed_cdev[i],
-   sizeof(cdev->type)))
+   strlen(cdev->type)))
return 0;
}
 
diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
index 996c038f83a4..c8d4010940ef 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -960,10 +960,7 @@ __thermal_cooling_device_register(struct device_node *np,
 {
struct thermal_cooling_device *cdev;
struct thermal_zone_device *pos = NULL;
-   int result;
-
-   if (type && strlen(type) >= THERMAL_NAME_LENGTH)
-   return ERR_PTR(-EINVAL);
+   int ret;
 
if (!ops || !ops->get_max_state || !ops->get_cur_state ||
!ops->set_cur_state)
@@ -973,14 +970,17 @@ __thermal_cooling_device_register(struct device_node *np,
if (!cdev)
return ERR_PTR(-ENOMEM);
 
-   result = ida_simple_get(&thermal_cdev_ida, 0, 0, GFP_KERNEL);
-   if (result < 0) {
-   kfree(cdev);
-   return ERR_PTR(result);
+   ret = ida_simple_get(&thermal_cdev_ida, 0, 0, GFP_KERNEL);
+   if (ret < 0)
+   goto out_kfree_cdev;
+   cdev->id = ret;
+
+   cdev->type = kstrdup(type ? type : "", GFP_KERNEL);
+   if (!cdev->type) {
+   ret = -ENOMEM;
+   goto out_ida_remove;
}
 
-   cdev->id = result;
-   strlcpy(cdev->type, type ? : "", sizeof(cdev->type));
mutex_init(&cdev->lock);
INIT_LIST_HEAD(&cdev->thermal_instances);
cdev->np = np;
@@ -990,12 +990,9 @@ __thermal_cooling_device_register(struct device_node *np,
cdev->devdata = devdata;
thermal_cooling_device_setup_sysfs(cdev);
dev_set_name(&cdev->device, "cooling_device%d", cdev->id);
-   result = device_register(&cdev->device);
-   if (result) {
-   ida_simple_remove(&thermal_cdev_ida, cdev->id);
-   put_device(&cdev->device);
-   return ERR_PTR(result);
-   }
+   ret = device_register(&cdev->device);
+   if (ret)
+   goto out_kfree_type;
 
/* Add 'this' new cdev to the global cdev list */
mutex_lock(&thermal_list_lock);
@@ -1013,6 +1010,14 @@ __thermal_cooling_device_register(struct device_node *np,
mutex_unlock(&thermal_list_lock);
 
return cdev;
+
+out_kfree_type:
+   kfree(cdev->type);
+   put_device(&cdev->device);
+out_ida_remove:
+   ida_simple_remove(&thermal_cdev_ida, cdev->id);
+out_kfree_cdev:
+   return ERR_PTR(ret);
 }
 
 /**
@@ -1171,6 +1176,7 @@ void thermal_cooling_device_unregister(struct 
thermal_cooling_device *cdev)
ida_simple_remove(&thermal_cdev_ida, cdev->id);
device_del(&cdev->device);
thermal_cooling_device_destroy_sysfs(cdev);
+   kfree(cdev->type);
put_device(&cdev->device);
 }
 EXPORT_SYMBOL_GPL(thermal_cooling_device_unregister);
diff --git a/include/linux/thermal.h b/include/linux/thermal.h
index 6ac7bb1d2b1f..169502164364 100644
--- a/include/linux/thermal.h
+++ b/include/linux/thermal.h
@@ -91,7 +91,7 @@ struct thermal_cooling_device_ops {
 
 struct thermal_cooling_device {
int id;
-   char type[THERMAL_NAME_LENGTH];
+   char *type;
struct device device;
struct device_node *np;
void *devdata;
-- 
2.17.1

[PATCH v6] selftests/x86: Use getauxval() to simplify the code in sgx

[Tianjia Zhang]

Simplify the sgx code implemntation by using library function
getauxval() instead of a custom function to get the base address
of vDSO.

Signed-off-by: Tianjia Zhang 
Reviewed-by: Jarkko Sakkinen 
Acked-by: Shuah Khan 
---
 tools/testing/selftests/sgx/main.c | 24 
 1 file changed, 4 insertions(+), 20 deletions(-)

diff --git a/tools/testing/selftests/sgx/main.c 
b/tools/testing/selftests/sgx/main.c
index 724cec700926..5167505fbb46 100644
--- a/tools/testing/selftests/sgx/main.c
+++ b/tools/testing/selftests/sgx/main.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "defines.h"
 #include "main.h"
 #include "../kselftest.h"
@@ -28,24 +29,6 @@ struct vdso_symtab {
Elf64_Word *elf_hashtab;
 };
 
-static void *vdso_get_base_addr(char *envp[])
-{
-   Elf64_auxv_t *auxv;
-   int i;
-
-   for (i = 0; envp[i]; i++)
-   ;
-
-   auxv = (Elf64_auxv_t *)&envp[i + 1];
-
-   for (i = 0; auxv[i].a_type != AT_NULL; i++) {
-   if (auxv[i].a_type == AT_SYSINFO_EHDR)
-   return (void *)auxv[i].a_un.a_val;
-   }
-
-   return NULL;
-}
-
 static Elf64_Dyn *vdso_get_dyntab(void *addr)
 {
Elf64_Ehdr *ehdr = addr;
@@ -162,7 +145,7 @@ static int user_handler(long rdi, long rsi, long rdx, long 
ursp, long r8, long r
return 0;
 }
 
-int main(int argc, char *argv[], char *envp[])
+int main(int argc, char *argv[])
 {
struct sgx_enclave_run run;
struct vdso_symtab symtab;
@@ -203,7 +186,8 @@ int main(int argc, char *argv[], char *envp[])
memset(&run, 0, sizeof(run));
run.tcs = encl.encl_base;
 
-   addr = vdso_get_base_addr(envp);
+   /* Get vDSO base address */
+   addr = (void *)getauxval(AT_SYSINFO_EHDR);
if (!addr)
goto err;
 
-- 
2.19.1.3.ge56e4f7

[PATCH net v2] net: hdlc_x25: Prevent racing between "x25_close" and "x25_xmit"/"x25_rx"

[Xie He]

"x25_close" is called by "hdlc_close" in "hdlc.c", which is called by
hardware drivers' "ndo_stop" function.
"x25_xmit" is called by "hdlc_start_xmit" in "hdlc.c", which is hardware
drivers' "ndo_start_xmit" function.
"x25_rx" is called by "hdlc_rcv" in "hdlc.c", which receives HDLC frames
from "net/core/dev.c".

"x25_close" races with "x25_xmit" and "x25_rx" because their callers race.

However, we need to ensure that the LAPB APIs called in "x25_xmit" and
"x25_rx" are called before "lapb_unregister" is called in "x25_close".

This patch adds locking to ensure when "x25_xmit" and "x25_rx" are doing
their work, "lapb_unregister" is not yet called in "x25_close".

Reasons for not solving the racing between "x25_close" and "x25_xmit" by
calling "netif_tx_disable" in "x25_close":
1. We still need to solve the racing between "x25_close" and "x25_rx";
2. The design of the HDLC subsystem assumes the HDLC hardware drivers
have full control over the TX queue, and the HDLC protocol drivers (like
this driver) have no control. Controlling the queue here in the protocol
driver may interfere with hardware drivers' control of the queue.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Xie He 
---

Change from v1:
Added a "Fixes" tag.

---
 drivers/net/wan/hdlc_x25.c | 42 +-
 1 file changed, 41 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wan/hdlc_x25.c b/drivers/net/wan/hdlc_x25.c
index 4aaa6388b9ee..5a6a945f6c81 100644
--- a/drivers/net/wan/hdlc_x25.c
+++ b/drivers/net/wan/hdlc_x25.c
@@ -23,6 +23,8 @@
 
 struct x25_state {
x25_hdlc_proto settings;
+   bool up;
+   spinlock_t up_lock; /* Protects "up" */
 };
 
 static int x25_ioctl(struct net_device *dev, struct ifreq *ifr);
@@ -104,6 +106,8 @@ static void x25_data_transmit(struct net_device *dev, 
struct sk_buff *skb)
 
 static netdev_tx_t x25_xmit(struct sk_buff *skb, struct net_device *dev)
 {
+   hdlc_device *hdlc = dev_to_hdlc(dev);
+   struct x25_state *x25st = state(hdlc);
int result;
 
/* There should be a pseudo header of 1 byte added by upper layers.
@@ -114,11 +118,19 @@ static netdev_tx_t x25_xmit(struct sk_buff *skb, struct 
net_device *dev)
return NETDEV_TX_OK;
}
 
+   spin_lock_bh(&x25st->up_lock);
+   if (!x25st->up) {
+   spin_unlock_bh(&x25st->up_lock);
+   kfree_skb(skb);
+   return NETDEV_TX_OK;
+   }
+
switch (skb->data[0]) {
case X25_IFACE_DATA:/* Data to be transmitted */
skb_pull(skb, 1);
if ((result = lapb_data_request(dev, skb)) != LAPB_OK)
dev_kfree_skb(skb);
+   spin_unlock_bh(&x25st->up_lock);
return NETDEV_TX_OK;
 
case X25_IFACE_CONNECT:
@@ -147,6 +159,7 @@ static netdev_tx_t x25_xmit(struct sk_buff *skb, struct 
net_device *dev)
break;
}
 
+   spin_unlock_bh(&x25st->up_lock);
dev_kfree_skb(skb);
return NETDEV_TX_OK;
 }
@@ -164,6 +177,7 @@ static int x25_open(struct net_device *dev)
.data_transmit = x25_data_transmit,
};
hdlc_device *hdlc = dev_to_hdlc(dev);
+   struct x25_state *x25st = state(hdlc);
struct lapb_parms_struct params;
int result;
 
@@ -190,6 +204,10 @@ static int x25_open(struct net_device *dev)
if (result != LAPB_OK)
return -EINVAL;
 
+   spin_lock_bh(&x25st->up_lock);
+   x25st->up = true;
+   spin_unlock_bh(&x25st->up_lock);
+
return 0;
 }
 
@@ -197,6 +215,13 @@ static int x25_open(struct net_device *dev)
 
 static void x25_close(struct net_device *dev)
 {
+   hdlc_device *hdlc = dev_to_hdlc(dev);
+   struct x25_state *x25st = state(hdlc);
+
+   spin_lock_bh(&x25st->up_lock);
+   x25st->up = false;
+   spin_unlock_bh(&x25st->up_lock);
+
lapb_unregister(dev);
 }
 
@@ -205,15 +230,28 @@ static void x25_close(struct net_device *dev)
 static int x25_rx(struct sk_buff *skb)
 {
struct net_device *dev = skb->dev;
+   hdlc_device *hdlc = dev_to_hdlc(dev);
+   struct x25_state *x25st = state(hdlc);
 
if ((skb = skb_share_check(skb, GFP_ATOMIC)) == NULL) {
dev->stats.rx_dropped++;
return NET_RX_DROP;
}
 
-   if (lapb_data_received(dev, skb) == LAPB_OK)
+   spin_lock_bh(&x25st->up_lock);
+   if (!x25st->up) {
+   spin_unlock_bh(&x25st->up_lock);
+   kfree_skb(skb);
+   dev->stats.rx_dropped++;
+   return NET_RX_DROP;
+   }
+
+   if (lapb_data_received(dev, skb) == LAPB_OK) {
+   spin_unlock_bh(&x25st->up_lock);
return NET_RX_SUCCESS;
+   }
 
+   spin_unlock_bh(&x25st->up_lock);
dev->stats.rx_errors++;
dev_kfree_skb_any(skb);
return NET_RX_DROP;
@@ -298,6 +336,8 @@ static int x25_ioctl(struct net_device *dev

Re: [PATCH 0/6] usbip fixes to crashes found by syzbot

[Tetsuo Handa]

On 2021/03/13 9:48, Tetsuo Handa wrote:
> On 2021/03/12 14:44, Tetsuo Handa wrote:
>> And what you are missing in your [PATCH 4,5,6/6] is
>>
>>   diff --git a/drivers/usb/usbip/vhci_sysfs.c 
>> b/drivers/usb/usbip/vhci_sysfs.c
>>   index c4457026d5ad..3c64bd06ab53 100644
>>   --- a/drivers/usb/usbip/vhci_sysfs.c
>>   +++ b/drivers/usb/usbip/vhci_sysfs.c
>>   @@ -423,6 +423,7 @@ static ssize_t attach_store(struct device *dev, struct 
>> device_attribute *attr,
>>   /* end the lock */
>>   
>>   wake_up_process(vdev->ud.tcp_rx);
>>   +   schedule_timeout_uninterruptible(HZ); // Consider being preempted 
>> here.
>>   wake_up_process(vdev->ud.tcp_tx);
>>   
>>   rh_port_connect(vdev, speed);
>>
>> . wake_up_process(tcp_tx) can call vhci_shutdown_connection() before 
>> wake_up_process(tcp_tx) is called.
> 
> wake_up_process(tcp_rx) can call vhci_shutdown_connection() before 
> wake_up_process(tcp_tx) is called.
> 
>> Since vhci_shutdown_connection() destroys tcp_tx thread and releases tcp_tx 
>> memory via kthread_stop_put(tcp_tx),
>> wake_up_process(tcp_tx) will access already freed memory. Your patch 
>> converted "NULL pointer dereference caused by
>> failing to call kthread_stop_put(tcp_tx)" into "use after free caused by 
>> succeeding to call kthread_stop_put(tcp_tx)".
>>
> 
> And note that
> 
>   diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
>   index c4457026d5ad..0e1a81d4632c 100644
>   --- a/drivers/usb/usbip/vhci_sysfs.c
>   +++ b/drivers/usb/usbip/vhci_sysfs.c
>   @@ -422,11 +422,11 @@ static ssize_t attach_store(struct device *dev, 
> struct device_attribute *attr,
>   spin_unlock_irqrestore(&vhci->lock, flags);
>   /* end the lock */
>   
>   -   wake_up_process(vdev->ud.tcp_rx);
>   -   wake_up_process(vdev->ud.tcp_tx);
>   -
>   rh_port_connect(vdev, speed);
>   
>   +   wake_up_process(vdev->ud.tcp_tx);
>   +   wake_up_process(vdev->ud.tcp_rx);
>   +
>   return count;
>}
>static DEVICE_ATTR_WO(attach);
> 
> is as well not sufficient, for you are still missing

Well, since tx thread can as well call usbip_event_add(USBIP_EH_SHUTDOWN), 
reversing
the order of wake_up_process(tcp_tx) and wake_up_process(tcp_rx) will not help.

> 
>   diff --git a/drivers/usb/usbip/vhci_sysfs.c b/drivers/usb/usbip/vhci_sysfs.c
>   index c4457026d5ad..c958f89a9196 100644
>   --- a/drivers/usb/usbip/vhci_sysfs.c
>   +++ b/drivers/usb/usbip/vhci_sysfs.c
>   @@ -422,11 +422,13 @@ static ssize_t attach_store(struct device *dev, 
> struct device_attribute *attr,
>   spin_unlock_irqrestore(&vhci->lock, flags);
>   /* end the lock */
>   
>   -   wake_up_process(vdev->ud.tcp_rx);
>   -   wake_up_process(vdev->ud.tcp_tx);
>   +   schedule_timeout_uninterruptible(HZ); // Consider being preempted 
> here.
>   
>   rh_port_connect(vdev, speed);
>   
>   +   wake_up_process(vdev->ud.tcp_tx);
>   +   wake_up_process(vdev->ud.tcp_rx);
>   +
>   return count;
>}
>static DEVICE_ATTR_WO(attach);
> 
> because vhci_port_disconnect() from detach_store() can call 
> usbip_event_add(&vdev->ud, VDEV_EVENT_DOWN)
> (same use after free bug regarding tcp_tx and tcp_rx) as soon as all shared 
> states are set up and
> spinlocks are released.
> 
> What you had better consider first is how to protect 
> event_handler()/usbip_sockfd_store()/attach_store()/detach_store() functions
>  from concurrent calls. Please respond to 
> https://lkml.kernel.org/r/3dab66dc-2981-bc88-a370-4b3178dfd...@i-love.sakura.ne.jp
> before you try to make further changes.
> 

After all, I believe that there is no choice but introduce a mutex for 
serialization.

Greg, please pick up 
https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux.git/commit/?h=usbip_test&id=f345de0d2e51a20a2a1c30fc22fa1527670d2095
and below patch.

>From e0579aa776e4a3568c06f767c193d2204b64679d Mon Sep 17 00:00:00 2001
From: Tetsuo Handa 
Date: Sun, 14 Mar 2021 20:24:16 +0900
Subject: [PATCH v5] usb: usbip: serialize attach/detach operations

The root problem syzbot has found [1] is that usbip module is not using
serialization between attach/detach operations and event_handler().
This results in the following race windows.

  (1) two userspace processes can perform attach operation on the same
  device by writing the same content to the same attach interface
  file

  (2) one userspace process can perform detach operation on a device by
  writing to detach interface file while the other userspace process
  is performing attach operation on that device by writing to attach
  interface file

  (3) event_handler() kernel workqueue thread can perform detach operation
  on a device while some userspace process is still performing attach
  operation on that device

What syzbot is reporting is (3), and what commits 46613c9dfa964c0c,
718ad9693e365612 and 9380afd6df70e24e did not take into

ERROR: modpost: "__aeabi_unwind_cpp_pr0" undefined!

[kernel test robot]

Hi Ye,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   88fe49249c99de14e543c632a46248d85411ab9e
commit: 660987e1250334dd944aab0421144b541675d5d1 iio: hid-sensors: Add hinge 
sensor driver
date:   7 weeks ago
config: arm-randconfig-r024-20210314 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project 
dfd27ebbd0eb137c9a439b7c537bb87ba903efd3)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install arm cross compiling tool for clang build
# apt-get install binutils-arm-linux-gnueabi
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=660987e1250334dd944aab0421144b541675d5d1
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 660987e1250334dd944aab0421144b541675d5d1
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=arm 

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

All errors (new ones prefixed by >>, old ones prefixed by <<):

ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/soc/codecs/snd-soc-ak4458.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/soc/codecs/snd-soc-ak4104.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" 
[sound/soc/codecs/snd-soc-adau7118-hw.ko] undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" 
[sound/soc/codecs/snd-soc-adau7118-i2c.ko] undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/soc/codecs/snd-soc-adau7118.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/soc/codecs/snd-soc-adau7002.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" 
[sound/soc/codecs/snd-soc-adau1761-spi.ko] undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/soc/codecs/snd-soc-adau1761.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/soc/codecs/snd-soc-adau17x1.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/soc/codecs/snd-soc-adau1701.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" 
[sound/soc/codecs/snd-soc-adau1372-spi.ko] undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" 
[sound/soc/codecs/snd-soc-adau1372-i2c.ko] undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/soc/codecs/snd-soc-adau1372.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" 
[sound/soc/codecs/snd-soc-adau-utils.ko] undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/soc/codecs/snd-soc-ac97.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/soc/snd-soc-core.ko] undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/usb/line6/snd-usb-variax.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/usb/line6/snd-usb-toneport.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/usb/line6/snd-usb-podhd.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/usb/line6/snd-usb-line6.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/usb/hiface/snd-usb-hiface.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/usb/6fire/snd-usb-6fire.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/usb/misc/snd-ua101.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/usb/snd-usbmidi-lib.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/usb/snd-usb-audio.ko] undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/pci/ac97/snd-ac97-codec.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/core/snd-compress.ko] undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/core/seq/snd-seq-midi-event.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/core/seq/snd-seq-midi.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/core/seq/snd-seq-dummy.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/core/seq/snd-seq.ko] undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/core/snd-rawmidi.ko] undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/core/snd-seq-device.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/core/snd-pcm-dmaengine.ko] 
undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/core/snd-pcm.ko] undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/core/snd-timer.ko] undefined!
ERROR: modpost: "__aeabi_unwind_cpp_pr0" [sound/core/snd-hwdep.ko] 

Re: [PATCH v4 3/3] x86/sgx: Add a basic NUMA allocation scheme to sgx_alloc_epc_page()

[Jarkko Sakkinen]

On Sat, Mar 13, 2021 at 06:01:19PM +0200, Jarkko Sakkinen wrote:
> Background
> ==
> 
> EPC section is covered by one or more SRAT entries that are associated with
> one and only one PXM (NUMA node). The motivation behind this patch is to
> provide basic elements of building allocation scheme based on this premise.
> 
> Just like normal RAM, enclave memory (EPC) should be covered by entries
> in the ACPI SRAT table.  These entries allow each EPC section to be
> associated with a NUMA node.
> 
> Use this information to implement a simple NUMA-aware allocator for
> enclave memory.
> 
> Solution
> 
> 
> Use phys_to_target_node() to associate each NUMA node with the EPC
> sections contained within its range. In sgx_alloc_epc_page(), first try
> to allocate from the NUMA node, where the CPU is executing. If that
> fails, allocate from other nodes, iterating them from the current node
> in order.
> 
> Other
> =
> 
> NUMA_KEEP_MEMINFO dependency is required for phys_to_target_node().
> 
> Link: 
> https://lore.kernel.org/lkml/158188326978.894464.217282995221175417.st...@dwillia2-desk3.amr.corp.intel.com/
> Signed-off-by: Jarkko Sakkinen 

We *can* have also epc_page->node by:

- Considering the first section as the EPC of that node.
- Printing a warning if more sections hit the same node, and
  ignoring them.
- Merging sgx_numa_node and sgx_epc_section

I think this would be a decent idea. I think it's a sane assumption that
a node has a single EPC section, but it's good to have that warning just
in case.

I did not want to do this into this version because it's faster for me
to refactor into this assumption than revert back.

/Jarkko

> ---
> 
> v4:
> * Cycle nodes instead of a global page list, starting from the node
>   of the current thread.
> * Documented NUMA_KEEP_MEMINFO dependency to the commit message.
> * Added NUMA node pointer to struct sgx_epc_section. EPC page should
>   reference to a section, since potentially a node could have multiple
>   sections (Intel SDM does not say anything explicit about this).
>   This the safest play.
> * Remove nodes_clear(sgx_numa_node_mask).
> * Appended Dave's additions to the commit message for the background
>   section.
> 
>  arch/x86/Kconfig   |   1 +
>  arch/x86/kernel/cpu/sgx/main.c | 117 -
>  arch/x86/kernel/cpu/sgx/sgx.h  |  16 +++--
>  3 files changed, 84 insertions(+), 50 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 513895af8ee7..3e6152a8dd2b 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1930,6 +1930,7 @@ config X86_SGX
>   depends on CRYPTO_SHA256=y
>   select SRCU
>   select MMU_NOTIFIER
> + select NUMA_KEEP_MEMINFO if NUMA
>   help
> Intel(R) Software Guard eXtensions (SGX) is a set of CPU instructions
> that can be used by applications to set aside private regions of code
> diff --git a/arch/x86/kernel/cpu/sgx/main.c b/arch/x86/kernel/cpu/sgx/main.c
> index cb4561444b96..3b524a1361d6 100644
> --- a/arch/x86/kernel/cpu/sgx/main.c
> +++ b/arch/x86/kernel/cpu/sgx/main.c
> @@ -18,14 +18,23 @@ static int sgx_nr_epc_sections;
>  static struct task_struct *ksgxd_tsk;
>  static DECLARE_WAIT_QUEUE_HEAD(ksgxd_waitq);
>  
> -/*
> - * These variables are part of the state of the reclaimer, and must be 
> accessed
> - * with sgx_reclaimer_lock acquired.
> - */
> +/* The reclaimer lock protected variables prepend the lock. */
>  static LIST_HEAD(sgx_active_page_list);
> -
>  static DEFINE_SPINLOCK(sgx_reclaimer_lock);
>  
> +/* The free page list lock protected variables prepend the lock. */
> +static unsigned long sgx_nr_free_pages;
> +
> +/* Nodes with one or more EPC sections. */
> +static nodemask_t sgx_numa_mask;
> +
> +/*
> + * Array with one list_head for each possible NUMA node.  Each
> + * list contains all the sgx_epc_section's which are on that
> + * node.
> + */
> +static struct sgx_numa_node *sgx_numa_nodes;
> +
>  /*
>   * When the driver initialized, EPC pages go first here, as they could be
>   * initialized to an active enclave, on kexec entry.
> @@ -352,21 +361,9 @@ static void sgx_reclaim_pages(void)
>   }
>  }
>  
> -static unsigned long sgx_nr_free_pages(void)
> -{
> - unsigned long cnt = 0;
> - int i;
> -
> - for (i = 0; i < sgx_nr_epc_sections; i++)
> - cnt += sgx_epc_sections[i].free_cnt;
> -
> - return cnt;
> -}
> -
>  static bool sgx_should_reclaim(unsigned long watermark)
>  {
> - return sgx_nr_free_pages() < watermark &&
> -!list_empty(&sgx_active_page_list);
> + return sgx_nr_free_pages < watermark && 
> !list_empty(&sgx_active_page_list);
>  }
>  
>  static int ksgxd(void *p)
> @@ -443,50 +440,63 @@ static bool __init sgx_page_reclaimer_init(void)
>   return true;
>  }
>  
> -static struct sgx_epc_page *__sgx_alloc_epc_page_from_section(struct 
> sgx_epc_section *section)
> +static struct sgx_epc_page *__sgx_alloc_epc_page_from_node(int 

[GIT PULL] x86/urgent for v5.12-rc3

[Borislav Petkov]

Hi Linus,

please pull the accumulated x86/urgent pile for v5.12-rc3.

Thx.

---

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
tags/x86_urgent_for_v5.12_rc3

for you to fetch changes up to bffe30dd9f1f3b2608a87ac909a224d6be472485:

  x86/sev-es: Use __copy_from_user_inatomic() (2021-03-09 12:37:54 +0100)


- A couple of SEV-ES fixes and robustifications: verify usermode stack
pointer in NMI is not coming from the syscall gap, correctly track IRQ
states in the #VC handler and access user insn bytes atomically in same
handler as latter cannot sleep.

- Balance 32-bit fast syscall exit path to do the proper work on exit
and thus not confuse audit and ptrace frameworks.

- Two fixes for the ORC unwinder going "off the rails" into KASAN
redzones and when ORC data is missing.


Andy Lutomirski (1):
  x86/entry: Fix entry/exit mismatch on failed fast 32-bit syscalls

Joerg Roedel (4):
  x86/sev-es: Introduce ip_within_syscall_gap() helper
  x86/sev-es: Check regs->sp is trusted before adjusting #VC IST stack
  x86/sev-es: Correctly track IRQ states in runtime #VC handler
  x86/sev-es: Use __copy_from_user_inatomic()

Josh Poimboeuf (2):
  x86/unwind/orc: Disable KASAN checking in the ORC unwinder, part 2
  x86/unwind/orc: Silence warnings caused by missing ORC data

 arch/x86/entry/common.c  |  3 +-
 arch/x86/entry/entry_64_compat.S |  2 ++
 arch/x86/include/asm/insn-eval.h |  2 ++
 arch/x86/include/asm/proto.h |  1 +
 arch/x86/include/asm/ptrace.h| 15 +
 arch/x86/kernel/sev-es.c | 22 +++---
 arch/x86/kernel/traps.c  |  3 +-
 arch/x86/kernel/unwind_orc.c | 14 -
 arch/x86/lib/insn-eval.c | 66 +++-
 9 files changed, 99 insertions(+), 29 deletions(-)

-- 
Regards/Gruss,
Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG 
Nürnberg

Re: [PATCH 0/4] Expose and manage PCI device reset

[Leon Romanovsky]

On Fri, Mar 12, 2021 at 11:04:48PM +0530, ameynarkhed...@gmail.com wrote:
> From: Amey Narkhede 
>
> PCI and PCIe devices may support a number of possible reset mechanisms
> for example Function Level Reset (FLR) provided via Advanced Feature or
> PCIe capabilities, Power Management reset, bus reset, or device specific 
> reset.
> Currently the PCI subsystem creates a policy prioritizing these reset methods
> which provides neither visibility nor control to userspace.
>
> Expose the reset methods available per device to userspace, via sysfs
> and allow an administrative user or device owner to have ability to
> manage per device reset method priorities or exclusions.
> This feature aims to allow greater control of a device for use cases
> as device assignment, where specific device or platform issues may
> interact poorly with a given reset method, and for which device specific
> quirks have not been developed.

Sorry, are we talking about specific devices/flows/applications that
must have this functionality or about theoretical use case?

Thanks

Re: [BUG] net: rds: rds_send_probe memory leak

[Fatih Yildirim]

On Sun, 2021-03-14 at 09:36 +0100, Greg KH wrote:
> On Sun, Mar 14, 2021 at 11:23:10AM +0300, Fatih Yildirim wrote:
> > Hi Santosh,
> > 
> > I've been working on a memory leak bug reported by syzbot.
> > https://syzkaller.appspot.com/bug?id=39b72114839a6dbd66c1d2104522698a813f9ae2
> > 
> > It seems that memory allocated in rds_send_probe function is not
> > freed.
> > 
> > Let me share my observations.
> > rds_message is allocated at the beginning of rds_send_probe
> > function.
> > Then it is added to cp_send_queue list of rds_conn_path and
> > refcount
> > is increased by one.
> > Next, in rds_send_xmit function it is moved from cp_send_queue list
> > to
> > cp_retrans list, and again refcount is increased by one.
> > Finally in rds_loop_xmit function refcount is increased by one.
> > So, total refcount is 4.
> > However, rds_message_put is called three times, in rds_send_probe,
> > rds_send_remove_from_sock and rds_send_xmit functions. It seems
> > that
> > one more rds_message_put is needed.
> > Would you please check and share your comments on this issue?
> 
> Do you have a proposed patch that syzbot can test to verify if this
> is
> correct or not?
> 
> thanks,
> 
> gre gk-h

Hi Greg,

Actually, using the .config and the C reproducer, syzbot reports the
memory leak in rds_send_probe function. Also by enabling
CONFIG_RDS_DEBUG=y, the debug messages indicates the similar as I
mentioned above. To give an example, below is the RDS_DEBUG messages.
Allocated address 8a7476e5 has initial ref_count 1. Then there
are three rds_message_addref calls for the same address making the
refcount 4, but only three rds_message_put calls which leave the
address still allocated.

[   60.570681] rds_message_addref(): addref rm 8a7476e5 ref 1
[   60.570707] rds_message_put(): put rm 8a7476e5 ref 2
[   60.570845] rds_message_addref(): addref rm 8a7476e5 ref 1
[   60.570870] rds_message_addref(): addref rm 8a7476e5 ref 2
[   60.570960] rds_message_put(): put rm 8a7476e5 ref 3
[   60.570995] rds_message_put(): put rm 8a7476e5 ref 2

Thanks,
Fatih

[GIT PULL] efi/urgent for v5.12-rc3

[Borislav Petkov]

Hi Linus,

please pull a single (forwarded) EFI urgent fix for v5.12-rc3.

Thx.

---

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
tags/efi-urgent-for-v5.12-rc2

for you to fetch changes up to 9e9888a0fe97b9501a40f717225d2bef7100a2c1:

  efi: stub: omit SetVirtualAddressMap() if marked unsupported in RT_PROP table 
(2021-03-07 09:31:02 +0100)


EFI fix for 5.12-rc2

Fix an oversight in the handling of the UEFI 2.8 EFI_RT_PROPERTIES_TABLE,
which was added v5.10, but failed to take the SetVirtualAddressMap() RT
service into account.


Ard Biesheuvel (1):
  efi: stub: omit SetVirtualAddressMap() if marked unsupported in RT_PROP 
table

 drivers/firmware/efi/libstub/efi-stub.c | 16 
 1 file changed, 16 insertions(+)

-- 
Regards/Gruss,
Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG 
Nürnberg

[PATCH] hwmon: corsair-psu: add support for critical values

[Wilken Gottwalt]

Adds support for reading the critical values of the temperature sensors
and the rail sensors (voltage and current) once and caches them. Updates
the naming of the constants following a more clear scheme. Also updates
the documentation and fixes a typo.

The new sensors output of a Corsair HX850i will look like this:
corsairpsu-hid-3-1
Adapter: HID adapter
v_in:230.00 V
v_out +12v:   12.14 V  (crit min =  +8.41 V, crit max = +15.59 V)
v_out +5v: 5.03 V  (crit min =  +3.50 V, crit max =  +6.50 V)
v_out +3.3v:   3.30 V  (crit min =  +2.31 V, crit max =  +4.30 V)
psu fan:0 RPM
vrm temp: +46.2°C  (crit = +70.0°C)
case temp:+39.8°C  (crit = +70.0°C)
power total: 152.00 W
power +12v:  108.00 W
power +5v:41.00 W
power +3.3v:   5.00 W
curr in:  N/A
curr +12v: 9.00 A  (crit max = +85.00 A)
curr +5v:  8.31 A  (crit max = +40.00 A)
curr +3.3v:1.62 A  (crit max = +40.00 A)

This patch changes:
- hwmon corsair-psu documentation
- hwmon corsair-psu driver

Signed-off-by: Wilken Gottwalt 
---
 Documentation/hwmon/corsair-psu.rst |  13 +-
 drivers/hwmon/corsair-psu.c | 185 ++--
 2 files changed, 157 insertions(+), 41 deletions(-)

diff --git a/Documentation/hwmon/corsair-psu.rst 
b/Documentation/hwmon/corsair-psu.rst
index 396b95c9a76a..b77e53810a13 100644
--- a/Documentation/hwmon/corsair-psu.rst
+++ b/Documentation/hwmon/corsair-psu.rst
@@ -45,19 +45,30 @@ Sysfs entries
 -
 
 ===

+curr2_crit Current max critical value on the 12v psu rail
+curr3_crit Current max critical value on the 5v psu rail
+curr4_crit Current max critical value on the 3.3v psu rail
 curr1_inputTotal current usage
 curr2_inputCurrent on the 12v psu rail
 curr3_inputCurrent on the 5v psu rail
 curr4_inputCurrent on the 3.3v psu rail
 fan1_input RPM of psu fan
+in1_crit   Voltage max critical value on the 12v psu rail
+in2_crit   Voltage max critical value on the 5v psu rail
+in3_crit   Voltage max critical value on the 3.3v psu rail
 in0_input  Voltage of the psu ac input
 in1_input  Voltage of the 12v psu rail
 in2_input  Voltage of the 5v psu rail
-in3_input  Voltage of the 3.3 psu rail
+in3_input  Voltage of the 3.3v psu rail
+in1_lcrit  Voltage min critical value on the 12v psu rail
+in2_lcrit  Voltage min critical value on the 5v psu rail
+in3_lcrit  Voltage min critical value on the 3.3v psu rail
 power1_input   Total power usage
 power2_input   Power usage of the 12v psu rail
 power3_input   Power usage of the 5v psu rail
 power4_input   Power usage of the 3.3v psu rail
+temp1_crit Temperature max cirtical value of the psu vrm component
+temp2_crit Temperature max critical value of psu case
 temp1_inputTemperature of the psu vrm component
 temp2_inputTemperature of the psu case
 ===

diff --git a/drivers/hwmon/corsair-psu.c b/drivers/hwmon/corsair-psu.c
index b0953eeeb2d3..141a5079ea7e 100644
--- a/drivers/hwmon/corsair-psu.c
+++ b/drivers/hwmon/corsair-psu.c
@@ -53,11 +53,21 @@
 #define CMD_TIMEOUT_MS 250
 #define SECONDS_PER_HOUR   (60 * 60)
 #define SECONDS_PER_DAY(SECONDS_PER_HOUR * 24)
+#define RAIL_COUNT 3 /* 3v3 + 5v + 12v */
+#define CRIT_VALUES_COUNT  11 /* 2 temp crit + 6 rail volts (low and high) 
+ 3 rails amps */
+#define TEMP_HCRIT 0
+#define VOLTS_RAIL_HCRIT   2
+#define VOLTS_RAIL_LCRIT   5
+#define AMPS_RAIL_HCRIT8
 
 #define PSU_CMD_SELECT_RAIL0x00 /* expects length 2 */
-#define PSU_CMD_IN_VOLTS   0x88 /* the rest of the commands expect length 
3 */
+#define PSU_CMD_RAIL_VOLTS_HCRIT 0x40 /* the rest of the commands expect 
length 3 */
+#define PSU_CMD_RAIL_VOLTS_LCRIT 0x44
+#define PSU_CMD_RAIL_AMPS_HCRIT0x46
+#define PSU_CMD_TEMP_HCRIT 0x4F
+#define PSU_CMD_IN_VOLTS   0x88
 #define PSU_CMD_IN_AMPS0x89
-#define PSU_CMD_RAIL_OUT_VOLTS 0x8B
+#define PSU_CMD_RAIL_VOLTS 0x8B
 #define PSU_CMD_RAIL_AMPS  0x8C
 #define PSU_CMD_TEMP0  0x8D
 #define PSU_CMD_TEMP1  0x8E
@@ -113,6 +123,7 @@ struct corsairpsu_data {
struct dentry *debugfs;
struct completion wait_completion;
struct mutex lock; /* for locking access to cmd_buffer */
+   long crit_values[CRIT_VALUES_COUNT];
u8 *cmd_buffer;
char vendor[REPLY_SIZE];
char product[REPLY_SIZE];
@@ -193,7 +204,10 @@ static int corsairpsu_request(struct corsairpsu_data 
*priv, u8 cmd, u8 rail, voi
 
mutex_lock(&priv->lock);
swi

[GIT PULL] perf/urgent for v5.12-rc3

[Borislav Petkov]

Hi Linus,

please pull there perf urgent fixes for v5.12-rc3.

Thx.

---

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
tags/perf_urgent_for_v5.12-rc3

for you to fetch changes up to c8e2fe13d1d1f3a02842b7b909d4e4846a4b6a2c:

  x86/perf: Use RET0 as default for guest_get_msrs to handle "no PMU" case 
(2021-03-10 16:45:09 +0100)


- Make sure PMU internal buffers are flushed for per-CPU events too and
  properly handle PID/TID for large PEBS.

- Handle the case properly when there's no PMU and therefore return an
  empty list of perf MSRs for VMX to switch instead of reading random
  garbage from the stack.


Kan Liang (2):
  perf/core: Flush PMU internal buffers for per-CPU events
  perf/x86/intel: Set PERF_ATTACH_SCHED_CB for large PEBS and LBR

Sean Christopherson (1):
  x86/perf: Use RET0 as default for guest_get_msrs to handle "no PMU" case

 arch/x86/events/core.c   | 15 ++-
 arch/x86/events/intel/core.c |  5 -
 arch/x86/kvm/vmx/vmx.c   |  2 +-
 include/linux/perf_event.h   |  2 ++
 kernel/events/core.c | 42 ++
 5 files changed, 51 insertions(+), 15 deletions(-)

-- 
Regards/Gruss,
Boris.

SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer, HRB 36809, AG 
Nürnberg

Re: [BUG] net: rds: rds_send_probe memory leak

[Greg KH]

On Sun, Mar 14, 2021 at 03:19:05PM +0300, Fatih Yildirim wrote:
> On Sun, 2021-03-14 at 09:36 +0100, Greg KH wrote:
> > On Sun, Mar 14, 2021 at 11:23:10AM +0300, Fatih Yildirim wrote:
> > > Hi Santosh,
> > > 
> > > I've been working on a memory leak bug reported by syzbot.
> > > https://syzkaller.appspot.com/bug?id=39b72114839a6dbd66c1d2104522698a813f9ae2
> > > 
> > > It seems that memory allocated in rds_send_probe function is not
> > > freed.
> > > 
> > > Let me share my observations.
> > > rds_message is allocated at the beginning of rds_send_probe
> > > function.
> > > Then it is added to cp_send_queue list of rds_conn_path and
> > > refcount
> > > is increased by one.
> > > Next, in rds_send_xmit function it is moved from cp_send_queue list
> > > to
> > > cp_retrans list, and again refcount is increased by one.
> > > Finally in rds_loop_xmit function refcount is increased by one.
> > > So, total refcount is 4.
> > > However, rds_message_put is called three times, in rds_send_probe,
> > > rds_send_remove_from_sock and rds_send_xmit functions. It seems
> > > that
> > > one more rds_message_put is needed.
> > > Would you please check and share your comments on this issue?
> > 
> > Do you have a proposed patch that syzbot can test to verify if this
> > is
> > correct or not?
> > 
> > thanks,
> > 
> > gre gk-h
> 
> Hi Greg,
> 
> Actually, using the .config and the C reproducer, syzbot reports the
> memory leak in rds_send_probe function. Also by enabling
> CONFIG_RDS_DEBUG=y, the debug messages indicates the similar as I
> mentioned above. To give an example, below is the RDS_DEBUG messages.
> Allocated address 8a7476e5 has initial ref_count 1. Then there
> are three rds_message_addref calls for the same address making the
> refcount 4, but only three rds_message_put calls which leave the
> address still allocated.
> 
> [   60.570681] rds_message_addref(): addref rm 8a7476e5 ref 1
> [   60.570707] rds_message_put(): put rm 8a7476e5 ref 2
> [   60.570845] rds_message_addref(): addref rm 8a7476e5 ref 1
> [   60.570870] rds_message_addref(): addref rm 8a7476e5 ref 2
> [   60.570960] rds_message_put(): put rm 8a7476e5 ref 3
> [   60.570995] rds_message_put(): put rm 8a7476e5 ref 2
> 

Ok, so the next step is to try your proposed change to see if it works
or not.  What prevents you from doign that?

No need to ask people if your analysis of an issue is true or not, no
maintainer or developer usually has the time to deal with that.  We much
rather would like to see patches of things you have tested to resolve
issues.

thanks,

greg k-h

Re: [PATCH v3 1/5] thermal/drivers/core: Use a char pointer for the cooling device name

[Ido Schimmel]

On Sun, Mar 14, 2021 at 12:13:29PM +0100, Daniel Lezcano wrote:
> We want to have any kind of name for the cooling devices as we do no
> longer want to rely on auto-numbering. Let's replace the cooling
> device's fixed array by a char pointer to be allocated dynamically
> when registering the cooling device, so we don't limit the length of
> the name.
> 
> Rework the error path at the same time as we have to rollback the
> allocations in case of error.
> 
> Tested with a dummy device having the name:
>  "Llanfairpwllgwyngyllgogerychwyrndrobwantysiliogogogoch"
> 
> A village on the island of Anglesey (Wales), known to have the longest
> name in Europe.
> 
> Signed-off-by: Daniel Lezcano 
> Reviewed-by: Lukasz Luba 

Tested-by: Ido Schimmel 

Re: [PATCH 2/5] mm/page_alloc: Add a bulk page allocator

[Mel Gorman]

On Sat, Mar 13, 2021 at 07:33:43PM +, Matthew Wilcox wrote:
> On Sat, Mar 13, 2021 at 04:56:31PM +, Chuck Lever III wrote:
> > IME lists are indeed less CPU-efficient, but I wonder if that
> > expense is insignificant compared to serialization primitives like
> > disabling and re-enabling IRQs, which we are avoiding by using
> > bulk page allocation.
> 
> Cache misses are a worse problem than serialisation.  Paul McKenney had
> a neat demonstration where he took a sheet of toilet paper to represent
> an instruction, and then unrolled two rolls of toilet paper around the
> lecture theatre to represent an L3 cache miss.  Obviously a serialising
> instruction is worse than an add instruction, but i'm thinking maybe
> 50-100 sheets of paper, not an entire roll?
> 

I'm well array of the advantages of arrays over lists. The reality is that
the penalty is incurred unconditionally as the pages have to be removed
from the per-cpu or buddy lists and the cache footprint of the allocator
and the data copies are already large. It's also the case that bulk free
interfaces already exist that operate on lists (free_unref_page_list)
so there is existing precedent. The bulk free API in this series was not
used by the callers so I've deleted it.

Obviously the callers would need to be adjusted to use the array
interface. The sunrpc user has an array but it is coded in a way that
expects the array could be partially populated or has holes so the API has
to skip populated elements. The caller is responsible for making sure that
there are enough NULL elements available to store nr_pages or the buffer
overruns. nr_elements could be passed in to avoid the buffer overrun but
then further logic is needed to distinguish between a failed allocation
and a failure to have enough space in the array to store the pointer.
It also means that prep_new_page() should not be deferred outside of
the IRQ disabled section as it does not have the storage to track which
pages were freshly allocated and which ones were already on the array. It
could be tracked using the lower bit of the pointer but that is not free
either. Ideally the callers simply would ensure the array does not have
valid struct page pointers in it already so prepping the new page could
always be deferred.  Obviously the callers are also responsible for
ensuring protecting the array from parallel access if necessary while
calling into the allocator.

> Anyway, I'm not arguing against a bulk allocator, nor even saying this
> is a bad interface.  It just maybe could be better.
> 

I think it puts more responsibility on the caller to use the API correctly
but I also see no value in arguing about it further because there is no
supporting data either way (I don't have routine access to a sufficiently
fast network to generate the data). I can add the following patch and let
callers figure out which interface is preferred. If one of the interfaces
is dead in a year, it can be removed.

As there are a couple of ways the arrays could be used, I'm leaving it
up to Jesper and Chuck which interface they want to use. In particular,
it would be preferred if the array has no valid struct pages in it but
it's up to them to judge how practical that is.

Patch is only lightly tested with a poor conversion of the sunrpc code
to use the array interface.

---8<---
mm/page_alloc: Add an array-based interface to the bulk page allocator

The existing callers for the bulk allocator are storing the pages in
arrays. This patch adds an array-based interface to the API to avoid
multiple list iterations. The page list interface is preserved to
avoid requiring all users of the bulk API to allocate and manage
enough storage to store the pages.

Signed-off-by: Mel Gorman 

diff --git a/include/linux/gfp.h b/include/linux/gfp.h
index 4a304fd39916..fb6234e1fe59 100644
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -520,13 +520,20 @@ struct page *__alloc_pages(gfp_t gfp, unsigned int order, 
int preferred_nid,
 
 int __alloc_pages_bulk(gfp_t gfp, int preferred_nid,
nodemask_t *nodemask, int nr_pages,
-   struct list_head *list);
+   struct list_head *page_list,
+   struct page **page_array);
 
 /* Bulk allocate order-0 pages */
 static inline unsigned long
-alloc_pages_bulk(gfp_t gfp, unsigned long nr_pages, struct list_head *list)
+alloc_pages_bulk_list(gfp_t gfp, unsigned long nr_pages, struct list_head 
*list)
 {
-   return __alloc_pages_bulk(gfp, numa_mem_id(), NULL, nr_pages, list);
+   return __alloc_pages_bulk(gfp, numa_mem_id(), NULL, nr_pages, list, 
NULL);
+}
+
+static inline unsigned long
+alloc_pages_bulk_array(gfp_t gfp, unsigned long nr_pages, struct page 
**page_array)
+{
+   return __alloc_pages_bulk(gfp, numa_mem_id(), NULL, nr_pages, NULL, 
page_array);
 }
 
 /*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 3e0c87c588d3..96590f0726c7 100644
--- a/m

[PATCH 1/4] habanalabs/gaudi: unsecure TPC cfg status registers

[Oded Gabbay]

From: Ofir Bitton 

Unsecure relevant registers as TPC engine need access to
TPC status.

Signed-off-by: Ofir Bitton 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/misc/habanalabs/gaudi/gaudi_security.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/misc/habanalabs/gaudi/gaudi_security.c 
b/drivers/misc/habanalabs/gaudi/gaudi_security.c
index 7085f45814ae..9a706c5980ef 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi_security.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi_security.c
@@ -9556,7 +9556,6 @@ static void gaudi_init_tpc_protection_bits(struct 
hl_device *hdev)
mask = 1U << ((mmTPC0_CFG_PROT & 0x7F) >> 2);
mask |= 1U << ((mmTPC0_CFG_VFLAGS & 0x7F) >> 2);
mask |= 1U << ((mmTPC0_CFG_SFLAGS & 0x7F) >> 2);
-   mask |= 1U << ((mmTPC0_CFG_STATUS & 0x7F) >> 2);
mask |= 1U << ((mmTPC0_CFG_CFG_BASE_ADDRESS_HIGH & 0x7F) >> 2);
mask |= 1U << ((mmTPC0_CFG_CFG_SUBTRACT_VALUE & 0x7F) >> 2);
mask |= 1U << ((mmTPC0_CFG_TPC_STALL & 0x7F) >> 2);
@@ -10011,7 +10010,6 @@ static void gaudi_init_tpc_protection_bits(struct 
hl_device *hdev)
mask = 1U << ((mmTPC1_CFG_PROT & 0x7F) >> 2);
mask |= 1U << ((mmTPC1_CFG_VFLAGS & 0x7F) >> 2);
mask |= 1U << ((mmTPC1_CFG_SFLAGS & 0x7F) >> 2);
-   mask |= 1U << ((mmTPC1_CFG_STATUS & 0x7F) >> 2);
mask |= 1U << ((mmTPC1_CFG_CFG_BASE_ADDRESS_HIGH & 0x7F) >> 2);
mask |= 1U << ((mmTPC1_CFG_CFG_SUBTRACT_VALUE & 0x7F) >> 2);
mask |= 1U << ((mmTPC1_CFG_TPC_STALL & 0x7F) >> 2);
@@ -10465,7 +10463,6 @@ static void gaudi_init_tpc_protection_bits(struct 
hl_device *hdev)
mask = 1U << ((mmTPC2_CFG_PROT & 0x7F) >> 2);
mask |= 1U << ((mmTPC2_CFG_VFLAGS & 0x7F) >> 2);
mask |= 1U << ((mmTPC2_CFG_SFLAGS & 0x7F) >> 2);
-   mask |= 1U << ((mmTPC2_CFG_STATUS & 0x7F) >> 2);
mask |= 1U << ((mmTPC2_CFG_CFG_BASE_ADDRESS_HIGH & 0x7F) >> 2);
mask |= 1U << ((mmTPC2_CFG_CFG_SUBTRACT_VALUE & 0x7F) >> 2);
mask |= 1U << ((mmTPC2_CFG_TPC_STALL & 0x7F) >> 2);
@@ -10919,7 +10916,6 @@ static void gaudi_init_tpc_protection_bits(struct 
hl_device *hdev)
mask = 1U << ((mmTPC3_CFG_PROT & 0x7F) >> 2);
mask |= 1U << ((mmTPC3_CFG_VFLAGS & 0x7F) >> 2);
mask |= 1U << ((mmTPC3_CFG_SFLAGS & 0x7F) >> 2);
-   mask |= 1U << ((mmTPC3_CFG_STATUS & 0x7F) >> 2);
mask |= 1U << ((mmTPC3_CFG_CFG_BASE_ADDRESS_HIGH & 0x7F) >> 2);
mask |= 1U << ((mmTPC3_CFG_CFG_SUBTRACT_VALUE & 0x7F) >> 2);
mask |= 1U << ((mmTPC3_CFG_TPC_STALL & 0x7F) >> 2);
@@ -11373,7 +11369,6 @@ static void gaudi_init_tpc_protection_bits(struct 
hl_device *hdev)
mask = 1U << ((mmTPC4_CFG_PROT & 0x7F) >> 2);
mask |= 1U << ((mmTPC4_CFG_VFLAGS & 0x7F) >> 2);
mask |= 1U << ((mmTPC4_CFG_SFLAGS & 0x7F) >> 2);
-   mask |= 1U << ((mmTPC4_CFG_STATUS & 0x7F) >> 2);
mask |= 1U << ((mmTPC4_CFG_CFG_BASE_ADDRESS_HIGH & 0x7F) >> 2);
mask |= 1U << ((mmTPC4_CFG_CFG_SUBTRACT_VALUE & 0x7F) >> 2);
mask |= 1U << ((mmTPC4_CFG_TPC_STALL & 0x7F) >> 2);
@@ -11827,7 +11822,6 @@ static void gaudi_init_tpc_protection_bits(struct 
hl_device *hdev)
mask = 1U << ((mmTPC5_CFG_PROT & 0x7F) >> 2);
mask |= 1U << ((mmTPC5_CFG_VFLAGS & 0x7F) >> 2);
mask |= 1U << ((mmTPC5_CFG_SFLAGS & 0x7F) >> 2);
-   mask |= 1U << ((mmTPC5_CFG_STATUS & 0x7F) >> 2);
mask |= 1U << ((mmTPC5_CFG_CFG_BASE_ADDRESS_HIGH & 0x7F) >> 2);
mask |= 1U << ((mmTPC5_CFG_CFG_SUBTRACT_VALUE & 0x7F) >> 2);
mask |= 1U << ((mmTPC5_CFG_TPC_STALL & 0x7F) >> 2);
@@ -12283,7 +12277,6 @@ static void gaudi_init_tpc_protection_bits(struct 
hl_device *hdev)
mask = 1U << ((mmTPC6_CFG_PROT & 0x7F) >> 2);
mask |= 1U << ((mmTPC6_CFG_VFLAGS & 0x7F) >> 2);
mask |= 1U << ((mmTPC6_CFG_SFLAGS & 0x7F) >> 2);
-   mask |= 1U << ((mmTPC6_CFG_STATUS & 0x7F) >> 2);
mask |= 1U << ((mmTPC6_CFG_CFG_BASE_ADDRESS_HIGH & 0x7F) >> 2);
mask |= 1U << ((mmTPC6_CFG_CFG_SUBTRACT_VALUE & 0x7F) >> 2);
mask |= 1U << ((mmTPC6_CFG_TPC_STALL & 0x7F) >> 2);
@@ -12739,7 +12732,6 @@ static void gaudi_init_tpc_protection_bits(struct 
hl_device *hdev)
mask = 1U << ((mmTPC7_CFG_PROT & 0x7F) >> 2);
mask |= 1U << ((mmTPC7_CFG_VFLAGS & 0x7F) >> 2);
mask |= 1U << ((mmTPC7_CFG_SFLAGS & 0x7F) >> 2);
-   mask |= 1U << ((mmTPC7_CFG_STATUS & 0x7F) >> 2);
mask |= 1U << ((mmTPC7_CFG_CFG_BASE_ADDRESS_HIGH & 0x7F) >> 2);
mask |= 1U << ((mmTPC7_CFG_CFG_SUBTRACT_VALUE & 0x7F) >> 2);
mask |= 1U << ((mmTPC7_CFG_TPC_STALL & 0x7F) >> 2);
-- 
2.25.1

[PATCH 2/4] habanalabs/gaudi: Update async events header

[Oded Gabbay]

From: Ofir Bitton 

Update with latest version from the Firmware team.

Signed-off-by: Ofir Bitton 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/misc/habanalabs/gaudi/gaudi.c |  2 +-
 .../include/gaudi/gaudi_async_events.h|  2 +-
 .../gaudi/gaudi_async_ids_map_extended.h  | 35 ---
 3 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/drivers/misc/habanalabs/gaudi/gaudi.c 
b/drivers/misc/habanalabs/gaudi/gaudi.c
index 0bcee675e1db..a65ae0dbdb92 100644
--- a/drivers/misc/habanalabs/gaudi/gaudi.c
+++ b/drivers/misc/habanalabs/gaudi/gaudi.c
@@ -7574,7 +7574,7 @@ static void gaudi_handle_eqe(struct hl_device *hdev,
event_type, cause);
break;
 
-   case GAUDI_EVENT_BMC_RESET_CMD:
+   case GAUDI_EVENT_DEV_RESET_REQ:
gaudi_print_irq_info(hdev, event_type, false);
goto reset_device;
 
diff --git a/drivers/misc/habanalabs/include/gaudi/gaudi_async_events.h 
b/drivers/misc/habanalabs/include/gaudi/gaudi_async_events.h
index 25f835ba2cd6..e8651abf84f2 100644
--- a/drivers/misc/habanalabs/include/gaudi/gaudi_async_events.h
+++ b/drivers/misc/habanalabs/include/gaudi/gaudi_async_events.h
@@ -303,7 +303,7 @@ enum gaudi_async_event_id {
GAUDI_EVENT_NIC3_QP1 = 619,
GAUDI_EVENT_NIC4_QP0 = 620,
GAUDI_EVENT_NIC4_QP1 = 621,
-   GAUDI_EVENT_BMC_RESET_CMD = 646,
+   GAUDI_EVENT_DEV_RESET_REQ = 646,
GAUDI_EVENT_PKT_QUEUE_OUT_SYNC = 647,
GAUDI_EVENT_FIX_POWER_ENV_S = 658,
GAUDI_EVENT_FIX_POWER_ENV_E = 659,
diff --git 
a/drivers/misc/habanalabs/include/gaudi/gaudi_async_ids_map_extended.h 
b/drivers/misc/habanalabs/include/gaudi/gaudi_async_ids_map_extended.h
index 079be1fb8f70..3dc79c131805 100644
--- a/drivers/misc/habanalabs/include/gaudi/gaudi_async_ids_map_extended.h
+++ b/drivers/misc/habanalabs/include/gaudi/gaudi_async_ids_map_extended.h
@@ -670,18 +670,29 @@ static struct gaudi_async_events_ids_map 
gaudi_irq_map_table[] = {
{ .fc_id = 643, .cpu_id = 492, .valid = 0, .name = "" },
{ .fc_id = 644, .cpu_id = 493, .valid = 0, .name = "" },
{ .fc_id = 645, .cpu_id = 494, .valid = 0, .name = "" },
-   { .fc_id = 646, .cpu_id = 495, .valid = 1, .name = "BMC_RST_CMD" },
-   { .fc_id = 647, .cpu_id = 496, .valid = 0, .name = "" },
-   { .fc_id = 648, .cpu_id = 497, .valid = 0, .name = "" },
-   { .fc_id = 649, .cpu_id = 498, .valid = 0, .name = "" },
-   { .fc_id = 650, .cpu_id = 499, .valid = 0, .name = "" },
-   { .fc_id = 651, .cpu_id = 500, .valid = 0, .name = "" },
-   { .fc_id = 652, .cpu_id = 501, .valid = 0, .name = "" },
-   { .fc_id = 653, .cpu_id = 502, .valid = 0, .name = "" },
-   { .fc_id = 654, .cpu_id = 503, .valid = 0, .name = "" },
-   { .fc_id = 655, .cpu_id = 504, .valid = 0, .name = "" },
-   { .fc_id = 656, .cpu_id = 505, .valid = 0, .name = "" },
-   { .fc_id = 657, .cpu_id = 506, .valid = 1, .name = "PKT_QUEUE_ASYNC" },
+   { .fc_id = 646, .cpu_id = 495, .valid = 1, .name = "DEV_RESET_REQ" },
+   { .fc_id = 647, .cpu_id = 496, .valid = 1,
+   .name = "PKT_QUEUE_OUT_SYNC" },
+   { .fc_id = 648, .cpu_id = 497, .valid = 1,
+   .name = "STATUS_NIC0_ENG0" },
+   { .fc_id = 649, .cpu_id = 498, .valid = 1,
+   .name = "STATUS_NIC0_ENG1" },
+   { .fc_id = 650, .cpu_id = 499, .valid = 1,
+   .name = "STATUS_NIC1_ENG0" },
+   { .fc_id = 651, .cpu_id = 500, .valid = 1,
+   .name = "STATUS_NIC1_ENG1" },
+   { .fc_id = 652, .cpu_id = 501, .valid = 1,
+   .name = "STATUS_NIC2_ENG0" },
+   { .fc_id = 653, .cpu_id = 502, .valid = 1,
+   .name = "STATUS_NIC2_ENG1" },
+   { .fc_id = 654, .cpu_id = 503, .valid = 1,
+   .name = "STATUS_NIC3_ENG0" },
+   { .fc_id = 655, .cpu_id = 504, .valid = 1,
+   .name = "STATUS_NIC3_ENG1" },
+   { .fc_id = 656, .cpu_id = 505, .valid = 1,
+   .name = "STATUS_NIC4_ENG0" },
+   { .fc_id = 657, .cpu_id = 506, .valid = 1,
+   .name = "STATUS_NIC4_ENG1" },
{ .fc_id = 658, .cpu_id = 507, .valid = 1, .name = "FIX_POWER_ENV_S" },
{ .fc_id = 659, .cpu_id = 508, .valid = 1, .name = "FIX_POWER_ENV_E" },
{ .fc_id = 660, .cpu_id = 509, .valid = 1,
-- 
2.25.1

[PATCH 4/4] habanalabs: support dynamic PLL numbering

[Oded Gabbay]

From: Ohad Sharabi 

As part of the effort remove hard-coded assumptions from the F/W-driver
communication, introduce support for dynamic pll numbering.

Signed-off-by: Ohad Sharabi 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/misc/habanalabs/common/firmware_if.c  | 22 +-
 drivers/misc/habanalabs/common/habanalabs.h   |  2 +-
 .../misc/habanalabs/include/common/cpucp_if.h | 41 +++
 .../habanalabs/include/gaudi/gaudi_fw_if.h| 14 ---
 .../misc/habanalabs/include/goya/goya_fw_if.h | 11 -
 5 files changed, 62 insertions(+), 28 deletions(-)

diff --git a/drivers/misc/habanalabs/common/firmware_if.c 
b/drivers/misc/habanalabs/common/firmware_if.c
index 2a58edaf984a..8843e040c660 100644
--- a/drivers/misc/habanalabs/common/firmware_if.c
+++ b/drivers/misc/habanalabs/common/firmware_if.c
@@ -539,18 +539,36 @@ int hl_fw_cpucp_total_energy_get(struct hl_device *hdev, 
u64 *total_energy)
return rc;
 }
 
-int hl_fw_cpucp_pll_info_get(struct hl_device *hdev, u16 pll_index,
+int hl_fw_cpucp_pll_info_get(struct hl_device *hdev, enum pll_index pll_index,
u16 *pll_freq_arr)
 {
+   struct asic_fixed_properties *prop = &hdev->asic_prop;
+   u8 pll_byte, pll_bit_off;
struct cpucp_packet pkt;
u64 result;
int rc;
 
+   if (pll_index >= PLL_MAX) {
+   dev_err(hdev->dev, "PLL index %d is out of range\n",
+   pll_index);
+   return -EINVAL;
+   }
+
+   /* PLL map is a u8 array */
+   pll_byte = prop->cpucp_info.pll_map[pll_index >> 3];
+   pll_bit_off = pll_index & 0x7;
+
+   if (!(pll_byte & BIT(pll_bit_off))) {
+   dev_err(hdev->dev, "PLL index %d is not supported\n",
+   pll_index);
+   return -EINVAL;
+   }
+
memset(&pkt, 0, sizeof(pkt));
 
pkt.ctl = cpu_to_le32(CPUCP_PACKET_PLL_INFO_GET <<
CPUCP_PKT_CTL_OPCODE_SHIFT);
-   pkt.pll_type = __cpu_to_le16(pll_index);
+   pkt.pll_type = __cpu_to_le16((u16)pll_index);
 
rc = hdev->asic_funcs->send_cpu_message(hdev, (u32 *) &pkt, sizeof(pkt),
HL_CPUCP_INFO_TIMEOUT_USEC, &result);
diff --git a/drivers/misc/habanalabs/common/habanalabs.h 
b/drivers/misc/habanalabs/common/habanalabs.h
index 2dcefd6485e5..5f930cb5e33d 100644
--- a/drivers/misc/habanalabs/common/habanalabs.h
+++ b/drivers/misc/habanalabs/common/habanalabs.h
@@ -2379,7 +2379,7 @@ int hl_fw_cpucp_pci_counters_get(struct hl_device *hdev,
struct hl_info_pci_counters *counters);
 int hl_fw_cpucp_total_energy_get(struct hl_device *hdev,
u64 *total_energy);
-int hl_fw_cpucp_pll_info_get(struct hl_device *hdev, u16 pll_index,
+int hl_fw_cpucp_pll_info_get(struct hl_device *hdev, enum pll_index pll_index,
u16 *pll_freq_arr);
 int hl_fw_cpucp_power_get(struct hl_device *hdev, u64 *power);
 int hl_fw_init_cpu(struct hl_device *hdev, u32 cpu_boot_status_reg,
diff --git a/drivers/misc/habanalabs/include/common/cpucp_if.h 
b/drivers/misc/habanalabs/include/common/cpucp_if.h
index 6ba480a316ce..e745c78dd8fd 100644
--- a/drivers/misc/habanalabs/include/common/cpucp_if.h
+++ b/drivers/misc/habanalabs/include/common/cpucp_if.h
@@ -28,6 +28,9 @@
 #define CPUCP_PKT_HBM_ECC_INFO_HBM_CH_SHIFT6
 #define CPUCP_PKT_HBM_ECC_INFO_HBM_CH_MASK 0x07C0
 
+#define PLL_MAP_MAX_BITS   128
+#define PLL_MAP_LEN(PLL_MAP_MAX_BITS / 8)
+
 /*
  * info of the pkt queue pointers in the first async occurrence
  */
@@ -473,6 +476,42 @@ enum cpucp_pll_type_attributes {
cpucp_pll_pci,
 };
 
+/*
+ * PLL enumeration table used for all ASICs and future SW versions.
+ * For future ASIC-LKD compatibility, we can only add new enumerations.
+ * at the end of the table.
+ * Changing the order of entries or removing entries is not allowed.
+ */
+enum pll_index {
+   CPU_PLL = 0,
+   PCI_PLL = 1,
+   NIC_PLL = 2,
+   DMA_PLL = 3,
+   MESH_PLL = 4,
+   MME_PLL = 5,
+   TPC_PLL = 6,
+   IF_PLL = 7,
+   SRAM_PLL = 8,
+   NS_DCORE_PLL = 9,
+   MESH_DCORE_PLL = 10,
+   HBM_PLL = 11,
+   TPC_DCORE_PLL = 12,
+   VIDEO_DCORE_PLL = 13,
+   SRAM_DCORE_PLL = 14,
+   NIC_PHY_DCORE_PLL = 15,
+   MSS_DCORE_PLL = 16,
+   DMA_DCORE_PLL = 17,
+   SIF_PLL = 18,
+   DDR_PLL = 19,
+   VID_PLL = 20,
+   BANK_PLL = 21,
+   MMU_PLL = 22,
+   IC_PLL = 23,
+   MC_PLL = 24,
+   EMMC_PLL = 25,
+   PLL_MAX
+};
+
 /* Event Queue Packets */
 
 struct eq_generic_event {
@@ -547,6 +586,7 @@ struct cpucp_security_info {
  * @dram_size: available DRAM size.
  * @card_name: card name that will be displayed in HWMON subsystem on the host
  * @sec_info: security information
+ * @pll_map: Bit map of supported P

[PATCH 3/4] habanalabs: avoid soft lockup bug upon mapping error

[Oded Gabbay]

From: farah kassabri 

Add a little sleep between page unmappings in case mapping of
large number of host pages failed, in order to
avoid soft lockup bug during the rollback.

Signed-off-by: farah kassabri 
Reviewed-by: Oded Gabbay 
Signed-off-by: Oded Gabbay 
---
 drivers/misc/habanalabs/common/memory.c | 20 +---
 1 file changed, 17 insertions(+), 3 deletions(-)

diff --git a/drivers/misc/habanalabs/common/memory.c 
b/drivers/misc/habanalabs/common/memory.c
index 1b69573369cf..6530fddbbc21 100644
--- a/drivers/misc/habanalabs/common/memory.c
+++ b/drivers/misc/habanalabs/common/memory.c
@@ -857,6 +857,7 @@ static int map_phys_pg_pack(struct hl_ctx *ctx, u64 vaddr,
u64 next_vaddr = vaddr, paddr, mapped_pg_cnt = 0, i;
u32 page_size = phys_pg_pack->page_size;
int rc = 0;
+   bool is_host_addr;
 
for (i = 0 ; i < phys_pg_pack->npages ; i++) {
paddr = phys_pg_pack->pages[i];
@@ -878,6 +879,8 @@ static int map_phys_pg_pack(struct hl_ctx *ctx, u64 vaddr,
return 0;
 
 err:
+   is_host_addr = !hl_is_dram_va(hdev, vaddr);
+
next_vaddr = vaddr;
for (i = 0 ; i < mapped_pg_cnt ; i++) {
if (hl_mmu_unmap_page(ctx, next_vaddr, page_size,
@@ -888,6 +891,17 @@ static int map_phys_pg_pack(struct hl_ctx *ctx, u64 vaddr,
phys_pg_pack->pages[i], page_size);
 
next_vaddr += page_size;
+
+   /*
+* unmapping on Palladium can be really long, so avoid a CPU
+* soft lockup bug by sleeping a little between unmapping pages
+*
+* In addition, on host num of pages could be huge,
+* because page size could be 4KB, so when unmapping host
+* pages sleep every 32K pages to avoid soft lockup
+*/
+   if (hdev->pldm || (is_host_addr && (i & 0x7FFF) == 0))
+   usleep_range(50, 200);
}
 
return rc;
@@ -921,9 +935,9 @@ static void unmap_phys_pg_pack(struct hl_ctx *ctx, u64 
vaddr,
 * unmapping on Palladium can be really long, so avoid a CPU
 * soft lockup bug by sleeping a little between unmapping pages
 *
-* In addition, when unmapping host memory we pass through
-* the Linux kernel to unpin the pages and that takes a long
-* time. Therefore, sleep every 32K pages to avoid soft lockup
+* In addition, on host num of pages could be huge,
+* because page size could be 4KB, so when unmapping host
+* pages sleep every 32K pages to avoid soft lockup
 */
if (hdev->pldm || (is_host_addr && (i & 0x7FFF) == 0))
usleep_range(50, 200);
-- 
2.25.1