[PATCH 0/3] staging: rtl8723bs: hal: Rectify with Linux kernel coding style

[Beatriz Martins de Carvalho]

This patchset rectifies the file Hal8723BReg.h with Linux kernel coding style.
The issues were:
- Space before tabs;
- Extra blank line;
- Indentation problem.
 

Beatriz Martins de Carvalho (3):
  staging: rtl8723bs: hal: remove space before tabs
  staging: rtl8723bs: hal: Remove extra blank line
  staging: rtl8723bs: hal: Correct indentation

 drivers/staging/rtl8723bs/hal/Hal8723BReg.h | 421 ++--
 1 file changed, 208 insertions(+), 213 deletions(-)

-- 
2.25.1

Re: Linux Kernel build bug with AMD_IOMMU_V2=M and HSA_AMD=Y

[Felix Kuehling]

This should have been fixed by this commit in amd-staging-drm-next: 
https://lore.kernel.org/patchwork/patch/1392368/


commit b8aff1f3a0b3d8434f8ccf5d3017137c29aca77b
Author: Felix Kuehling 
Date:   Mon Mar 8 22:15:42 2021 -0500

drm/amdkfd: fix build error with AMD_IOMMU_V2=m

Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link

against the exported functions. If the GPU driver is built-in but the
IOMMU driver is a loadable module, the kfd_iommu.c file is indeed
built but does not work:

x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_bind_process_to_device':

kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function 
`kfd_iommu_unbind_process':
kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function 
`kfd_iommu_suspend':
kfd_iommu.c:(.text+0x966): undefined reference to 
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to 
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to 
`amd_iommu_free_device'
x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function 
`kfd_iommu_resume':
kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device'
x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to 
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to 
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to 
`amd_iommu_bind_pasid'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to 
`amd_iommu_set_invalidate_ctx_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to 
`amd_iommu_set_invalid_ppr_cb'
x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to 
`amd_iommu_free_device'

Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols

are reachable by the amdkfd driver. Output a warning if they are not,
because that may not be what the user was expecting.

Fixes: 64d1c3a43a6f ("drm/amdkfd: Centralize IOMMUv2 code and make it conditional")

Reported-by: Arnd Bergmann 
Signed-off-by: Felix Kuehling 
Reviewed-by: Christian König 

Regards,
  Felix

On 2021-04-08 7:04 p.m., David Niklas wrote:

Hello,
(There are so many maintainers for kfd_iommu.c I feel like I'm spamming.)

When compiling for Linux version 5.11.12 using the AMDGPU GPU driver
with HSA_AMD enabled, I get the below set of errors. To work around this,
I need to change AMD_IOMMU_V2 from M to Y. This bug doesn't affect linux
kernel version 5.6 as it requires AMD_IOMMU_V2 to by Y when HSA_AMD is
enabled.
I'd bisect and request the removal of the relevant patch, but it's
possible that building the linux kernel should work this way and so a fix,
not a patch removal, is what should be issued.
I'm attaching my kernel config for 5.11.

Thanks,
David

PS: I made an official bug report in case you'd prefer that:
https://bugzilla.kernel.org/show_bug.cgi?id=212619

drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: In function
`kfd_iommu_bind_process_to_device': 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:120:
undefined reference to `amd_iommu_bind_pasid'
drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: In function
`kfd_iommu_unbind_process': 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:138:
undefined reference to `amd_iommu_unbind_pasid'
drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: In function
`kfd_iommu_suspend': 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:292:
undefined reference to
`amd_iommu_set_invalidate_ctx_cb' 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:293:
undefined reference to `amd_iommu_set_invalid_ppr_cb'
drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: In function
`kfd_iommu_resume': 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:312:
undefined reference to
`amd_iommu_init_device' 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:316:
undefined reference to
`amd_iommu_set_invalidate_ctx_cb' 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:318:
undefined reference to
`amd_iommu_set_invalid_ppr_cb' 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:323:
undefined reference to
`amd_iommu_set_invalidate_ctx_cb' 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:324:
undefined reference to
`amd_iommu_set_invalid_ppr_cb' 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:325:
undefined reference to
`amd_iommu_free_device' 
/root/working/linux-5.11.12/drivers/g

Linux Kernel build bug with AMD_IOMMU_V2=M and HSA_AMD=Y

[David Niklas]

Hello,
(There are so many maintainers for kfd_iommu.c I feel like I'm spamming.)

When compiling for Linux version 5.11.12 using the AMDGPU GPU driver
with HSA_AMD enabled, I get the below set of errors. To work around this,
I need to change AMD_IOMMU_V2 from M to Y. This bug doesn't affect linux
kernel version 5.6 as it requires AMD_IOMMU_V2 to by Y when HSA_AMD is
enabled.
I'd bisect and request the removal of the relevant patch, but it's
possible that building the linux kernel should work this way and so a fix,
not a patch removal, is what should be issued.
I'm attaching my kernel config for 5.11.

Thanks,
David

PS: I made an official bug report in case you'd prefer that:
https://bugzilla.kernel.org/show_bug.cgi?id=212619

drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: In function
`kfd_iommu_bind_process_to_device': 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:120:
undefined reference to `amd_iommu_bind_pasid'
drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: In function
`kfd_iommu_unbind_process': 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:138:
undefined reference to `amd_iommu_unbind_pasid'
drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: In function
`kfd_iommu_suspend': 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:292:
undefined reference to
`amd_iommu_set_invalidate_ctx_cb' 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:293:
undefined reference to `amd_iommu_set_invalid_ppr_cb'
drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: In function
`kfd_iommu_resume': 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:312:
undefined reference to
`amd_iommu_init_device' 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:316:
undefined reference to
`amd_iommu_set_invalidate_ctx_cb' 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:318:
undefined reference to
`amd_iommu_set_invalid_ppr_cb' 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:323:
undefined reference to
`amd_iommu_set_invalidate_ctx_cb' 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:324:
undefined reference to
`amd_iommu_set_invalid_ppr_cb' 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:325:
undefined reference to
`amd_iommu_free_device' 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:232:
undefined reference to `amd_iommu_bind_pasid'
drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: In function
`kfd_iommu_suspend': 
/root/working/linux-5.11.12/drivers/gpu/drm/amd/amdgpu/../amdkfd/kfd_iommu.c:294:
undefined reference to `amd_iommu_free_device' Makefile:1166: recipe for
target 'vmlinux' failed make: *** [vmlinux] Error 1


kernel-build-amdgpu-bug.conf.xz
Description: application/xz

[PATCH V3 4/4] remoteproc: imx_rproc: support remote cores booted before Linux Kernel

[peng . fan]

From: Peng Fan 

 - When remote cores are kicked before Linux Kernel, we are not able
   to get resource table from the firmware elf file, so we need to add
   rsc_table to hold the resource table published by remote cores and
   imx_rproc_get_loaded_rsc_table is to get the resource table.
 - Per remoteproc framework, add attach hook for processor in a detached
   state.
 - Add imx_rproc_detect_mode to detect remote cores' working mode to
   set the state which is required by remoteproc framework.

Reviewed-by: Mathieu Poirier 
Signed-off-by: Peng Fan 
---
 drivers/remoteproc/imx_rproc.c | 45 ++
 1 file changed, 45 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 7cd09971d1a4..d6338872c6db 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -95,6 +95,7 @@ struct imx_rproc {
struct mbox_chan*rx_ch;
struct work_struct  rproc_work;
struct workqueue_struct *workqueue;
+   void __iomem*rsc_table;
 };
 
 static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
@@ -395,8 +396,26 @@ static void imx_rproc_kick(struct rproc *rproc, int vqid)
__func__, vqid, err);
 }
 
+static int imx_rproc_attach(struct rproc *rproc)
+{
+   return 0;
+}
+
+static struct resource_table *imx_rproc_get_loaded_rsc_table(struct rproc 
*rproc, size_t *table_sz)
+{
+   struct imx_rproc *priv = rproc->priv;
+
+   /* The resource table has already been mapped in imx_rproc_addr_init */
+   if (!priv->rsc_table)
+   return NULL;
+
+   *table_sz = SZ_1K;
+   return (struct resource_table *)priv->rsc_table;
+}
+
 static const struct rproc_ops imx_rproc_ops = {
.prepare= imx_rproc_prepare,
+   .attach = imx_rproc_attach,
.start  = imx_rproc_start,
.stop   = imx_rproc_stop,
.kick   = imx_rproc_kick,
@@ -404,6 +423,7 @@ static const struct rproc_ops imx_rproc_ops = {
.load   = rproc_elf_load_segments,
.parse_fw   = imx_rproc_parse_fw,
.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
+   .get_loaded_rsc_table = imx_rproc_get_loaded_rsc_table,
.sanity_check   = rproc_elf_sanity_check,
.get_boot_addr  = rproc_elf_get_boot_addr,
 };
@@ -470,6 +490,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
}
priv->mem[b].sys_addr = res.start;
priv->mem[b].size = resource_size();
+   if (!strcmp(node->name, "rsc_table"))
+   priv->rsc_table = priv->mem[b].cpu_addr;
b++;
}
 
@@ -536,6 +558,25 @@ static void imx_rproc_free_mbox(struct rproc *rproc)
mbox_free_channel(priv->rx_ch);
 }
 
+static int imx_rproc_detect_mode(struct imx_rproc *priv)
+{
+   const struct imx_rproc_dcfg *dcfg = priv->dcfg;
+   struct device *dev = priv->dev;
+   int ret;
+   u32 val;
+
+   ret = regmap_read(priv->regmap, dcfg->src_reg, );
+   if (ret) {
+   dev_err(dev, "Failed to read src\n");
+   return ret;
+   }
+
+   if (!(val & dcfg->src_stop))
+   priv->rproc->state = RPROC_DETACHED;
+
+   return 0;
+}
+
 static int imx_rproc_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -590,6 +631,10 @@ static int imx_rproc_probe(struct platform_device *pdev)
goto err_put_mbox;
}
 
+   ret = imx_rproc_detect_mode(priv);
+   if (ret)
+   goto err_put_mbox;
+
priv->clk = devm_clk_get(dev, NULL);
if (IS_ERR(priv->clk)) {
dev_err(dev, "Failed to get clock\n");
-- 
2.30.0

Re: [PATCH V2 4/4] remoteproc: imx_rproc: support remote cores booted before Linux Kernel

[Mathieu Poirier]

On Tue, Mar 30, 2021 at 01:30:35PM +0800, peng@oss.nxp.com wrote:
> From: Peng Fan 
> 
>  - Add rsc_table to hold the resource table published by remote cores.
>  - Add attach hook.
>  - Add imx_rproc_get_loaded_rsc_table to get resource table published by
>remote processors.
>  - Add imx_rproc_detect_mode to detect remote cores' working mode.
>

This is describing _what_ is being done rather than _why_ it is done.

Moreover for patches 1 an 3 the subject line is tagged with "imx" while patches
2 and 4 have "imx_rproc".  I don't mind which one is used as long as it is
consistent.
 
> Signed-off-by: Peng Fan 
> ---
>  drivers/remoteproc/imx_rproc.c | 45 ++
>  1 file changed, 45 insertions(+)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 7cd09971d1a4..d6338872c6db 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -95,6 +95,7 @@ struct imx_rproc {
>   struct mbox_chan*rx_ch;
>   struct work_struct  rproc_work;
>   struct workqueue_struct *workqueue;
> + void __iomem*rsc_table;
>  };
>  
>  static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
> @@ -395,8 +396,26 @@ static void imx_rproc_kick(struct rproc *rproc, int vqid)
>   __func__, vqid, err);
>  }
>  
> +static int imx_rproc_attach(struct rproc *rproc)
> +{
> + return 0;
> +}
> +
> +static struct resource_table *imx_rproc_get_loaded_rsc_table(struct rproc 
> *rproc, size_t *table_sz)
> +{
> + struct imx_rproc *priv = rproc->priv;
> +
> + /* The resource table has already been mapped in imx_rproc_addr_init */
> + if (!priv->rsc_table)
> + return NULL;
> +
> + *table_sz = SZ_1K;
> + return (struct resource_table *)priv->rsc_table;
> +}
> +
>  static const struct rproc_ops imx_rproc_ops = {
>   .prepare= imx_rproc_prepare,
> + .attach = imx_rproc_attach,
>   .start  = imx_rproc_start,
>   .stop   = imx_rproc_stop,
>   .kick   = imx_rproc_kick,
> @@ -404,6 +423,7 @@ static const struct rproc_ops imx_rproc_ops = {
>   .load   = rproc_elf_load_segments,
>   .parse_fw   = imx_rproc_parse_fw,
>   .find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
> + .get_loaded_rsc_table = imx_rproc_get_loaded_rsc_table,
>   .sanity_check   = rproc_elf_sanity_check,
>   .get_boot_addr  = rproc_elf_get_boot_addr,
>  };
> @@ -470,6 +490,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
>   }
>   priv->mem[b].sys_addr = res.start;
>   priv->mem[b].size = resource_size();
> + if (!strcmp(node->name, "rsc_table"))
> + priv->rsc_table = priv->mem[b].cpu_addr;
>   b++;
>   }
>  
> @@ -536,6 +558,25 @@ static void imx_rproc_free_mbox(struct rproc *rproc)
>   mbox_free_channel(priv->rx_ch);
>  }
>  
> +static int imx_rproc_detect_mode(struct imx_rproc *priv)
> +{
> + const struct imx_rproc_dcfg *dcfg = priv->dcfg;
> + struct device *dev = priv->dev;
> + int ret;
> + u32 val;
> +
> + ret = regmap_read(priv->regmap, dcfg->src_reg, );
> + if (ret) {
> + dev_err(dev, "Failed to read src\n");
> + return ret;
> + }
> +
> + if (!(val & dcfg->src_stop))
> + priv->rproc->state = RPROC_DETACHED;
> +
> + return 0;
> +}
> +
>  static int imx_rproc_probe(struct platform_device *pdev)
>  {
>   struct device *dev = >dev;
> @@ -590,6 +631,10 @@ static int imx_rproc_probe(struct platform_device *pdev)
>   goto err_put_mbox;
>   }
>  
> + ret = imx_rproc_detect_mode(priv);
> + if (ret)
> + goto err_put_mbox;
> +

With the above:

Reviewed-by: Mathieu Poirier 

>   priv->clk = devm_clk_get(dev, NULL);
>   if (IS_ERR(priv->clk)) {
>   dev_err(dev, "Failed to get clock\n");
> -- 
> 2.30.0
> 

Re: Compiling Linux kernel into a build directory

[Randy Dunlap]

On 4/2/21 11:29 AM, James Courtier-Dutton wrote:
> Hi,
> 
> Currently, when one builds the linux kernel, it places .o files all
> over the source code tree.
> Is there a way to have the linux kernel build, but place all the .o
> files into a separate build folder?
> Similar to how cmake or ninja work when building C source code.
> 
> One possible advantage of this approach is one can then put the build
> folder on a ram disk / tmpfs   and be able to compile and test much
> quicker.

That has been available for quite a long time now.
Just use "O=somebuilddir" on the make command line.

$ mkdir build
$ make O=build allnoconfig
$ make O=build all

AFAIK 'somebuilddir' can be a relative path (that's what
I use, in the kernel source tree) or an absolute path,
like O=/tmp/buildit .

>From kernel Makefile "help":
@echo  '  make O=dir [targets] Locate all output files in "dir", 
including .config'


and from kernel Makefile comments:

# Kbuild will save output files in the current working directory.
# This does not need to match to the root of the kernel source tree.
#
# For example, you can do this:
#
#  cd /dir/to/store/output/files; make -f /dir/to/kernel/source/Makefile
#
# If you want to save output files in a different location, there are
# two syntaxes to specify it.
#
# 1) O=
# Use "make O=dir/to/store/output/files/"
#
# 2) Set KBUILD_OUTPUT
# Set the environment variable KBUILD_OUTPUT to point to the output directory.
# export KBUILD_OUTPUT=dir/to/store/output/files/; make
#
# The O= assignment takes precedence over the KBUILD_OUTPUT environment
# variable.


HTH.
-- 
~Randy

Compiling Linux kernel into a build directory

[James Courtier-Dutton]

Hi,

Currently, when one builds the linux kernel, it places .o files all
over the source code tree.
Is there a way to have the linux kernel build, but place all the .o
files into a separate build folder?
Similar to how cmake or ninja work when building C source code.

One possible advantage of this approach is one can then put the build
folder on a ram disk / tmpfs   and be able to compile and test much
quicker.

Kind Regards

James

[PATCH V2 4/4] remoteproc: imx_rproc: support remote cores booted before Linux Kernel

[peng . fan]

From: Peng Fan 

 - Add rsc_table to hold the resource table published by remote cores.
 - Add attach hook.
 - Add imx_rproc_get_loaded_rsc_table to get resource table published by
   remote processors.
 - Add imx_rproc_detect_mode to detect remote cores' working mode.

Signed-off-by: Peng Fan 
---
 drivers/remoteproc/imx_rproc.c | 45 ++
 1 file changed, 45 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 7cd09971d1a4..d6338872c6db 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -95,6 +95,7 @@ struct imx_rproc {
struct mbox_chan*rx_ch;
struct work_struct  rproc_work;
struct workqueue_struct *workqueue;
+   void __iomem*rsc_table;
 };
 
 static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
@@ -395,8 +396,26 @@ static void imx_rproc_kick(struct rproc *rproc, int vqid)
__func__, vqid, err);
 }
 
+static int imx_rproc_attach(struct rproc *rproc)
+{
+   return 0;
+}
+
+static struct resource_table *imx_rproc_get_loaded_rsc_table(struct rproc 
*rproc, size_t *table_sz)
+{
+   struct imx_rproc *priv = rproc->priv;
+
+   /* The resource table has already been mapped in imx_rproc_addr_init */
+   if (!priv->rsc_table)
+   return NULL;
+
+   *table_sz = SZ_1K;
+   return (struct resource_table *)priv->rsc_table;
+}
+
 static const struct rproc_ops imx_rproc_ops = {
.prepare= imx_rproc_prepare,
+   .attach = imx_rproc_attach,
.start  = imx_rproc_start,
.stop   = imx_rproc_stop,
.kick   = imx_rproc_kick,
@@ -404,6 +423,7 @@ static const struct rproc_ops imx_rproc_ops = {
.load   = rproc_elf_load_segments,
.parse_fw   = imx_rproc_parse_fw,
.find_loaded_rsc_table = rproc_elf_find_loaded_rsc_table,
+   .get_loaded_rsc_table = imx_rproc_get_loaded_rsc_table,
.sanity_check   = rproc_elf_sanity_check,
.get_boot_addr  = rproc_elf_get_boot_addr,
 };
@@ -470,6 +490,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
}
priv->mem[b].sys_addr = res.start;
priv->mem[b].size = resource_size();
+   if (!strcmp(node->name, "rsc_table"))
+   priv->rsc_table = priv->mem[b].cpu_addr;
b++;
}
 
@@ -536,6 +558,25 @@ static void imx_rproc_free_mbox(struct rproc *rproc)
mbox_free_channel(priv->rx_ch);
 }
 
+static int imx_rproc_detect_mode(struct imx_rproc *priv)
+{
+   const struct imx_rproc_dcfg *dcfg = priv->dcfg;
+   struct device *dev = priv->dev;
+   int ret;
+   u32 val;
+
+   ret = regmap_read(priv->regmap, dcfg->src_reg, );
+   if (ret) {
+   dev_err(dev, "Failed to read src\n");
+   return ret;
+   }
+
+   if (!(val & dcfg->src_stop))
+   priv->rproc->state = RPROC_DETACHED;
+
+   return 0;
+}
+
 static int imx_rproc_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -590,6 +631,10 @@ static int imx_rproc_probe(struct platform_device *pdev)
goto err_put_mbox;
}
 
+   ret = imx_rproc_detect_mode(priv);
+   if (ret)
+   goto err_put_mbox;
+
priv->clk = devm_clk_get(dev, NULL);
if (IS_ERR(priv->clk)) {
dev_err(dev, "Failed to get clock\n");
-- 
2.30.0

Re: [PATCH 2/2] remoteproc: imx_rproc: support remote cores booted before Linux Kernel

[Mathieu Poirier]

On Fri, Mar 19, 2021 at 06:47:08PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan 
> 
> Support remote cores booted before Linux Kernel booting.
> 
> Add rsc_table to hold the resource table published by remote cores
> Add attach hook

Missing a period "." and a new line between the paragraphs.

> Add imx_rproc_detect_mode to detect remote cores' working mode, and if
> remote cores are booted before booting Linux Kernel, parse the memory
> regions and initialize the table_ptr, table_sz, cached_table.
> 
> Signed-off-by: Peng Fan 
> ---
>  drivers/remoteproc/imx_rproc.c | 64 ++
>  1 file changed, 64 insertions(+)
> 
> diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
> index 24275429a7cc..fdaaf7599cc8 100644
> --- a/drivers/remoteproc/imx_rproc.c
> +++ b/drivers/remoteproc/imx_rproc.c
> @@ -74,6 +74,16 @@ struct imx_rproc_att {
>   int flags;
>  };
>  
> +enum imx_rproc_mode {
> + /* Linux load/kick remote core */
> + IMX_RPROC_NORMAL,
> + /*
> +  * remote core booted before kicking Linux, and remote core
> +  * could be stopped & restarted by Linux
> +  */
> + IMX_RPROC_EARLY_BOOT,
> +};
> +
>  struct imx_rproc_dcfg {
>   u32 src_reg;
>   u32 src_mask;
> @@ -95,6 +105,8 @@ struct imx_rproc {
>   struct mbox_chan*rx_ch;
>   struct work_struct  rproc_work;
>   struct workqueue_struct *workqueue;
> + enum imx_rproc_mode mode;
> + void __iomem*rsc_table;
>  };
>  
>  static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
> @@ -229,6 +241,9 @@ static int imx_rproc_stop(struct rproc *rproc)
>   if (ret)
>   dev_err(dev, "Failed to stop M4!\n");
>  
> + if (priv->mode == IMX_RPROC_EARLY_BOOT)
> + priv->mode = IMX_RPROC_NORMAL;
> +

Why is this needed?  What scenario are you trying to address?

>   return ret;
>  }
>  
> @@ -398,9 +413,15 @@ static void imx_rproc_kick(struct rproc *rproc, int vqid)
>   __func__, vqid, err);
>  }
>  
> +static int imx_rproc_attach(struct rproc *rproc)
> +{
> + return 0;
> +}
> +
>  static const struct rproc_ops imx_rproc_ops = {
>   .start  = imx_rproc_start,
>   .stop   = imx_rproc_stop,
> + .attach = imx_rproc_attach,
>   .kick   = imx_rproc_kick,
>   .da_to_va   = imx_rproc_da_to_va,
>   .load   = rproc_elf_load_segments,
> @@ -470,6 +491,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
>   }
>   priv->mem[b].sys_addr = res.start;
>   priv->mem[b].size = resource_size();
> + if (!strcmp(node->name, "rsc_table"))
> + priv->rsc_table = priv->mem[b].cpu_addr;
>   b++;
>   }
>  
> @@ -536,6 +559,43 @@ static void imx_rproc_free_mbox(struct rproc *rproc)
>   mbox_free_channel(priv->rx_ch);
>  }
>  
> +static int imx_rproc_detect_mode(struct imx_rproc *priv)
> +{
> + const struct imx_rproc_dcfg *dcfg = priv->dcfg;
> + struct rproc *rproc = priv->rproc;
> + struct device *dev = priv->dev;
> + int ret;
> + u32 val;
> +
> + ret = regmap_read(priv->regmap, dcfg->src_reg, );
> + if (ret) {
> + dev_err(dev, "Failed to read src\n");
> + return ret;
> + }
> +
> + if (!(val & dcfg->src_stop))
> + priv->mode = IMX_RPROC_EARLY_BOOT;
> + else
> + priv->mode = IMX_RPROC_NORMAL;
> +
> + if (priv->mode == IMX_RPROC_EARLY_BOOT) {
> + priv->rproc->state = RPROC_DETACHED;
> +
> + ret = imx_rproc_parse_memory_regions(priv->rproc);

If you do this here it won't be possible to reattach to the remote processor
once it has been detached.  This kind of memory parsing should go in
rproc_ops::prepare().  I suggest you look at what has been done for STM32, the
example there is quite good and simple.

> + if (ret)
> + return ret;
> +
> + if (!priv->rsc_table)
> + return 0;
> +
> + rproc->table_ptr = (struct resource_table *)priv->rsc_table;

The core is taking care of that, see rproc_set_rsc_table() for details.  

> + rproc->table_sz = SZ_1K;
> + rproc->cached_table = NULL;
> + }
> +
> + return 0;
> +}
> +
>  static int imx_rproc_prob

[PATCH 2/2] remoteproc: imx_rproc: support remote cores booted before Linux Kernel

[Peng Fan (OSS)]

From: Peng Fan 

Support remote cores booted before Linux Kernel booting.

Add rsc_table to hold the resource table published by remote cores
Add attach hook
Add imx_rproc_detect_mode to detect remote cores' working mode, and if
remote cores are booted before booting Linux Kernel, parse the memory
regions and initialize the table_ptr, table_sz, cached_table.

Signed-off-by: Peng Fan 
---
 drivers/remoteproc/imx_rproc.c | 64 ++
 1 file changed, 64 insertions(+)

diff --git a/drivers/remoteproc/imx_rproc.c b/drivers/remoteproc/imx_rproc.c
index 24275429a7cc..fdaaf7599cc8 100644
--- a/drivers/remoteproc/imx_rproc.c
+++ b/drivers/remoteproc/imx_rproc.c
@@ -74,6 +74,16 @@ struct imx_rproc_att {
int flags;
 };
 
+enum imx_rproc_mode {
+   /* Linux load/kick remote core */
+   IMX_RPROC_NORMAL,
+   /*
+* remote core booted before kicking Linux, and remote core
+* could be stopped & restarted by Linux
+*/
+   IMX_RPROC_EARLY_BOOT,
+};
+
 struct imx_rproc_dcfg {
u32 src_reg;
u32 src_mask;
@@ -95,6 +105,8 @@ struct imx_rproc {
struct mbox_chan*rx_ch;
struct work_struct  rproc_work;
struct workqueue_struct *workqueue;
+   enum imx_rproc_mode mode;
+   void __iomem*rsc_table;
 };
 
 static const struct imx_rproc_att imx_rproc_att_imx8mq[] = {
@@ -229,6 +241,9 @@ static int imx_rproc_stop(struct rproc *rproc)
if (ret)
dev_err(dev, "Failed to stop M4!\n");
 
+   if (priv->mode == IMX_RPROC_EARLY_BOOT)
+   priv->mode = IMX_RPROC_NORMAL;
+
return ret;
 }
 
@@ -398,9 +413,15 @@ static void imx_rproc_kick(struct rproc *rproc, int vqid)
__func__, vqid, err);
 }
 
+static int imx_rproc_attach(struct rproc *rproc)
+{
+   return 0;
+}
+
 static const struct rproc_ops imx_rproc_ops = {
.start  = imx_rproc_start,
.stop   = imx_rproc_stop,
+   .attach = imx_rproc_attach,
.kick   = imx_rproc_kick,
.da_to_va   = imx_rproc_da_to_va,
.load   = rproc_elf_load_segments,
@@ -470,6 +491,8 @@ static int imx_rproc_addr_init(struct imx_rproc *priv,
}
priv->mem[b].sys_addr = res.start;
priv->mem[b].size = resource_size();
+   if (!strcmp(node->name, "rsc_table"))
+   priv->rsc_table = priv->mem[b].cpu_addr;
b++;
}
 
@@ -536,6 +559,43 @@ static void imx_rproc_free_mbox(struct rproc *rproc)
mbox_free_channel(priv->rx_ch);
 }
 
+static int imx_rproc_detect_mode(struct imx_rproc *priv)
+{
+   const struct imx_rproc_dcfg *dcfg = priv->dcfg;
+   struct rproc *rproc = priv->rproc;
+   struct device *dev = priv->dev;
+   int ret;
+   u32 val;
+
+   ret = regmap_read(priv->regmap, dcfg->src_reg, );
+   if (ret) {
+   dev_err(dev, "Failed to read src\n");
+   return ret;
+   }
+
+   if (!(val & dcfg->src_stop))
+   priv->mode = IMX_RPROC_EARLY_BOOT;
+   else
+   priv->mode = IMX_RPROC_NORMAL;
+
+   if (priv->mode == IMX_RPROC_EARLY_BOOT) {
+   priv->rproc->state = RPROC_DETACHED;
+
+   ret = imx_rproc_parse_memory_regions(priv->rproc);
+   if (ret)
+   return ret;
+
+   if (!priv->rsc_table)
+   return 0;
+
+   rproc->table_ptr = (struct resource_table *)priv->rsc_table;
+   rproc->table_sz = SZ_1K;
+   rproc->cached_table = NULL;
+   }
+
+   return 0;
+}
+
 static int imx_rproc_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -590,6 +650,10 @@ static int imx_rproc_probe(struct platform_device *pdev)
goto err_put_mbox;
}
 
+   ret = imx_rproc_detect_mode(priv);
+   if (ret)
+   goto err_put_mbox;
+
priv->clk = devm_clk_get(dev, NULL);
if (IS_ERR(priv->clk)) {
dev_err(dev, "Failed to get clock\n");
-- 
2.30.0

(Riy-ID#3545) - Newsletter to linux-kernel@vger.kernel.org

[Hallman]

Good day there,



We are presently searching for proficient & knowledgeable people to become part 
of our friendly business. We feel that your experience and skills will be an 
excellent fit for our team.

Specifications: 

- Capability to interact, read, and simply write in English
- Dependable access to the internet and typical personal computer understanding
- Outstanding multitask abilities + focus on small-scale details
- No criminal history records and problems with the law
- Only the people that are legally licensed to function in the USA are approved.


This can be a very good opportunity to be a part of our business while working 
remotely.
If you require more info, kindly respond to this e-mail, and we'll send you 
additional facts promptly.




..
Sincerely,
Mr. Hallman Matusiak.

Hello linux-kernel@vger.kernel.org

[Dr Chris Hobson]

Greetings: linux-kernel@vger.kernel.org
I have a business transaction that I will like to discuss with 
you.
Please reply me immediately via my
Email: chrishobson...@gmail.com
Best regards,
Dr Chris Hobson
Credit Suisse Bank London.

Re: linux-kernel janitorial RFP: Mark static arrays as const

[Julia Lawall]

On Sun, 7 Mar 2021, Joe Perches wrote:

> On Sun, 2021-03-07 at 20:14 +0100, Julia Lawall wrote:
> >
> > On Wed, 3 Mar 2021, Joe Perches wrote:
> >
> > > On Wed, 2021-03-03 at 10:41 +0100, Rasmus Villemoes wrote:
> > > > On 02/03/2021 18.42, Joe Perches wrote:
> > > > > Here is a possible opportunity to reduce data usage in the kernel.
> > > > >
> > > > > $ git grep -P -n 
> > > > > '^static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' drivers/ | \
> > > > >   grep -v __initdata | \
> > > > >   wc -l
> > > > > 3250
> > > > >
> > > > > Meaning there are ~3000 declarations of arrays with what appears to be
> > > > > file static const content that are not marked const.
> > > > >
> > > > > So there are many static arrays that could be marked const to move the
> > > > > compiled object code from data to text minimizing the total amount of
> > > > > exposed r/w data.
> > > >
> > > > You can add const if you like, but it will rarely change the generated
> > > > code. gcc is already smart enough to take a static array whose contents
> > > > are provably never modified within the TU and put it in .rodata:
> > >
> > > At least some or perhaps even most of the time, true, but the gcc compiler
> > > from v5 through at least v10 seems inconsistent about when it does the
> > > appropriate conversion.
> > >
> > > See the example I posted:
> > > https://lore.kernel.org/lkml/6b8b250a06a98ce42120a14824531a8641f5e8aa.ca...@perches.com/
> > >
> > > It was a randomly chosen source file conversion btw, I had no prior
> > > knowledge of whether the text/data use would change.
> > >
> > > I'm unsure about clang consistently moving static but provably const 
> > > arrays
> > > from data to text.  I rarely use clang.  At least for v11 it seems to be
> > > better though.  I didn't try 10.1.
> >
> > I tried the relevnt drivers in drivers/input/joystick.  I got only one
> > driver that changed with gcc 9.3, which was
> > drivers/input/joystick/analog.c.  It actually got larger:
> >
> > original:
> >
> >    textdata bss dec hex filename
> >   22607   10560 320   3348782cf drivers/input/joystick/analog.o
> >
> > after adding const:
> >
> >    textdata bss dec hex filename
> >   22728   10816 320   338648448 drivers/input/joystick/analog.o
> >
> > This was the only case where bss was not 0, but I don't know if there is a
> > connection.
>
> You really need consider using defconfig so whatever object code
> does not have tracing/debugging support.
>
> For instance, this code with defconfig and analog joystick:
>
> Original:
>
> $ size drivers/input/joystick/analog.o
>text  data bss dec hex filename
>8115   261 22486002198 drivers/input/joystick/analog.o
>
> with const:
>
> $ size drivers/input/joystick/analog.o
>text  data bss dec hex filename
>8179   201 2248604219c drivers/input/joystick/analog.o

Thanks for the suggestion.  It occurred to me that in one case my
transformation was wrong, because the array was multi-level, and a sub
array was being stored in a structure field that was not declared as
const.  So the argument that the compiler would figure out to put the
array in .rodata didn't make sense.  But I still go the same sizes for
that file.  So I'll try the whole thing again.

thanks,
julia

Re: linux-kernel janitorial RFP: Mark static arrays as const

[Joe Perches]

On Sun, 2021-03-07 at 20:14 +0100, Julia Lawall wrote:
> 
> On Wed, 3 Mar 2021, Joe Perches wrote:
> 
> > On Wed, 2021-03-03 at 10:41 +0100, Rasmus Villemoes wrote:
> > > On 02/03/2021 18.42, Joe Perches wrote:
> > > > Here is a possible opportunity to reduce data usage in the kernel.
> > > > 
> > > > $ git grep -P -n 
> > > > '^static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' drivers/ | \
> > > >   grep -v __initdata | \
> > > >   wc -l
> > > > 3250
> > > > 
> > > > Meaning there are ~3000 declarations of arrays with what appears to be
> > > > file static const content that are not marked const.
> > > > 
> > > > So there are many static arrays that could be marked const to move the
> > > > compiled object code from data to text minimizing the total amount of
> > > > exposed r/w data.
> > > 
> > > You can add const if you like, but it will rarely change the generated
> > > code. gcc is already smart enough to take a static array whose contents
> > > are provably never modified within the TU and put it in .rodata:
> > 
> > At least some or perhaps even most of the time, true, but the gcc compiler
> > from v5 through at least v10 seems inconsistent about when it does the
> > appropriate conversion.
> > 
> > See the example I posted:
> > https://lore.kernel.org/lkml/6b8b250a06a98ce42120a14824531a8641f5e8aa.ca...@perches.com/
> > 
> > It was a randomly chosen source file conversion btw, I had no prior
> > knowledge of whether the text/data use would change.
> > 
> > I'm unsure about clang consistently moving static but provably const arrays
> > from data to text.  I rarely use clang.  At least for v11 it seems to be
> > better though.  I didn't try 10.1.
> 
> I tried the relevnt drivers in drivers/input/joystick.  I got only one
> driver that changed with gcc 9.3, which was
> drivers/input/joystick/analog.c.  It actually got larger:
> 
> original:
> 
>    textdata bss dec hex filename
>   22607   10560 320   3348782cf drivers/input/joystick/analog.o
> 
> after adding const:
> 
>    textdata bss dec hex filename
>   22728   10816 320   338648448 drivers/input/joystick/analog.o
> 
> This was the only case where bss was not 0, but I don't know if there is a
> connection.

You really need consider using defconfig so whatever object code
does not have tracing/debugging support.

For instance, this code with defconfig and analog joystick:

Original:

$ size drivers/input/joystick/analog.o
   textdata bss dec hex filename
   8115 261 22486002198 drivers/input/joystick/analog.o

with const:

$ size drivers/input/joystick/analog.o
   textdata bss dec hex filename
   8179 201 2248604219c drivers/input/joystick/analog.o

Re: linux-kernel janitorial RFP: Mark static arrays as const

[Julia Lawall]

On Wed, 3 Mar 2021, Joe Perches wrote:

> On Wed, 2021-03-03 at 10:41 +0100, Rasmus Villemoes wrote:
> > On 02/03/2021 18.42, Joe Perches wrote:
> > > Here is a possible opportunity to reduce data usage in the kernel.
> > >
> > > $ git grep -P -n '^static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' 
> > > drivers/ | \
> > >   grep -v __initdata | \
> > >   wc -l
> > > 3250
> > >
> > > Meaning there are ~3000 declarations of arrays with what appears to be
> > > file static const content that are not marked const.
> > >
> > > So there are many static arrays that could be marked const to move the
> > > compiled object code from data to text minimizing the total amount of
> > > exposed r/w data.
> >
> > You can add const if you like, but it will rarely change the generated
> > code. gcc is already smart enough to take a static array whose contents
> > are provably never modified within the TU and put it in .rodata:
>
> At least some or perhaps even most of the time, true, but the gcc compiler
> from v5 through at least v10 seems inconsistent about when it does the
> appropriate conversion.
>
> See the example I posted:
> https://lore.kernel.org/lkml/6b8b250a06a98ce42120a14824531a8641f5e8aa.ca...@perches.com/
>
> It was a randomly chosen source file conversion btw, I had no prior
> knowledge of whether the text/data use would change.
>
> I'm unsure about clang consistently moving static but provably const arrays
> from data to text.  I rarely use clang.  At least for v11 it seems to be
> better though.  I didn't try 10.1.

I tried the relevnt drivers in drivers/input/joystick.  I got only one
driver that changed with gcc 9.3, which was
drivers/input/joystick/analog.c.  It actually got larger:

original:

   textdata bss dec hex filename
  22607   10560 320   3348782cf drivers/input/joystick/analog.o

after adding const:

   textdata bss dec hex filename
  22728   10816 320   338648448 drivers/input/joystick/analog.o

This was the only case where bss was not 0, but I don't know if there is a
connection.

julia

Re: linux-kernel janitorial RFP: Mark static arrays as const

[Joe Perches]

On Wed, 2021-03-03 at 10:41 +0100, Rasmus Villemoes wrote:
> On 02/03/2021 18.42, Joe Perches wrote:
> > Here is a possible opportunity to reduce data usage in the kernel.
> > 
> > $ git grep -P -n '^static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' 
> > drivers/ | \
> >   grep -v __initdata | \
> >   wc -l
> > 3250
> > 
> > Meaning there are ~3000 declarations of arrays with what appears to be
> > file static const content that are not marked const.
> > 
> > So there are many static arrays that could be marked const to move the
> > compiled object code from data to text minimizing the total amount of
> > exposed r/w data.
> 
> You can add const if you like, but it will rarely change the generated
> code. gcc is already smart enough to take a static array whose contents
> are provably never modified within the TU and put it in .rodata:

At least some or perhaps even most of the time, true, but the gcc compiler
from v5 through at least v10 seems inconsistent about when it does the
appropriate conversion.

See the example I posted:
https://lore.kernel.org/lkml/6b8b250a06a98ce42120a14824531a8641f5e8aa.ca...@perches.com/

It was a randomly chosen source file conversion btw, I had no prior
knowledge of whether the text/data use would change.

I'm unsure about clang consistently moving static but provably const arrays
from data to text.  I rarely use clang.  At least for v11 it seems to be
better though.  I didn't try 10.1.

Re: [Cocci] linux-kernel janitorial RFP: Mark static arrays as const

[Julia Lawall]

On Tue, 2 Mar 2021, Bernd Petrovitsch wrote:

> Hi all!
>
> On 02/03/2021 18:42, Joe Perches wrote:
> [...]
> > - For instance: (head -10 of the git grep for file statics)
> >
> > drivers/accessibility/speakup/keyhelp.c:18:static u_short masks[] = { 32, 
> > 16, 8, 4, 2, 1 };
> > drivers/accessibility/speakup/keyhelp.c:26:static u_char funcvals[] = {
> > drivers/accessibility/speakup/main.c:2059:static spkup_hand spkup_handler[] 
> > = {
> > drivers/accessibility/speakup/speakup_acntpc.c:35:static unsigned int 
> > synth_portlist[] = { 0x2a8, 0 };
> > drivers/accessibility/speakup/speakup_decpc.c:133:static int 
> > synth_portlist[] = { 0x340, 0x350, 0x240, 0x250, 0 };
> > drivers/accessibility/speakup/speakup_dectlk.c:110:static int ap_defaults[] 
> > = {122, 89, 155, 110, 208, 240, 200, 106, 306};
> > drivers/accessibility/speakup/speakup_dectlk.c:111:static int g5_defaults[] 
> > = {86, 81, 86, 84, 81, 80, 83, 83, 73};
> > drivers/accessibility/speakup/speakup_dtlk.c:34:static unsigned int 
> > synth_portlist[] = {
> > drivers/accessibility/speakup/speakup_keypc.c:34:static unsigned int 
> > synth_portlist[] = { 0x2a8, 0 };
> > drivers/acpi/ac.c:137:static enum power_supply_property ac_props[] = {
> >
> > For drivers/accessibility/speakup/keyhelp.c:18:static u_short masks[] = { 
> > 32, 16, 8, 4, 2, 1 };
>
> Looking at the examples: Just s/^static /static const / in the lines
> reported by the grep's above and see if it compiles (and save space)?

There is a small risk with compiling that there may be a problem for a
configuration you haven't considered.

julia

Re: [Linux-kernel-mentees] [PATCH net] Bluetooth: Fix NULL pointer dereference in amp_read_loc_assoc_final_data()

[Dmitry Vyukov]

On Wed, Mar 3, 2021 at 11:11 AM Gopal Tiwari  wrote:
>
> Hi,
>
> I tried to search the patch for one of the bugzilla reported (Internal) 
> https://bugzilla.redhat.com/show_bug.cgi?id=1916057 with the traces
>
> [  405.938525] Workqueue: hci0 hci_rx_work [bluetooth]
> [  405.941360] RIP: 0010:amp_read_loc_assoc_final_data+0xfc/0x1c0 [bluetooth]
> [  405.944740] Code: 89 44 24 29 48 b8 00 00 00 00 00 fc ff df 0f b6 04 02 84 
> c0 74 08 3c 01 0f 8e 9d 00 00 00 0f b7 85 c0 03 00 00 66 89 44 24 2b  41 
> 80 4c 24 30 04 4c 8d 64 24 68 48 89 ee 4c 89 e7 e8 3d 48 fe
> [  405.952396] RSP: 0018:88802ea0f838 EFLAGS: 00010246
> [  405.955368] RAX:  RBX: 111005d41f08 RCX: 
> dc00
> [  405.958669] RDX: 1110254cc878 RSI: 88802000 RDI: 
> 88812a6643c0
> [  405.961980] RBP: 88812a664000 R08:  R09: 
> 
> [  405.965319] R10: 88802ea0fd00 R11:  R12: 
> 
> [  405.968624] R13: 0041 R14: 88802b836800 R15: 
> 8881250570c0
> [  405.971989] FS:  () GS:888055a0() 
> knlGS:
> [  405.975645] CS:  0010 DS:  ES:  CR0: 80050033
> [  405.978755] CR2: 0030 CR3: 2d20 CR4: 
> 00340ee0
> [  405.982150] Call Trace:
> [  405.984768]  ? amp_read_loc_assoc+0x170/0x170 [bluetooth]
> [  405.987875]  ? rcu_read_unlock+0x50/0x50
> [  405.990663]  ? deref_stack_reg+0xf0/0xf0
> [  405.993403]  ? __module_address+0x3f/0x370
> [  405.996184]  ? hci_cmd_work+0x180/0x330 [bluetooth]
> [  405.999170]  ? hci_conn_hash_lookup_handle+0x1a1/0x270 [bluetooth]
> [  406.002354]  hci_event_packet+0x1476/0x7e00 [bluetooth]
> [  406.005407]  ? arch_stack_walk+0x8f/0xf0
> [  406.008206]  ? ret_from_fork+0x27/0x50
> [  406.010887]  ? hci_cmd_complete_evt+0xbf70/0xbf70 [bluetooth]
> [  406.013933]  ? stack_trace_save+0x8a/0xb0
> [  406.016618]  ? do_profile_hits.isra.4.cold.9+0x2d/0x2d
> [  406.019483]  ? lock_acquire+0x1a3/0x970
> [  406.022092]  ? __wake_up_common_lock+0xaf/0x130
>
>
> I didn't found any solution upstream. After the vmcore analysis I found what 
> is wrong. And took reference from the following patch, which seems to be on 
> the similar line
>
> commit 6dfccd13db2ff2b709ef60a50163925d477549aa
> Author: Anmol Karn 
> Date:   Wed Sep 30 19:48:13 2020 +0530
>
> Bluetooth: Fix null pointer dereference in hci_event_packet()
>
> AMP_MGR is getting derefernced in hci_phy_link_complete_evt(), when 
> called
> from hci_event_packet() and there is a possibility, that 
> hcon->amp_mgr may
> not be found when accessing after initialization of hcon.
>
> - net/bluetooth/hci_event.c:4945
>
> How we can avoid this scenario. So I made the chages and tested. It worked or 
> avoided the kernel panic. But I really don't know that some one has already 
> posted the patch. I would have love to backport the patch, I was more of 
> looking for the fix. That's where I didn't applied the reported-by tag as I 
> thought it reported internal only.

Hi Gopal,

I think it's somewhat inherent to the current kernel unstructured
processes with bugs being reported on mailing lists, bugzilla,
distro-specific trackers.
One useful thing, though, is searching Lore, e.g. searching for just
the crashing function:
https://lore.kernel.org/lkml/?q=amp_read_loc_assoc_final_data
gives the report and the patch (if we filter out all entries produced
by your patch, which obviously wasn't yet there before you wrote it
:)):

12. [Linux-kernel-mentees] [PATCH net] Bluetooth: Fix NULL pointer
dereference in amp_read_loc_assoc_final_data()
- by Peilin Ye @ 2020-08-08  4:04 UTC [21%]

13. KASAN: null-ptr-deref Write in amp_read_loc_assoc_final_data
- by syzbot @ 2020-07-31 17:04 UTC [13%]


> Thanks & regards,
> Gopal Tiwari
>
>
>
> - Original Message -
> From: "Dmitry Vyukov" 
> To: "Peilin Ye" 
> Cc: "Marcel Holtmann" , "Johan Hedberg" 
> , "Andrei Emeltchenko" 
> , "Greg Kroah-Hartman" 
> , "David S. Miller" , "Jakub 
> Kicinski" , linux-kernel-ment...@lists.linuxfoundation.org, 
> "syzkaller-bugs" , "linux-bluetooth" 
> , "netdev" , "LKML" 
> , gtiw...@redhat.com, 
> syzbot+f4fb0eaafdb51c32a...@syzkaller.appspotmail.com
> Sent: Wednesday, March 3, 2021 1:51:41 PM
> Subject: Re: [Linux-kernel-mentees] [PATCH net] Bluetooth: Fix NULL pointer 
> dereference in amp_read_loc_assoc_final_data()
>
> On Sat, Aug 8, 2020 at 6:06 AM Peilin Ye  wrote:
> >
> > Prevent amp_read_loc_assoc_final_data() from 

Re: [Linux-kernel-mentees] [PATCH net] Bluetooth: Fix NULL pointer dereference in amp_read_loc_assoc_final_data()

[Gopal Tiwari]

Hi, 

I tried to search the patch for one of the bugzilla reported (Internal) 
https://bugzilla.redhat.com/show_bug.cgi?id=1916057 with the traces 

[  405.938525] Workqueue: hci0 hci_rx_work [bluetooth]
[  405.941360] RIP: 0010:amp_read_loc_assoc_final_data+0xfc/0x1c0 [bluetooth]
[  405.944740] Code: 89 44 24 29 48 b8 00 00 00 00 00 fc ff df 0f b6 04 02 84 
c0 74 08 3c 01 0f 8e 9d 00 00 00 0f b7 85 c0 03 00 00 66 89 44 24 2b  41 80 
4c 24 30 04 4c 8d 64 24 68 48 89 ee 4c 89 e7 e8 3d 48 fe
[  405.952396] RSP: 0018:88802ea0f838 EFLAGS: 00010246
[  405.955368] RAX:  RBX: 111005d41f08 RCX: dc00
[  405.958669] RDX: 1110254cc878 RSI: 88802000 RDI: 88812a6643c0
[  405.961980] RBP: 88812a664000 R08:  R09: 
[  405.965319] R10: 88802ea0fd00 R11:  R12: 
[  405.968624] R13: 0041 R14: 88802b836800 R15: 8881250570c0
[  405.971989] FS:  () GS:888055a0() 
knlGS:
[  405.975645] CS:  0010 DS:  ES:  CR0: 80050033
[  405.978755] CR2: 0030 CR3: 2d20 CR4: 00340ee0
[  405.982150] Call Trace:
[  405.984768]  ? amp_read_loc_assoc+0x170/0x170 [bluetooth]
[  405.987875]  ? rcu_read_unlock+0x50/0x50
[  405.990663]  ? deref_stack_reg+0xf0/0xf0
[  405.993403]  ? __module_address+0x3f/0x370
[  405.996184]  ? hci_cmd_work+0x180/0x330 [bluetooth]
[  405.999170]  ? hci_conn_hash_lookup_handle+0x1a1/0x270 [bluetooth]
[  406.002354]  hci_event_packet+0x1476/0x7e00 [bluetooth]
[  406.005407]  ? arch_stack_walk+0x8f/0xf0
[  406.008206]  ? ret_from_fork+0x27/0x50
[  406.010887]  ? hci_cmd_complete_evt+0xbf70/0xbf70 [bluetooth]
[  406.013933]  ? stack_trace_save+0x8a/0xb0
[  406.016618]  ? do_profile_hits.isra.4.cold.9+0x2d/0x2d
[  406.019483]  ? lock_acquire+0x1a3/0x970
[  406.022092]  ? __wake_up_common_lock+0xaf/0x130


I didn't found any solution upstream. After the vmcore analysis I found what is 
wrong. And took reference from the following patch, which seems to be on the 
similar line 

commit 6dfccd13db2ff2b709ef60a50163925d477549aa
Author: Anmol Karn 
Date:   Wed Sep 30 19:48:13 2020 +0530

Bluetooth: Fix null pointer dereference in hci_event_packet()

AMP_MGR is getting derefernced in hci_phy_link_complete_evt(), when 
called
from hci_event_packet() and there is a possibility, that hcon->amp_mgr 
may
not be found when accessing after initialization of hcon.

- net/bluetooth/hci_event.c:4945

How we can avoid this scenario. So I made the chages and tested. It worked or 
avoided the kernel panic. But I really don't know that some one has already 
posted the patch. I would have love to backport the patch, I was more of 
looking for the fix. That's where I didn't applied the reported-by tag as I 
thought it reported internal only. 

Thanks & regards, 
Gopal Tiwari 



- Original Message -
From: "Dmitry Vyukov" 
To: "Peilin Ye" 
Cc: "Marcel Holtmann" , "Johan Hedberg" 
, "Andrei Emeltchenko" , 
"Greg Kroah-Hartman" , "David S. Miller" 
, "Jakub Kicinski" , 
linux-kernel-ment...@lists.linuxfoundation.org, "syzkaller-bugs" 
, "linux-bluetooth" 
, "netdev" , "LKML" 
, gtiw...@redhat.com, 
syzbot+f4fb0eaafdb51c32a...@syzkaller.appspotmail.com
Sent: Wednesday, March 3, 2021 1:51:41 PM
Subject: Re: [Linux-kernel-mentees] [PATCH net] Bluetooth: Fix NULL pointer 
dereference in amp_read_loc_assoc_final_data()

On Sat, Aug 8, 2020 at 6:06 AM Peilin Ye  wrote:
>
> Prevent amp_read_loc_assoc_final_data() from dereferencing `mgr` as NULL.
>
> Reported-and-tested-by: syzbot+f4fb0eaafdb51c32a...@syzkaller.appspotmail.com
> Fixes: 9495b2ee757f ("Bluetooth: AMP: Process Chan Selected event")
> Signed-off-by: Peilin Ye 
> ---
>  net/bluetooth/amp.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/net/bluetooth/amp.c b/net/bluetooth/amp.c
> index 9c711f0dfae3..be2d469d6369 100644
> --- a/net/bluetooth/amp.c
> +++ b/net/bluetooth/amp.c
> @@ -297,6 +297,9 @@ void amp_read_loc_assoc_final_data(struct hci_dev *hdev,
> struct hci_request req;
> int err;
>
> +   if (!mgr)
> +   return;
> +
> cp.phy_handle = hcon->handle;
> cp.len_so_far = cpu_to_le16(0);
> cp.max_len = cpu_to_le16(hdev->amp_assoc_size);

Not sure what happened here, but the merged patch somehow has a
different author and no Reported-by tag:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e8bd76ede155fd54d8c41d045dda43cd3174d506
so let's tell syzbot what fixed it manually:
#syz fix:
Bluetooth: Fix null pointer dereference in amp_read_loc_assoc_final_data

Re: [Linux-kernel-mentees] [PATCH net] Bluetooth: Fix NULL pointer dereference in amp_read_loc_assoc_final_data()

[Dmitry Vyukov]

On Sat, Aug 8, 2020 at 6:06 AM Peilin Ye  wrote:
>
> Prevent amp_read_loc_assoc_final_data() from dereferencing `mgr` as NULL.
>
> Reported-and-tested-by: syzbot+f4fb0eaafdb51c32a...@syzkaller.appspotmail.com
> Fixes: 9495b2ee757f ("Bluetooth: AMP: Process Chan Selected event")
> Signed-off-by: Peilin Ye 
> ---
>  net/bluetooth/amp.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/net/bluetooth/amp.c b/net/bluetooth/amp.c
> index 9c711f0dfae3..be2d469d6369 100644
> --- a/net/bluetooth/amp.c
> +++ b/net/bluetooth/amp.c
> @@ -297,6 +297,9 @@ void amp_read_loc_assoc_final_data(struct hci_dev *hdev,
> struct hci_request req;
> int err;
>
> +   if (!mgr)
> +   return;
> +
> cp.phy_handle = hcon->handle;
> cp.len_so_far = cpu_to_le16(0);
> cp.max_len = cpu_to_le16(hdev->amp_assoc_size);

Not sure what happened here, but the merged patch somehow has a
different author and no Reported-by tag:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e8bd76ede155fd54d8c41d045dda43cd3174d506
so let's tell syzbot what fixed it manually:
#syz fix:
Bluetooth: Fix null pointer dereference in amp_read_loc_assoc_final_data

Re: linux-kernel janitorial RFP: Mark static arrays as const

[Rasmus Villemoes]

On 02/03/2021 18.42, Joe Perches wrote:
> Here is a possible opportunity to reduce data usage in the kernel.
> 
> $ git grep -P -n '^static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' 
> drivers/ | \
>   grep -v __initdata | \
>   wc -l
> 3250
> 
> Meaning there are ~3000 declarations of arrays with what appears to be
> file static const content that are not marked const.
> 
> So there are many static arrays that could be marked const to move the
> compiled object code from data to text minimizing the total amount of
> exposed r/w data.

You can add const if you like, but it will rarely change the generated
code. gcc is already smart enough to take a static array whose contents
are provably never modified within the TU and put it in .rodata:

static int x = 7;
static int y[2] = {13, 19};

static int p(int a, const int *foo)
{
return a + *foo;
}
int q(int a)
{
int b = p(a, );
return p(b, [b & 1]);
}
$ nm c.o
 T q
 r y
$ size c.o
   textdata bss dec hex filename
111   0   0 111  6f c.o

So x gets optimized away completely, but y isn't so easy to get rid of -
nevertheless, it's never modified and the address doesn't escape the TU,
so gcc treats is as if it was declared const.

I think you'll see the same if you try adding the const on a few of your
real-life examples. (Of course, the control flow may be so convoluted
that gcc isn't able to infer the constness, so I'm not saying it will
never make a difference - only that you shouldn't expect too much.)

Rasmus

Re: [Cocci] linux-kernel janitorial RFP: Mark static arrays as const

[Joe Perches]

On Tue, 2021-03-02 at 22:41 +0100, Julia Lawall wrote:
> 
> On Tue, 2 Mar 2021, Joe Perches wrote:
> 
> > Here is a possible opportunity to reduce data usage in the kernel.
> 
> Does it actually reduce data usage?

Yes, at least for gcc.  For instance:

$ gcc --version
gcc (Ubuntu 10.2.0-13ubuntu1) 10.2.0

And with the diff below (x86-64 defconfig with hwmon/pmbus and max20730)

$ diff --git a/drivers/hwmon/pmbus/max20730.c b/drivers/hwmon/pmbus/max20730.c
index 9dd3dd79bc18..b824eab95456 100644
--- a/drivers/hwmon/pmbus/max20730.c
+++ b/drivers/hwmon/pmbus/max20730.c
@@ -434,7 +434,7 @@ static long direct_to_val(u16 w, enum pmbus_sensor_classes >
return d;
 }
 
-static u32 max_current[][5] = {
+static const u32 max_current[][5] = {
[max20710] = { 6200, 8000, 9700, 11600 },
[max20730] = { 13000, 16600, 20100, 23600 },
[max20734] = { 21000, 27000, 32000, 38000 },

$ size drivers/hwmon/pmbus/max20730.o*
   textdata bss dec hex filename
   9245 256   09501251d drivers/hwmon/pmbus/max20730.o.gcc.new
   9149 352   09501251d drivers/hwmon/pmbus/max20730.o.gcc.old

with clang-11 it doesn't seem to make a difference:

$ /usr/bin/clang --version
Ubuntu clang version 11.0.0-2

$ size drivers/hwmon/pmbus/max20730.o*
   textdata bss dec hex filename
   9166 256   1942324cf 
drivers/hwmon/pmbus/max20730.o.clang-11.new
   9166 256   1942324cf 
drivers/hwmon/pmbus/max20730.o.clang-11.old

Re: linux-kernel janitorial RFP: Mark static arrays as const

[Bernd Petrovitsch]

Hi all!

On 02/03/2021 18:42, Joe Perches wrote:
[...]
> - For instance: (head -10 of the git grep for file statics)
> 
> drivers/accessibility/speakup/keyhelp.c:18:static u_short masks[] = { 32, 16, 
> 8, 4, 2, 1 };
> drivers/accessibility/speakup/keyhelp.c:26:static u_char funcvals[] = {
> drivers/accessibility/speakup/main.c:2059:static spkup_hand spkup_handler[] = 
> {
> drivers/accessibility/speakup/speakup_acntpc.c:35:static unsigned int 
> synth_portlist[] = { 0x2a8, 0 };
> drivers/accessibility/speakup/speakup_decpc.c:133:static int synth_portlist[] 
> = { 0x340, 0x350, 0x240, 0x250, 0 };
> drivers/accessibility/speakup/speakup_dectlk.c:110:static int ap_defaults[] = 
> {122, 89, 155, 110, 208, 240, 200, 106, 306};
> drivers/accessibility/speakup/speakup_dectlk.c:111:static int g5_defaults[] = 
> {86, 81, 86, 84, 81, 80, 83, 83, 73};
> drivers/accessibility/speakup/speakup_dtlk.c:34:static unsigned int 
> synth_portlist[] = {
> drivers/accessibility/speakup/speakup_keypc.c:34:static unsigned int 
> synth_portlist[] = { 0x2a8, 0 };
> drivers/acpi/ac.c:137:static enum power_supply_property ac_props[] = {
> 
> For drivers/accessibility/speakup/keyhelp.c:18:static u_short masks[] = { 32, 
> 16, 8, 4, 2, 1 };

Looking at the examples: Just s/^static /static const / in the lines
reported by the grep's above and see if it compiles (and save space)?

MfG,
Bernd
-- 
Bernd Petrovitsch  Email : be...@petrovitsch.priv.at
 There is NO CLOUD, just other people's computers. - FSFE
 LUGA : http://www.luga.at

Re: [Cocci] linux-kernel janitorial RFP: Mark static arrays as const

[Julia Lawall]

On Tue, 2 Mar 2021, Joe Perches wrote:

> Here is a possible opportunity to reduce data usage in the kernel.

Does it actually reduce data usage?

julia

>
> $ git grep -P -n '^static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' 
> drivers/ | \
>   grep -v __initdata | \
>   wc -l
> 3250
>
> Meaning there are ~3000 declarations of arrays with what appears to be
> file static const content that are not marked const.
>
> So there are many static arrays that could be marked const to move the
> compiled object code from data to text minimizing the total amount of
> exposed r/w data.
>
> However, I do not know of a mechanism using coccinelle to determine
> whether or not any of these static declarations are ever modified.
>
> So it appears that each instance of these declarations might need
> manual inspection.
>
> But for arrays declared inside functions, it's much more likely that
> the static declaration without const is done with the intent to modify
> the array:
>
> (note the difference in the git grep with a leading '^\s+')
>
> $ git grep -Pn '^\s+static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' 
> drivers/ | \
>   grep -v __initdata | \
>   wc -l
> 323
>
> - For instance: (head -10 of the git grep for file statics)
>
> drivers/accessibility/speakup/keyhelp.c:18:static u_short masks[] = { 32, 16, 
> 8, 4, 2, 1 };
> drivers/accessibility/speakup/keyhelp.c:26:static u_char funcvals[] = {
> drivers/accessibility/speakup/main.c:2059:static spkup_hand spkup_handler[] = 
> {
> drivers/accessibility/speakup/speakup_acntpc.c:35:static unsigned int 
> synth_portlist[] = { 0x2a8, 0 };
> drivers/accessibility/speakup/speakup_decpc.c:133:static int synth_portlist[] 
> = { 0x340, 0x350, 0x240, 0x250, 0 };
> drivers/accessibility/speakup/speakup_dectlk.c:110:static int ap_defaults[] = 
> {122, 89, 155, 110, 208, 240, 200, 106, 306};
> drivers/accessibility/speakup/speakup_dectlk.c:111:static int g5_defaults[] = 
> {86, 81, 86, 84, 81, 80, 83, 83, 73};
> drivers/accessibility/speakup/speakup_dtlk.c:34:static unsigned int 
> synth_portlist[] = {
> drivers/accessibility/speakup/speakup_keypc.c:34:static unsigned int 
> synth_portlist[] = { 0x2a8, 0 };
> drivers/acpi/ac.c:137:static enum power_supply_property ac_props[] = {
>
> For drivers/accessibility/speakup/keyhelp.c:18:static u_short masks[] = { 32, 
> 16, 8, 4, 2, 1 };
>
> masks is only used in static function say_key and should be const and
> perhaps the declaration might be better moved into that function.
>
> For drivers/accessibility/speakup/keyhelp.c:26:static u_char funcvals[] = {
>
> funcvals is only used in static function spk_handle_help and should be const
> and perhaps the declaration might be better moved into that function.
>
> For drivers/accessibility/speakup/main.c:2059:static spkup_hand 
> spkup_handler[] = {
>
> spkup_handler is only used in static function do_spkup and should be const
> and perhaps the declaration might be better moved into that function.
>
> etc... for speakup
>
> For drivers/acpi/ac.c:137:static enum power_supply_property ac_props[] = {
>
> array ac_props is assigned as a reference in acpi_ac_add as a
> "const enum power_supply_property *" member of a struct power_supply_desc.
>
> - For instance: (head -10 of the git grep for function statics)
>
> drivers/acpi/apei/apei-base.c:781:static u8 whea_uuid_str[] = 
> "ed855e0c-6c90-47bf-a62a-26de0fc5ad5c";
> drivers/block/amiflop.c:1051: static unsigned char CRCTable1[] = {
> drivers/block/amiflop.c:1070: static unsigned char CRCTable2[] = {
> drivers/block/drbd/drbd_nl.c:872: static char units[] = { 'K', 'M', 'G', 
> 'T', 'P', 'E' };
> drivers/block/drbd/drbd_proc.c:224:   static char write_ordering_chars[] = {
> drivers/block/drbd/drbd_receiver.c:4363:  static enum drbd_conns c_tab[] 
> = {
> drivers/char/pcmcia/synclink_cs.c:3717:   static unsigned char patterns[] 
> =
> drivers/cpufreq/intel_pstate.c:1515:  static int silvermont_freq_table[] = {
> drivers/cpufreq/intel_pstate.c:1530:  static int airmont_freq_table[] = {
> drivers/dma/xgene-dma.c:360:  static u8 flyby_type[] = {
>
> Some of these could be const, but some could not.  For instance:
>
> For drivers/acpi/apei/apei-base.c:781:static u8 whea_uuid_str[] = 
> "ed855e0c-6c90-47bf-a62a-26de0fc5ad5c";
>
> whea_uuid_str is assigned as a reference in "int apei_osc_setup(void)"
> a struct acpi_osc_context where .uuid_str is not declared as const char *.
>
>
>
>
> ___
> Cocci mailing list
> co...@systeme.lip6.fr
> https://systeme.lip6.fr/mailman/listinfo/cocci
>

linux-kernel janitorial RFP: Mark static arrays as const

[Joe Perches]

Here is a possible opportunity to reduce data usage in the kernel.

$ git grep -P -n '^static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' 
drivers/ | \
  grep -v __initdata | \
  wc -l
3250

Meaning there are ~3000 declarations of arrays with what appears to be
file static const content that are not marked const.

So there are many static arrays that could be marked const to move the
compiled object code from data to text minimizing the total amount of
exposed r/w data.

However, I do not know of a mechanism using coccinelle to determine
whether or not any of these static declarations are ever modified.

So it appears that each instance of these declarations might need
manual inspection.

But for arrays declared inside functions, it's much more likely that
the static declaration without const is done with the intent to modify
the array:

(note the difference in the git grep with a leading '^\s+')

$ git grep -Pn '^\s+static\s+(?!const|struct)(?:\w+\s+){1,3}\w+\s*\[\s*\]' 
drivers/ | \
  grep -v __initdata | \
  wc -l
323

- For instance: (head -10 of the git grep for file statics)

drivers/accessibility/speakup/keyhelp.c:18:static u_short masks[] = { 32, 16, 
8, 4, 2, 1 };
drivers/accessibility/speakup/keyhelp.c:26:static u_char funcvals[] = {
drivers/accessibility/speakup/main.c:2059:static spkup_hand spkup_handler[] = {
drivers/accessibility/speakup/speakup_acntpc.c:35:static unsigned int 
synth_portlist[] = { 0x2a8, 0 };
drivers/accessibility/speakup/speakup_decpc.c:133:static int synth_portlist[] = 
{ 0x340, 0x350, 0x240, 0x250, 0 };
drivers/accessibility/speakup/speakup_dectlk.c:110:static int ap_defaults[] = 
{122, 89, 155, 110, 208, 240, 200, 106, 306};
drivers/accessibility/speakup/speakup_dectlk.c:111:static int g5_defaults[] = 
{86, 81, 86, 84, 81, 80, 83, 83, 73};
drivers/accessibility/speakup/speakup_dtlk.c:34:static unsigned int 
synth_portlist[] = {
drivers/accessibility/speakup/speakup_keypc.c:34:static unsigned int 
synth_portlist[] = { 0x2a8, 0 };
drivers/acpi/ac.c:137:static enum power_supply_property ac_props[] = {

For drivers/accessibility/speakup/keyhelp.c:18:static u_short masks[] = { 32, 
16, 8, 4, 2, 1 };

masks is only used in static function say_key and should be const and
perhaps the declaration might be better moved into that function.

For drivers/accessibility/speakup/keyhelp.c:26:static u_char funcvals[] = {

funcvals is only used in static function spk_handle_help and should be const
and perhaps the declaration might be better moved into that function.

For drivers/accessibility/speakup/main.c:2059:static spkup_hand spkup_handler[] 
= {

spkup_handler is only used in static function do_spkup and should be const
and perhaps the declaration might be better moved into that function.

etc... for speakup

For drivers/acpi/ac.c:137:static enum power_supply_property ac_props[] = {

array ac_props is assigned as a reference in acpi_ac_add as a 
"const enum power_supply_property *" member of a struct power_supply_desc.

- For instance: (head -10 of the git grep for function statics)

drivers/acpi/apei/apei-base.c:781:  static u8 whea_uuid_str[] = 
"ed855e0c-6c90-47bf-a62a-26de0fc5ad5c";
drivers/block/amiflop.c:1051:   static unsigned char CRCTable1[] = {
drivers/block/amiflop.c:1070:   static unsigned char CRCTable2[] = {
drivers/block/drbd/drbd_nl.c:872:   static char units[] = { 'K', 'M', 'G', 
'T', 'P', 'E' };
drivers/block/drbd/drbd_proc.c:224: static char write_ordering_chars[] = {
drivers/block/drbd/drbd_receiver.c:4363:static enum drbd_conns c_tab[] 
= {
drivers/char/pcmcia/synclink_cs.c:3717: static unsigned char patterns[] =
drivers/cpufreq/intel_pstate.c:1515:static int silvermont_freq_table[] = {
drivers/cpufreq/intel_pstate.c:1530:static int airmont_freq_table[] = {
drivers/dma/xgene-dma.c:360:static u8 flyby_type[] = {

Some of these could be const, but some could not.  For instance:

For drivers/acpi/apei/apei-base.c:781:  static u8 whea_uuid_str[] = 
"ed855e0c-6c90-47bf-a62a-26de0fc5ad5c";

whea_uuid_str is assigned as a reference in "int apei_osc_setup(void)"
a struct acpi_osc_context where .uuid_str is not declared as const char *.

Re: linux kernel bug???

[Dmitry Vyukov]

On Mon, Mar 1, 2021 at 8:10 AM Lukas Bulwahn  wrote:
>
> Hi,
>
> On Mon, Mar 1, 2021 at 7:58 AM  wrote:
> >
> > This is the first time for me to report something, so maybe the format is 
> > not right. Please  correct me if I'm wrong. Thank you ~
> > When using Syzkaller to fuzz Linux kernel 5.11.0, it reported one 
> > null-ptr-def bug in file.c. The information is as follows:
> >
> > The kernel's commit:   c03c21ba6
> > The syzkaller commit: 52e3731913ab2677be27c29ed8142b04e8f28521
> >
>
> This looks like a valid kernel issue found with syzkaller.
>
> Given that it is reproducible, I suggest you continue with the following 
> steps:
>
> 1. Check if it reproduces on v5.12-rc1. If not, there is already a fix
> in v5.12-rc1. Try to identify the specific fix by bisection.
>
> 2. Check since when this issue occurs, e.g., does it appear on v5.10, v5.9 
> etc.
>
> 3. Bisect it to a specific commit.
>
> 4. Report back the results of your bisections.

Hi,

For syzkaller bugs it's also a good idea to check if it was already
reported by syzbot or not.
This one seems to be already reported:
https://syzkaller.appspot.com/bug?id=e9579dc4fc313abec952e5811bf48a26fb8d74b4
https://lore.kernel.org/lkml/ff83de05bc628...@google.com/


> > The report:
> > Syzkaller hit 'KASAN: null-ptr-deref Read in __fget_light' bug.
> >
> > ==
> > audit: type=1400 audit(1614571961.594:8): avc:  denied  { execmem } for  
> > pid=294 comm="syz-executor894" scontext=system_u:system_r:kernel_t:s0 
> > tcontext=system_u:system_r:kernel_t:s0 tclass=process permissive=1
> > BUG: KASAN: null-ptr-deref in instrument_atomic_read 
> > include/linux/instrumented.h:71 [inline]
> > BUG: KASAN: null-ptr-deref in atomic_read 
> > include/asm-generic/atomic-instrumented.h:27 [inline]
> > BUG: KASAN: null-ptr-deref in __fget_light+0x4f/0x250 fs/file.c:930
> > Read of size 4 at addr  by task io_wqe_worker-0/296
> >
> > CPU: 1 PID: 296 Comm: io_wqe_worker-0 Not tainted 5.11.0+ #5
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> > 1.13.0-1ubuntu1.1 04/01/2014
> > Call Trace:
> >  __dump_stack lib/dump_stack.c:79 [inline]
> >  dump_stack+0xaf/0xf2 lib/dump_stack.c:120
> >  __kasan_report mm/kasan/report.c:400 [inline]
> >  kasan_report.cold.9+0x10c/0x10e mm/kasan/report.c:413
> >  check_memory_region_inline mm/kasan/generic.c:179 [inline]
> >  check_memory_region+0x198/0x200 mm/kasan/generic.c:185
> >  instrument_atomic_read include/linux/instrumented.h:71 [inline]
> >  atomic_read include/asm-generic/atomic-instrumented.h:27 [inline]
> >  __fget_light+0x4f/0x250 fs/file.c:930
> >  fdget_raw include/linux/file.h:70 [inline]
> >  path_init+0x940/0x1290 fs/namei.c:2354
> >  path_lookupat.isra.65+0x2c/0x4e0 fs/namei.c:2410
> >  filename_lookup.part.80+0x17a/0x370 fs/namei.c:2453
> >  filename_lookup fs/namei.c:2446 [inline]
> >  user_path_at_empty+0x4b/0x80 fs/namei.c:2733
> >  user_path_at include/linux/namei.h:60 [inline]
> >  vfs_statx+0x108/0x310 fs/stat.c:195
> >  do_statx+0xa9/0x120 fs/stat.c:590
> >  io_statx fs/io_uring.c:4525 [inline]
> >  io_issue_sqe+0x1c31/0x4a50 fs/io_uring.c:6343
> >  io_wq_submit_work+0x2f7/0x8e0 fs/io_uring.c:6418
> >  io_worker_handle_work+0xcdd/0x1900 fs/io-wq.c:561
> >  io_wqe_worker+0xa15/0xeb0 fs/io-wq.c:603
> >  kthread+0x32a/0x3f0 kernel/kthread.c:292
> >  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
> > ==
> >
> >
> > Syzkaller reproducer:
> > # {Threaded:false Collide:false Repeat:false RepeatTimes:0 Procs:1 
> > Slowdown:1 Sandbox: Fault:false FaultCall:-1 FaultNth:0 Leak:false 
> > NetInjection:false NetDevices:false NetReset:false Cgroups:false 
> > BinfmtMisc:false CloseFDs:false KCSAN:false DevlinkPCI:false USB:false 
> > VhciInjection:false Wifi:false Sysctl:false UseTmpDir:false 
> > HandleSegv:false Repro:false Trace:false}
> > r0 = syz_io_uring_setup(0x1, &(0x7f80)={0x0, 0x0, 0x0, 0x0, 0x0, 
> > 0x0, 0x0}, &(0x7f0a)=nil, &(0x7f0b)=nil, 
> > &(0x7f000100)=0x0, &(0x7f000140)=0x0)
> > syz_io_uring_submit(r1, r2, &(0x7f0008c0)=@IORING_OP_STATX={0x15, 0x0, 
> > 0x0, 0x, 0x0, &(0x7f0003c0)='./file1\x00', 0x20, 
> > 0x1000}, 0x3)
> > io_uring_enter(r0, 0x1, 0x1, 0x1, 0x0, 0x0)
> >
> >
> > C reproducer:
> > // autogenerated by syzkaller (https://g

Re: linux kernel bug???

[Lukas Bulwahn]

Hi,

On Mon, Mar 1, 2021 at 7:58 AM  wrote:
>
> This is the first time for me to report something, so maybe the format is not 
> right. Please  correct me if I'm wrong. Thank you ~
> When using Syzkaller to fuzz Linux kernel 5.11.0, it reported one 
> null-ptr-def bug in file.c. The information is as follows:
>
> The kernel's commit:   c03c21ba6
> The syzkaller commit: 52e3731913ab2677be27c29ed8142b04e8f28521
>

This looks like a valid kernel issue found with syzkaller.

Given that it is reproducible, I suggest you continue with the following steps:

1. Check if it reproduces on v5.12-rc1. If not, there is already a fix
in v5.12-rc1. Try to identify the specific fix by bisection.

2. Check since when this issue occurs, e.g., does it appear on v5.10, v5.9 etc.

3. Bisect it to a specific commit.

4. Report back the results of your bisections.

Lukas

>
>
> The report:
> Syzkaller hit 'KASAN: null-ptr-deref Read in __fget_light' bug.
>
> ==
> audit: type=1400 audit(1614571961.594:8): avc:  denied  { execmem } for  
> pid=294 comm="syz-executor894" scontext=system_u:system_r:kernel_t:s0 
> tcontext=system_u:system_r:kernel_t:s0 tclass=process permissive=1
> BUG: KASAN: null-ptr-deref in instrument_atomic_read 
> include/linux/instrumented.h:71 [inline]
> BUG: KASAN: null-ptr-deref in atomic_read 
> include/asm-generic/atomic-instrumented.h:27 [inline]
> BUG: KASAN: null-ptr-deref in __fget_light+0x4f/0x250 fs/file.c:930
> Read of size 4 at addr  by task io_wqe_worker-0/296
>
> CPU: 1 PID: 296 Comm: io_wqe_worker-0 Not tainted 5.11.0+ #5
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 
> 04/01/2014
> Call Trace:
>  __dump_stack lib/dump_stack.c:79 [inline]
>  dump_stack+0xaf/0xf2 lib/dump_stack.c:120
>  __kasan_report mm/kasan/report.c:400 [inline]
>  kasan_report.cold.9+0x10c/0x10e mm/kasan/report.c:413
>  check_memory_region_inline mm/kasan/generic.c:179 [inline]
>  check_memory_region+0x198/0x200 mm/kasan/generic.c:185
>  instrument_atomic_read include/linux/instrumented.h:71 [inline]
>  atomic_read include/asm-generic/atomic-instrumented.h:27 [inline]
>  __fget_light+0x4f/0x250 fs/file.c:930
>  fdget_raw include/linux/file.h:70 [inline]
>  path_init+0x940/0x1290 fs/namei.c:2354
>  path_lookupat.isra.65+0x2c/0x4e0 fs/namei.c:2410
>  filename_lookup.part.80+0x17a/0x370 fs/namei.c:2453
>  filename_lookup fs/namei.c:2446 [inline]
>  user_path_at_empty+0x4b/0x80 fs/namei.c:2733
>  user_path_at include/linux/namei.h:60 [inline]
>  vfs_statx+0x108/0x310 fs/stat.c:195
>  do_statx+0xa9/0x120 fs/stat.c:590
>  io_statx fs/io_uring.c:4525 [inline]
>  io_issue_sqe+0x1c31/0x4a50 fs/io_uring.c:6343
>  io_wq_submit_work+0x2f7/0x8e0 fs/io_uring.c:6418
>  io_worker_handle_work+0xcdd/0x1900 fs/io-wq.c:561
>  io_wqe_worker+0xa15/0xeb0 fs/io-wq.c:603
>  kthread+0x32a/0x3f0 kernel/kthread.c:292
>  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294
> ==
>
>
> Syzkaller reproducer:
> # {Threaded:false Collide:false Repeat:false RepeatTimes:0 Procs:1 Slowdown:1 
> Sandbox: Fault:false FaultCall:-1 FaultNth:0 Leak:false NetInjection:false 
> NetDevices:false NetReset:false Cgroups:false BinfmtMisc:false CloseFDs:false 
> KCSAN:false DevlinkPCI:false USB:false VhciInjection:false Wifi:false 
> Sysctl:false UseTmpDir:false HandleSegv:false Repro:false Trace:false}
> r0 = syz_io_uring_setup(0x1, &(0x7f80)={0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
> 0x0}, &(0x7f0a)=nil, &(0x7f0b)=nil, 
> &(0x7f000100)=0x0, &(0x7f000140)=0x0)
> syz_io_uring_submit(r1, r2, &(0x7f0008c0)=@IORING_OP_STATX={0x15, 0x0, 
> 0x0, 0x, 0x0, &(0x7f0003c0)='./file1\x00', 0x20, 0x1000}, 
> 0x3)
> io_uring_enter(r0, 0x1, 0x1, 0x1, 0x0, 0x0)
>
>
> C reproducer:
> // autogenerated by syzkaller (https://github.com/google/syzkaller)
>
> #define _GNU_SOURCE
>
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> #define SIZEOF_IO_URING_SQE 64
> #define SIZEOF_IO_URING_CQE 16
> #define SQ_HEAD_OFFSET 0
> #define SQ_TAIL_OFFSET 64
> #define SQ_RING_MASK_OFFSET 256
> #define SQ_RING_ENTRIES_OFFSET 264
> #define SQ_FLAGS_OFFSET 276
> #define SQ_DROPPED_OFFSET 272
> #define CQ_HEAD_OFFSET 128
> #define CQ_TAIL_OFFSET 192
> #define CQ_RING_MASK_OFFSET 260
> #define CQ_RING_ENTRIES_OFFSET 268
> #define CQ_RING_OVERFLOW_OFFSET 284
> #define CQ_FLAGS_OFFSET 280
> #define CQ_CQES_OFFSET 320
>
> struct io_sqring_offsets {
> uint32_t head;
> uint

linux kernel 5.10.x to 5.11.x : boot FB switch VT is black after EFI VGA FB changed to CPU FB

[hanasaki-gmail]

linux-kernel@vger.kernel.org

previous kernel 5.10...

current kernel 5.11.4

After moving to 5.11, can no longer switch to VT's.  The boot sequence 
shows as far as


fb0: switching to inteldrmfb from EFI VGA

...

Console: switching to colour dummy device 80x25

and then goes black and unresponsive.  the ^Alt-VT# keys do switch 
between X and the VT except the VT is black and unresponsive.  Booting 
to recovery mode, or just the console (uninstalled X) gets to the same 
"it appears to hang" point, although it may just be an unresponsive FB.

[RELEASE] LTTng-modules 2.11.8 and 2.12.5 (Linux kernel tracer)

[Mathieu Desnoyers]

Hi,

This is a release announcement for the 2.11.8 and 2.12.5 releases of the
LTTng kernel tracer.

New and noteworthy in these releases:

* Support for Linux kernel 5.11,
* Deal with stable kernel version overflow (sublevel >= 256),
* Prepare for Ubuntu, SLES, RHEL, and RT release version overflows (which 
should come sooner
  or later),
* Writeback instrumentation: fix out-of-bound read of block device name beyond 
terminating
  '\0' character,
* Writeback instrumentation: fix a crash in wb_workfn when a device disappears 
when memcg
  is in use,
* aarch64: blacklist gcc compiler prior to version 5.1, because they perform 
unsafe access
  to deallocated stack.

Thanks,

Mathieu

Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

[tip: irq/core] Merge tag 'irqchip-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core

[tip-bot2 for Thomas Gleixner]

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

Commit-ID: 0b6d70e571a1c764ab079e5c31d4156feee4b06b
Gitweb:
https://git.kernel.org/tip/0b6d70e571a1c764ab079e5c31d4156feee4b06b
Author:Thomas Gleixner 
AuthorDate:Mon, 15 Feb 2021 15:41:56 +01:00
Committer: Thomas Gleixner 
CommitterDate: Mon, 15 Feb 2021 15:41:56 +01:00

Merge tag 'irqchip-5.12' of 
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core

Pull irqchip updates from Marc Zyngier

 - New driver for the MIPS-based Realtek RTL838x/RTL839x SoC
 - Conversion of the sun6i-r support code to a hierarchical setup
 - Fix wake-up interrupts for the ls-extirq driver
 - Fix MSI allocation for the loongson-pch-msi driver
 - Add compatible strings for new Qualcomm SoCs
 - Tidy up a few Kconfig entries (IMX, CSKY)
 - Spelling phyksiz
 - Remove the sirfsoc and tango drivers

Link: https://lore.kernel.org/r/20210214124015.457-1-...@kernel.org
---

Greylisting on linux-kernel broken?

[Phillip Lougher]

Hi,

I have sent a patch-set from my usual email address
(phil...@squashfs.org.uk), but despite over 18 hours it has still not
shown up.  Instead I have received bounce warning emails that they are
delayed.

I have sent emails to autoans...@vger.kernel.org and
majord...@vger.kernel.org, and they have not been delivered either.

Is  there something wrong here?  It is impossible to get an empty
email to autoans...@vger.kernel.org wrong so it is delayed AFAIK.   I
have used http://vger.kernel.org/mxverify.html to check that the MX
records appear correct.

Thanks for any help.

Phillip Lougher
Squashfs maintainer

Re: [Linux-kernel-mentees] Patches from the future - can checkpatch help?

[Philip Li]

On Tue, Feb 02, 2021 at 04:48:04AM -0800, Joe Perches wrote:
> On Mon, 2021-02-01 at 22:41 +0530, Dwaipayan Ray wrote:
> > The idea of a bot seems nice though in general.
> > People do have all the style checking scripts at their disposal, but still
> > we see style issues on the list.
> > 
> > Something similar to the kernel test robot, but for style issues seems nice.
> > Is it something the community would like?
> 
> (Adding lkp)
> 
> Maybe yes, but likely it depends on the particular audience so
> no, not really.
> 
> The kbuild test robot used to run checkpatch on patches and there
> there was negative feedback.  I don't know if the robot is still
> running checkpatch with some subset of message types.
Hi Joe, we had disabled the checkpatch due to low fruit with very limited
useful reports. Is there any recommendation like which kind of types can
be interested?

Thanks

> 
> A thread from 2013:
> 
> https://lore.kernel.org/lkml/20130903003958.GA6855@localhost/
> 
> 

Re: [Linux-kernel-mentees] Patches from the future - can checkpatch help?

[Joe Perches]

On Mon, 2021-02-01 at 22:41 +0530, Dwaipayan Ray wrote:
> The idea of a bot seems nice though in general.
> People do have all the style checking scripts at their disposal, but still
> we see style issues on the list.
> 
> Something similar to the kernel test robot, but for style issues seems nice.
> Is it something the community would like?

(Adding lkp)

Maybe yes, but likely it depends on the particular audience so
no, not really.

The kbuild test robot used to run checkpatch on patches and there
there was negative feedback.  I don't know if the robot is still
running checkpatch with some subset of message types.

A thread from 2013:

https://lore.kernel.org/lkml/20130903003958.GA6855@localhost/

Re: [Linux-kernel-mentees] Patches from the future - can checkpatch help?

[Greg KH]

On Mon, Feb 01, 2021 at 10:31:33PM +0530, Dwaipayan Ray wrote:
> On Mon, Feb 1, 2021 at 10:07 PM Greg KH  wrote:
> >
> > On Mon, Feb 01, 2021 at 10:04:01PM +0530, Dwaipayan Ray wrote:
> > > Hi,
> > > on linux-next,
> > > $ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
> > > gives:
> > > 4a2d78822fdf
> > > 12ca45fea91c
> > > 09f2724a786f
> > >
> > > These are patches from the year 2085, 2037 and 2030 respectively.
> > >
> > > Would a checkpatch rule be helpful for these or are they too
> > > isolated to waste runtime on?
> >
> > Dates come from your email client, not the patch itself, how is
> > checkpatch going to catch this?
> >
> 
> I was hoping that the maintainer could catch it before merging it
> into his tree. Dates being a trivial thing might slip human eyes,
> but checkpatch might detect it there.

What is the problem here.  You can't treat dates that patches were
"created", you have to always go off of the release the patches showed
up in.  So while you might want to do a sliding scale of 4 months or so,
in reality we have patches committed to the tree today that were written
years ago.

I think I still hold the record for "time it took to get a patch merged"
with a very old devfs removal patch, which was many many years...

thanks,

greg k-h

Re: [Linux-kernel-mentees] Patches from the future - can checkpatch help?

[Theodore Ts'o]

On Mon, Feb 01, 2021 at 05:50:45PM +0100, Lukas Bulwahn wrote:
> 
> Dwaipayan, there are two ways:
> - We build a bot listening to mailing lists and check. I like that
> implementation idea for various other checks.
> - Stephen Rothwell could include this as a check on linux-next and
> inform the git author and committer.
> 
> I am wondering though if that is worth the effort, three instances of
> a wrong date among 1M commits seems to be very seldom and the harm of
> that mistake is quite small as well.

Another solution might be to ask the git developers if they would be
willing to have "git am" print a warning if the date is sufficiently
insane (say, more than 3 months in the past or present).

One could also imagine a request that "git log" would have a new
format where normally the author time is printed, but if it's
sufficiently different from the commit time, the commit time is also
printed in parenthesis.

Or you could set up your git config so that "git log" uses
--pretty=fuller by default, which prints both the author date and
commit date.

Like Lukas, I'm not really sure it's worth the effort, however.

 - Ted

Re: [Linux-kernel-mentees] Patches from the future - can checkpatch help?

[Dwaipayan Ray]

On Mon, Feb 1, 2021 at 10:20 PM Lukas Bulwahn  wrote:
>
> On Mon, Feb 1, 2021 at 5:37 PM Greg KH  wrote:
> >
> > On Mon, Feb 01, 2021 at 10:04:01PM +0530, Dwaipayan Ray wrote:
> > > Hi,
> > > on linux-next,
> > > $ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
> > > gives:
> > > 4a2d78822fdf
> > > 12ca45fea91c
> > > 09f2724a786f
> > >
> > > These are patches from the year 2085, 2037 and 2030 respectively.
> > >
> > > Would a checkpatch rule be helpful for these or are they too
> > > isolated to waste runtime on?
> >
> > Dates come from your email client, not the patch itself, how is
> > checkpatch going to catch this?
> >
>
> Dwaipayan, there are two ways:
> - We build a bot listening to mailing lists and check. I like that
> implementation idea for various other checks.
> - Stephen Rothwell could include this as a check on linux-next and
> inform the git author and committer.
>
> I am wondering though if that is worth the effort, three instances of
> a wrong date among 1M commits seems to be very seldom and the harm of
> that mistake is quite small as well.
>

I agree. I felt it was isolated as well but it might affect people who do
static analysis on the commits or such.

The idea of a bot seems nice though in general.
People do have all the style checking scripts at their disposal, but still
we see style issues on the list.

Something similar to the kernel test robot, but for style issues seems nice.
Is it something the community would like?

Thanks,
Dwaipayan.

Re: [Linux-kernel-mentees] Patches from the future - can checkpatch help?

[Dwaipayan Ray]

On Mon, Feb 1, 2021 at 10:07 PM Greg KH  wrote:
>
> On Mon, Feb 01, 2021 at 10:04:01PM +0530, Dwaipayan Ray wrote:
> > Hi,
> > on linux-next,
> > $ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
> > gives:
> > 4a2d78822fdf
> > 12ca45fea91c
> > 09f2724a786f
> >
> > These are patches from the year 2085, 2037 and 2030 respectively.
> >
> > Would a checkpatch rule be helpful for these or are they too
> > isolated to waste runtime on?
>
> Dates come from your email client, not the patch itself, how is
> checkpatch going to catch this?
>

I was hoping that the maintainer could catch it before merging it
into his tree. Dates being a trivial thing might slip human eyes,
but checkpatch might detect it there.

Thanks,
Dwaipayan.

Re: [Linux-kernel-mentees] Patches from the future - can checkpatch help?

[Lukas Bulwahn]

On Mon, Feb 1, 2021 at 5:37 PM Greg KH  wrote:
>
> On Mon, Feb 01, 2021 at 10:04:01PM +0530, Dwaipayan Ray wrote:
> > Hi,
> > on linux-next,
> > $ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
> > gives:
> > 4a2d78822fdf
> > 12ca45fea91c
> > 09f2724a786f
> >
> > These are patches from the year 2085, 2037 and 2030 respectively.
> >
> > Would a checkpatch rule be helpful for these or are they too
> > isolated to waste runtime on?
>
> Dates come from your email client, not the patch itself, how is
> checkpatch going to catch this?
>

Dwaipayan, there are two ways:
- We build a bot listening to mailing lists and check. I like that
implementation idea for various other checks.
- Stephen Rothwell could include this as a check on linux-next and
inform the git author and committer.

I am wondering though if that is worth the effort, three instances of
a wrong date among 1M commits seems to be very seldom and the harm of
that mistake is quite small as well.

Lukas

Re: [Linux-kernel-mentees] Patches from the future - can checkpatch help?

[Greg KH]

On Mon, Feb 01, 2021 at 10:04:01PM +0530, Dwaipayan Ray wrote:
> Hi,
> on linux-next,
> $ git log --pretty=format:"%h%x09%ad" | awk '$6>2021 {print $1}'
> gives:
> 4a2d78822fdf
> 12ca45fea91c
> 09f2724a786f
> 
> These are patches from the year 2085, 2037 and 2030 respectively.
> 
> Would a checkpatch rule be helpful for these or are they too
> isolated to waste runtime on?

Dates come from your email client, not the patch itself, how is
checkpatch going to catch this?

thanks,

greg k-h

[PATCH 2/8] tools: bitmap: sync function declarations with linux kernel

[Yury Norov]

Some functions in tools/include/linux/bitmap.h declare nbits
as int. In the kernel nbits is declared as unsigned int.

Signed-off-by: Yury Norov 
---
 tools/include/linux/bitmap.h | 8 
 tools/lib/bitmap.c   | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/tools/include/linux/bitmap.h b/tools/include/linux/bitmap.h
index 477a1cae513f..7cbd23e56d48 100644
--- a/tools/include/linux/bitmap.h
+++ b/tools/include/linux/bitmap.h
@@ -30,7 +30,7 @@ void bitmap_clear(unsigned long *map, unsigned int start, int 
len);
 #define small_const_nbits(nbits) \
(__builtin_constant_p(nbits) && (nbits) <= BITS_PER_LONG)
 
-static inline void bitmap_zero(unsigned long *dst, int nbits)
+static inline void bitmap_zero(unsigned long *dst, unsigned int nbits)
 {
if (small_const_nbits(nbits))
*dst = 0UL;
@@ -66,7 +66,7 @@ static inline int bitmap_full(const unsigned long *src, 
unsigned int nbits)
return find_first_zero_bit(src, nbits) == nbits;
 }
 
-static inline int bitmap_weight(const unsigned long *src, int nbits)
+static inline int bitmap_weight(const unsigned long *src, unsigned int nbits)
 {
if (small_const_nbits(nbits))
return hweight_long(*src & BITMAP_LAST_WORD_MASK(nbits));
@@ -74,7 +74,7 @@ static inline int bitmap_weight(const unsigned long *src, int 
nbits)
 }
 
 static inline void bitmap_or(unsigned long *dst, const unsigned long *src1,
-const unsigned long *src2, int nbits)
+const unsigned long *src2, unsigned int nbits)
 {
if (small_const_nbits(nbits))
*dst = *src1 | *src2;
@@ -141,7 +141,7 @@ static inline void bitmap_free(unsigned long *bitmap)
  * @buf: buffer to store output
  * @size: size of @buf
  */
-size_t bitmap_scnprintf(unsigned long *bitmap, int nbits,
+size_t bitmap_scnprintf(unsigned long *bitmap, unsigned int nbits,
char *buf, size_t size);
 
 /**
diff --git a/tools/lib/bitmap.c b/tools/lib/bitmap.c
index 5043747ef6c5..f4e914712b6f 100644
--- a/tools/lib/bitmap.c
+++ b/tools/lib/bitmap.c
@@ -28,11 +28,11 @@ void __bitmap_or(unsigned long *dst, const unsigned long 
*bitmap1,
dst[k] = bitmap1[k] | bitmap2[k];
 }
 
-size_t bitmap_scnprintf(unsigned long *bitmap, int nbits,
+size_t bitmap_scnprintf(unsigned long *bitmap, unsigned int nbits,
char *buf, size_t size)
 {
/* current bit is 'cur', most recently seen range is [rbot, rtop] */
-   int cur, rbot, rtop;
+   unsigned int cur, rbot, rtop;
bool first = true;
size_t ret = 0;
 
-- 
2.25.1

[PATCH -V9 3/3] NOT kernel/numactl: Support to enable Linux kernel NUMA balancing

[Huang Ying]

A new API: numa_set_membind_balancing() is added to libnuma.  It is
same as numa_set_membind() except that the Linux kernel NUMA balancing
will be enabled for the task if the feature is supported by the
kernel.

At the same time, a new option: --balancing (-b) is added to numactl.
Which can be used before the --membind/-m memory policy in the command
line.  With it, the Linux kernel NUMA balancing will be enabled for
the process if --membind/-m is used and the feature is supported by
the kernel.

Signed-off-by: "Huang, Ying" 
---
 libnuma.c | 14 ++
 numa.3| 15 +++
 numa.h|  4 
 numactl.8 | 12 
 numactl.c | 17 ++---
 numaif.h  |  3 +++
 versions.ldscript |  8 
 7 files changed, 70 insertions(+), 3 deletions(-)

diff --git a/libnuma.c b/libnuma.c
index 88f479b..f073c50 100644
--- a/libnuma.c
+++ b/libnuma.c
@@ -1064,6 +1064,20 @@ numa_set_membind_v2(struct bitmask *bmp)
 
 make_internal_alias(numa_set_membind_v2);
 
+void
+numa_set_membind_balancing(struct bitmask *bmp)
+{
+   /* MPOL_F_NUMA_BALANCING: ignore if unsupported */
+   if (set_mempolicy(MPOL_BIND | MPOL_F_NUMA_BALANCING,
+ bmp->maskp, bmp->size + 1) < 0) {
+   if (errno == EINVAL) {
+   errno = 0;
+   numa_set_membind_v2(bmp);
+   } else
+   numa_error("set_mempolicy");
+   }
+}
+
 /*
  * copy a bitmask map body to a numa.h nodemask_t structure
  */
diff --git a/numa.3 b/numa.3
index 3e18098..af01c8f 100644
--- a/numa.3
+++ b/numa.3
@@ -80,6 +80,8 @@ numa \- NUMA policy library
 .br
 .BI "void numa_set_membind(struct bitmask *" nodemask );
 .br
+.BI "void numa_set_membind_balancing(struct bitmask *" nodemask );
+.br
 .B struct bitmask *numa_get_membind(void);
 .sp
 .BI "void *numa_alloc_onnode(size_t " size ", int " node );
@@ -538,6 +540,19 @@ that contains nodes other than those in the mask returned 
by
 .IR numa_get_mems_allowed ()
 will result in an error.
 
+.BR numa_set_membind_balancing ()
+sets the memory allocation mask and enable the Linux kernel NUMA
+balancing for the task if the feature is supported by the kernel.
+The task will only allocate memory from the nodes set in
+.IR nodemask .
+Passing an empty
+.I nodemask
+or a
+.I nodemask
+that contains nodes other than those in the mask returned by
+.IR numa_get_mems_allowed ()
+will result in an error.
+
 .BR numa_get_membind ()
 returns the mask of nodes from which memory can currently be allocated.
 If the returned mask is equal to
diff --git a/numa.h b/numa.h
index bd1d676..5d8543a 100644
--- a/numa.h
+++ b/numa.h
@@ -192,6 +192,10 @@ void numa_set_localalloc(void);
 /* Only allocate memory from the nodes set in mask. 0 to turn off */
 void numa_set_membind(struct bitmask *nodemask);
 
+/* Only allocate memory from the nodes set in mask. Optimize page
+   placement with Linux kernel NUMA balancing if possible. 0 to turn off */
+void numa_set_membind_balancing(struct bitmask *bmp);
+
 /* Return current membind */
 struct bitmask *numa_get_membind(void);
 
diff --git a/numactl.8 b/numactl.8
index f3bb22b..7d52688 100644
--- a/numactl.8
+++ b/numactl.8
@@ -25,6 +25,8 @@ numactl \- Control NUMA policy for processes or shared memory
 [
 .B \-\-all
 ] [
+.B \-\-balancing
+] [
 .B \-\-interleave nodes
 ] [
 .B \-\-preferred node 
@@ -168,6 +170,12 @@ but if memory cannot be allocated there fall back to other 
nodes.
 This option takes only a single node number.
 Relative notation may be used.
 .TP
+.B \-\-balancing, \-b
+Enable Linux kernel NUMA balancing for the process if it is supported by 
kernel.
+This should only be used with
+.I \-\-membind, \-m
+only, otherwise ignored.
+.TP
 .B \-\-show, \-s
 Show NUMA policy settings of the current process. 
 .TP
@@ -278,6 +286,10 @@ numactl \-\-cpunodebind=0 \-\-membind=0,1 -- process -l
 Run process as above, but with an option (-l) that would be confused with
 a numactl option.
 
+numactl \-\-cpunodebind=0 \-\-balancing \-\-membind=0,1 process
+Run process on node 0 with memory allocated on node 0 and 1.  Optimize the
+page placement with Linux kernel NUMA balancing mechanism if possible.
+
 numactl \-\-cpunodebind=netdev:eth0 \-\-membind=netdev:eth0 network-server
 Run network-server on the node of network device eth0 with its memory
 also in the same node.
diff --git a/numactl.c b/numactl.c
index df9dbcb..5a9d2df 100644
--- a/numactl.c
+++ b/numactl.c
@@ -45,6 +45,7 @@ struct option opts[] = {
{"membind", 1, 0, 'm'},
{"show", 0, 0, 's' },
{"localalloc", 0,0, 'l'},
+   {"balancing", 0, 0, 'b'},
{"hardware", 0,0,'H' },
 
{"shm", 1, 0, 'S'},
@@ -65,9 +66,10 @@ struct option opts[] = {
 void usage(void)
 {
fprintf(stderr,
-

[tip: irq/urgent] Merge tag 'irqchip-fixes-5.11-1' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent

[tip-bot2 for Thomas Gleixner]

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

Commit-ID: 4bae052dde14c5538eca39592777b1d1987234ba
Gitweb:
https://git.kernel.org/tip/4bae052dde14c5538eca39592777b1d1987234ba
Author:Thomas Gleixner 
AuthorDate:Tue, 12 Jan 2021 21:23:55 +01:00
Committer: Thomas Gleixner 
CommitterDate: Tue, 12 Jan 2021 21:23:55 +01:00

Merge tag 'irqchip-fixes-5.11-1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent

Pull irqchip fixes from Marc Zyngier:

 - Fix the MIPS CPU interrupt controller hierarchy
 - Simplify the PRUSS Kconfig entry
 - Eliminate trivial build warnings on the MIPS Loongson liointc
 - Fix error path in devm_platform_get_irqs_affinity()
 - Turn the BCM2836 IPI irq_eoi callback into irq_ack
 - Fix initialisation of on-stack msi_alloc_info
 - Cleanup spurious comma in irq-sl28cpld

Link: https://lore.kernel.org/r/20210110110001.2328708-1-...@kernel.org
---

Re: Linux Kernel module notification bug

[Greg Kroah-Hartman]

On Tue, Jan 12, 2021 at 11:46:55AM +0100, Jessica Yu wrote:
> +++ Adam Zabrocki [12/01/21 01:15 +0100]:
> > Hello,
> > 
> > On Mon, Jan 11, 2021 at 03:20:48PM +0100, Jessica Yu wrote:
> > > +++ Adam Zabrocki [10/01/21 18:54 +0100]:
> > > > Hello,
> > > >
> > > > I believe that the following commit does introduce a gentle 
> > > > "functionality
> > > > bug":
> > > >
> > > > "module: delay kobject uevent until after module init call":
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/kernel/module.c?id=38dc717e97153e46375ee21797aa54777e5498f3
> > > >
> > > > The official Linux Kernel API for the kernel module activities 
> > > > notification has
> > > > been divided based on the readiness 'stage' for such module. We have the
> > > > following stages:
> > > >
> > > >MODULE_STATE_LIVE,  /* Normal state. */
> > > >MODULE_STATE_COMING,/* Full formed, running module_init. */
> > > >MODULE_STATE_GOING, /* Going away. */
> > > >MODULE_STATE_UNFORMED,  /* Still setting it up. */
> > > >
> > > > LIVE means that the kernel module is correctly running and all 
> > > > initialization
> > > > work has been already done. Otherwise, we have event 'COMING' or 
> > > > 'UNFORMED'.
> > > >
> > > > In the described commit, creation of the KOBJECT has been moved after 
> > > > invoking
> > > > a notficiation of the newly formed kernel module state (LIVE). That's 
> > > > somehow
> > > > inconsistent from my understanding of the kernel modules notifiers 
> > > > logic.
> > > > Creation of the new objects (like KOBJ) should be done before 
> > > > notification of
> > > > the stage LIVE is invoked.
> > > 
> > > I'm confused. We're not creating any kobjects here. That is all done
> > > in mod_sysfs_setup(), which is called while the module is still
> > > COMING.  What that commit does is delay telling userspace about the
> > > module (specifically, systemd/udev) until the module is basically
> > > ready. Systemd was basically receiving the uevent too early, before
> > > the module has initialized, hence we decided to delay the uevent [1].
> > > 
> > 
> > Sorry for the confusion on my side. I was referring to the internal state of
> > the KOBJ itself which is being actively modified when uevent is sent. During
> > the module creation KOBJ_ADD modifies 'kobj->state_add_uevent_sent'. Until
> > recent commit, kernel didn't modify KOBJ after sending LIVE notification.
> > 
> > > > This commit breaks some of the projects that rely on the LIVE 
> > > > notification to
> > > > monitor when the newly loaded module is ready.
> > > 
> > > Hm, could you please explain specifically what is the issue you're seeing?
> > > What projects is it breaking?
> > > 
> > 
> > I'm specifically referencing these projects which are tracking kernel 
> > modules
> > for integrity purpose (e.g. anti-rootkit tools) like Linux Kernel Runtime
> > Guard.
> > It is possible to modify these tools to adopt and take into account
> > modification of KOBJ after LIVE state notification. However, from my
> > understanding of the kernel modules notifiers logic, KOBJ should be fully
> > formed at this stage.
> 
> Ah I see, thanks for the clarification. I was under the impression
> that kobj->state_add_uevent_sent is an internal field interesting
> only to lib/kobject.c, and did not know tools like you mention are
> implicitly tracking that.

There is no in-kernel tools/users tracking stuff like this, so this is
not an issue.  The internals of kobjects can change at any time, there
is no "stable api" here at all.

thanks,

greg k-h

Re: Linux Kernel module notification bug

[Jessica Yu]

+++ Adam Zabrocki [12/01/21 01:15 +0100]:

Hello,

On Mon, Jan 11, 2021 at 03:20:48PM +0100, Jessica Yu wrote:

+++ Adam Zabrocki [10/01/21 18:54 +0100]:
> Hello,
>
> I believe that the following commit does introduce a gentle "functionality
> bug":
>
> "module: delay kobject uevent until after module init call":
> 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/kernel/module.c?id=38dc717e97153e46375ee21797aa54777e5498f3
>
> The official Linux Kernel API for the kernel module activities notification 
has
> been divided based on the readiness 'stage' for such module. We have the
> following stages:
>
>MODULE_STATE_LIVE,  /* Normal state. */
>MODULE_STATE_COMING,/* Full formed, running module_init. */
>MODULE_STATE_GOING, /* Going away. */
>MODULE_STATE_UNFORMED,  /* Still setting it up. */
>
> LIVE means that the kernel module is correctly running and all initialization
> work has been already done. Otherwise, we have event 'COMING' or 'UNFORMED'.
>
> In the described commit, creation of the KOBJECT has been moved after invoking
> a notficiation of the newly formed kernel module state (LIVE). That's somehow
> inconsistent from my understanding of the kernel modules notifiers logic.
> Creation of the new objects (like KOBJ) should be done before notification of
> the stage LIVE is invoked.

I'm confused. We're not creating any kobjects here. That is all done
in mod_sysfs_setup(), which is called while the module is still
COMING.  What that commit does is delay telling userspace about the
module (specifically, systemd/udev) until the module is basically
ready. Systemd was basically receiving the uevent too early, before
the module has initialized, hence we decided to delay the uevent [1].



Sorry for the confusion on my side. I was referring to the internal state of
the KOBJ itself which is being actively modified when uevent is sent. During
the module creation KOBJ_ADD modifies 'kobj->state_add_uevent_sent'. Until
recent commit, kernel didn't modify KOBJ after sending LIVE notification.


> This commit breaks some of the projects that rely on the LIVE notification to
> monitor when the newly loaded module is ready.

Hm, could you please explain specifically what is the issue you're seeing?
What projects is it breaking?



I'm specifically referencing these projects which are tracking kernel modules
for integrity purpose (e.g. anti-rootkit tools) like Linux Kernel Runtime
Guard.
It is possible to modify these tools to adopt and take into account
modification of KOBJ after LIVE state notification. However, from my
understanding of the kernel modules notifiers logic, KOBJ should be fully
formed at this stage.


Ah I see, thanks for the clarification. I was under the impression
that kobj->state_add_uevent_sent is an internal field interesting
only to lib/kobject.c, and did not know tools like you mention are
implicitly tracking that.

In any case, I think your suggested change doesn't affect the
systemd/udev issue we were trying to fix, as long as the uevent is
sent after module init(). Would you mind sending a patch? (with a
Fixes: tag and including the explanations you've provided in this
thread in the changelog)

Thanks!

Jessica

Re: Linux Kernel module notification bug

[Adam Zabrocki]

Hello,

On Mon, Jan 11, 2021 at 03:20:48PM +0100, Jessica Yu wrote:
> +++ Adam Zabrocki [10/01/21 18:54 +0100]:
> > Hello,
> > 
> > I believe that the following commit does introduce a gentle "functionality
> > bug":
> > 
> > "module: delay kobject uevent until after module init call":
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/kernel/module.c?id=38dc717e97153e46375ee21797aa54777e5498f3
> > 
> > The official Linux Kernel API for the kernel module activities notification 
> > has
> > been divided based on the readiness 'stage' for such module. We have the
> > following stages:
> > 
> >MODULE_STATE_LIVE,  /* Normal state. */
> >MODULE_STATE_COMING,/* Full formed, running module_init. */
> >MODULE_STATE_GOING, /* Going away. */
> >MODULE_STATE_UNFORMED,  /* Still setting it up. */
> > 
> > LIVE means that the kernel module is correctly running and all 
> > initialization
> > work has been already done. Otherwise, we have event 'COMING' or 'UNFORMED'.
> > 
> > In the described commit, creation of the KOBJECT has been moved after 
> > invoking
> > a notficiation of the newly formed kernel module state (LIVE). That's 
> > somehow
> > inconsistent from my understanding of the kernel modules notifiers logic.
> > Creation of the new objects (like KOBJ) should be done before notification 
> > of
> > the stage LIVE is invoked.
> 
> I'm confused. We're not creating any kobjects here. That is all done
> in mod_sysfs_setup(), which is called while the module is still
> COMING.  What that commit does is delay telling userspace about the
> module (specifically, systemd/udev) until the module is basically
> ready. Systemd was basically receiving the uevent too early, before
> the module has initialized, hence we decided to delay the uevent [1].
> 

Sorry for the confusion on my side. I was referring to the internal state of 
the KOBJ itself which is being actively modified when uevent is sent. During 
the module creation KOBJ_ADD modifies 'kobj->state_add_uevent_sent'. Until 
recent commit, kernel didn't modify KOBJ after sending LIVE notification.

> > This commit breaks some of the projects that rely on the LIVE notification 
> > to
> > monitor when the newly loaded module is ready.
> 
> Hm, could you please explain specifically what is the issue you're seeing?
> What projects is it breaking?
> 

I'm specifically referencing these projects which are tracking kernel modules
for integrity purpose (e.g. anti-rootkit tools) like Linux Kernel Runtime 
Guard.
It is possible to modify these tools to adopt and take into account 
modification of KOBJ after LIVE state notification. However, from my 
understanding of the kernel modules notifiers logic, KOBJ should be fully 
formed at this stage.

Thanks,
Adam

> Thanks,
> 
> Jessica
> 
> [1] https://github.com/systemd/systemd/issues/17586

-- 
pi3 (pi3ki31ny) - pi3 (at) itsec pl
http://pi3.com.pl

[RELEASE] LTTng-modules 2.11.7 and 2.12.4 (Linux kernel tracer)

[Mathieu Desnoyers]

Hi,

I just released versions 2.11.7 and 2.12.4 of the lttng-modules stable branches.
These add support for the 5.10 Linux kernel.

Please try them out, and, as usual, feedback is welcome!

Thanks,

Mathieu

Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: Linux Kernel module notification bug

[Jessica Yu]

+++ Adam Zabrocki [10/01/21 18:54 +0100]:

Hello,

I believe that the following commit does introduce a gentle "functionality
bug":

"module: delay kobject uevent until after module init call":
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/kernel/module.c?id=38dc717e97153e46375ee21797aa54777e5498f3

The official Linux Kernel API for the kernel module activities notification has
been divided based on the readiness 'stage' for such module. We have the
following stages:

   MODULE_STATE_LIVE,  /* Normal state. */
   MODULE_STATE_COMING,/* Full formed, running module_init. */
   MODULE_STATE_GOING, /* Going away. */
   MODULE_STATE_UNFORMED,  /* Still setting it up. */

LIVE means that the kernel module is correctly running and all initialization
work has been already done. Otherwise, we have event 'COMING' or 'UNFORMED'.

In the described commit, creation of the KOBJECT has been moved after invoking
a notficiation of the newly formed kernel module state (LIVE). That's somehow
inconsistent from my understanding of the kernel modules notifiers logic.
Creation of the new objects (like KOBJ) should be done before notification of
the stage LIVE is invoked.


I'm confused. We're not creating any kobjects here. That is all done
in mod_sysfs_setup(), which is called while the module is still
COMING.  What that commit does is delay telling userspace about the
module (specifically, systemd/udev) until the module is basically
ready. Systemd was basically receiving the uevent too early, before
the module has initialized, hence we decided to delay the uevent [1].


This commit breaks some of the projects that rely on the LIVE notification to
monitor when the newly loaded module is ready.


Hm, could you please explain specifically what is the issue you're seeing?
What projects is it breaking?

Thanks,

Jessica

[1] https://github.com/systemd/systemd/issues/17586

Linux Kernel module notification bug

[Adam Zabrocki]

Hello,

I believe that the following commit does introduce a gentle "functionality 
bug":

"module: delay kobject uevent until after module init call":
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/kernel/module.c?id=38dc717e97153e46375ee21797aa54777e5498f3

The official Linux Kernel API for the kernel module activities notification has
been divided based on the readiness 'stage' for such module. We have the
following stages:

MODULE_STATE_LIVE,  /* Normal state. */
MODULE_STATE_COMING,/* Full formed, running module_init. */
MODULE_STATE_GOING, /* Going away. */
MODULE_STATE_UNFORMED,  /* Still setting it up. */

LIVE means that the kernel module is correctly running and all initialization
work has been already done. Otherwise, we have event 'COMING' or 'UNFORMED'.

In the described commit, creation of the KOBJECT has been moved after invoking
a notficiation of the newly formed kernel module state (LIVE). That's somehow
inconsistent from my understanding of the kernel modules notifiers logic.
Creation of the new objects (like KOBJ) should be done before notification of
the stage LIVE is invoked.

This commit breaks some of the projects that rely on the LIVE notification to
monitor when the newly loaded module is ready.

I believe that the latest time when 'kobject_uevent' function can be called is
just before invoking 'blocking_notifier_call_chain', e.g:

diff --git a/kernel/module.c b/kernel/module.c
index 4bf30e4b3eaa..7d56b1b07237 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3681,14 +3681,14 @@ static noinline int do_init_module(struct module *mod)
dump_stack();
}

+   /* Delay uevent until module has finished its init routine */
+   kobject_uevent(>mkobj.kobj, KOBJ_ADD);
+
/* Now it's a first class citizen! */
mod->state = MODULE_STATE_LIVE;
blocking_notifier_call_chain(_notify_list,
 MODULE_STATE_LIVE, mod);

-   /* Delay uevent until module has finished its init routine */
-   kobject_uevent(>mkobj.kobj, KOBJ_ADD);
-
/*
 * We need to finish all async code before the module init sequence
 * is done.  This has potential to deadlock.  For example, a newly

Thanks,
Adam

--
pi3 (pi3ki31ny) - pi3 (at) itsec pl
http://pi3.com.pl

To linux kernel!

[Steven Newbury]

Linux   https://bit.ly/2JY7Ueo  Steven Newbury


I might as well be dead, but I could kill you instead. - PJ Harvey
If you brutalize the world around you, you also brutalize yourself. - Flanders
Falling in Love is a trick our genes pull on our otherwise perceptive mind to 
hoodwink us into marriage. - M. Scott Peck (The Road Less Travelled)

[PATCH -V8 3/3] NOT kernel/numactl: Support to enable Linux kernel NUMA balancing

[Huang Ying]

A new API: numa_set_membind_balancing() is added to libnuma.  It is
same as numa_set_membind() except that the Linux kernel NUMA balancing
will be enabled for the task if the feature is supported by the
kernel.

At the same time, a new option: --balancing (-b) is added to numactl.
Which can be used before the --membind/-m memory policy in the command
line.  With it, the Linux kernel NUMA balancing will be enabled for
the process if --membind/-m is used and the feature is supported by
the kernel.

Signed-off-by: "Huang, Ying" 
---
 libnuma.c | 14 ++
 numa.3| 15 +++
 numa.h|  4 
 numactl.8 | 12 
 numactl.c | 17 ++---
 numaif.h  |  3 +++
 versions.ldscript |  8 
 7 files changed, 70 insertions(+), 3 deletions(-)

diff --git a/libnuma.c b/libnuma.c
index 88f479b..f073c50 100644
--- a/libnuma.c
+++ b/libnuma.c
@@ -1064,6 +1064,20 @@ numa_set_membind_v2(struct bitmask *bmp)
 
 make_internal_alias(numa_set_membind_v2);
 
+void
+numa_set_membind_balancing(struct bitmask *bmp)
+{
+   /* MPOL_F_NUMA_BALANCING: ignore if unsupported */
+   if (set_mempolicy(MPOL_BIND | MPOL_F_NUMA_BALANCING,
+ bmp->maskp, bmp->size + 1) < 0) {
+   if (errno == EINVAL) {
+   errno = 0;
+   numa_set_membind_v2(bmp);
+   } else
+   numa_error("set_mempolicy");
+   }
+}
+
 /*
  * copy a bitmask map body to a numa.h nodemask_t structure
  */
diff --git a/numa.3 b/numa.3
index 3e18098..af01c8f 100644
--- a/numa.3
+++ b/numa.3
@@ -80,6 +80,8 @@ numa \- NUMA policy library
 .br
 .BI "void numa_set_membind(struct bitmask *" nodemask );
 .br
+.BI "void numa_set_membind_balancing(struct bitmask *" nodemask );
+.br
 .B struct bitmask *numa_get_membind(void);
 .sp
 .BI "void *numa_alloc_onnode(size_t " size ", int " node );
@@ -538,6 +540,19 @@ that contains nodes other than those in the mask returned 
by
 .IR numa_get_mems_allowed ()
 will result in an error.
 
+.BR numa_set_membind_balancing ()
+sets the memory allocation mask and enable the Linux kernel NUMA
+balancing for the task if the feature is supported by the kernel.
+The task will only allocate memory from the nodes set in
+.IR nodemask .
+Passing an empty
+.I nodemask
+or a
+.I nodemask
+that contains nodes other than those in the mask returned by
+.IR numa_get_mems_allowed ()
+will result in an error.
+
 .BR numa_get_membind ()
 returns the mask of nodes from which memory can currently be allocated.
 If the returned mask is equal to
diff --git a/numa.h b/numa.h
index bd1d676..5d8543a 100644
--- a/numa.h
+++ b/numa.h
@@ -192,6 +192,10 @@ void numa_set_localalloc(void);
 /* Only allocate memory from the nodes set in mask. 0 to turn off */
 void numa_set_membind(struct bitmask *nodemask);
 
+/* Only allocate memory from the nodes set in mask. Optimize page
+   placement with Linux kernel NUMA balancing if possible. 0 to turn off */
+void numa_set_membind_balancing(struct bitmask *bmp);
+
 /* Return current membind */
 struct bitmask *numa_get_membind(void);
 
diff --git a/numactl.8 b/numactl.8
index f3bb22b..7d52688 100644
--- a/numactl.8
+++ b/numactl.8
@@ -25,6 +25,8 @@ numactl \- Control NUMA policy for processes or shared memory
 [
 .B \-\-all
 ] [
+.B \-\-balancing
+] [
 .B \-\-interleave nodes
 ] [
 .B \-\-preferred node 
@@ -168,6 +170,12 @@ but if memory cannot be allocated there fall back to other 
nodes.
 This option takes only a single node number.
 Relative notation may be used.
 .TP
+.B \-\-balancing, \-b
+Enable Linux kernel NUMA balancing for the process if it is supported by 
kernel.
+This should only be used with
+.I \-\-membind, \-m
+only, otherwise ignored.
+.TP
 .B \-\-show, \-s
 Show NUMA policy settings of the current process. 
 .TP
@@ -278,6 +286,10 @@ numactl \-\-cpunodebind=0 \-\-membind=0,1 -- process -l
 Run process as above, but with an option (-l) that would be confused with
 a numactl option.
 
+numactl \-\-cpunodebind=0 \-\-balancing \-\-membind=0,1 process
+Run process on node 0 with memory allocated on node 0 and 1.  Optimize the
+page placement with Linux kernel NUMA balancing mechanism if possible.
+
 numactl \-\-cpunodebind=netdev:eth0 \-\-membind=netdev:eth0 network-server
 Run network-server on the node of network device eth0 with its memory
 also in the same node.
diff --git a/numactl.c b/numactl.c
index df9dbcb..5a9d2df 100644
--- a/numactl.c
+++ b/numactl.c
@@ -45,6 +45,7 @@ struct option opts[] = {
{"membind", 1, 0, 'm'},
{"show", 0, 0, 's' },
{"localalloc", 0,0, 'l'},
+   {"balancing", 0, 0, 'b'},
{"hardware", 0,0,'H' },
 
{"shm", 1, 0, 'S'},
@@ -65,9 +66,10 @@ struct option opts[] = {
 void usage(void)
 {
fprintf(stderr,
-

How do I account for the Linux kernel development team

[Bruce]

How do I account for the Linux kernel development team？

Re: linux kernel新手想参与文档翻译

[Alex Shi]

CC linux-doc

?? 2020/12/23 11:03, ?? :
> ??
> ?0?2 ?0?2 ?0?2 
> Linux????????kernel??Documentation/translations/zh_CN

 ?? 
??

> ?0?2 ?0?2 ?0?2 
> ??
> ?0?2 ?0?2 ?0?2 
> Documentation/translations/zh_CN??Documentation/??patch??CodingStyle

??coding style,  ?? coding 
style, 
2??
  make help ??make cleandocs/htmldocs  
 htmldocs 
,patch ??Jonathan Corbet 
, cc 

> ?0?2 ?0?2 ?0?2 
> 

 patch review ?? ??

> ?0?2 ?0?2 ?0?2
> ?0?2 ?0?2 ?0?2 

?? ??


Alex 

Re: Linux kernel in-tree Rust support

[Miguel Ojeda]

On Thu, Dec 17, 2020 at 10:45 PM Pavel Machek  wrote:
>
> Well.. not everyone has 32 cores in their notebook.

It is true that complex Rust, like complex C++, does have high
compilation times. But it all depends on how much one relies on
certain language features. Straightforward Rust code is quick to
compile.

For reference, some quick stats :-)

On a given machine, building v5.10 with a minimal config under -j3
takes 3 minutes. With Rust support enabled and 4 trivial Rust modules,
it takes 50 seconds more. "A big increase!", you may indeed claim, but
those 50 seconds are basically all spent on the shared Rust support.
The actual Rust modules compile very quickly afterwards. For example,
touching either `drivers/char/mem.c` or one of the trivial Rust
modules takes the same time in that machine: 10 seconds.

This is for a minimal config -- when you start dealing with
`allmodconfig` builds, or when you start having a hundred Rust modules
instead of 4, the upfront cost becomes very small per Rust module.

> Okay. I did some refactoring recently and I really wished kernel was
> in Rust (and not in C)... so lets see what happens.

Indeed, I think it is definitely worth it.

Cheers,
Miguel

Re: Linux kernel in-tree Rust support

[Pavel Machek]

On Tue 2020-07-28 23:34:17, Josh Triplett wrote:
> On Tue, Jul 28, 2020 at 10:40:38PM +0200, Pavel Machek wrote:
> > > We just need to make sure that any kernel CI infrastructure tests that
> > > right away, then, so that failures don't get introduced by a patch from
> > > someone without a Rust toolchain and not noticed until someone with a
> > > Rust toolchain tests it.
> > 
> > So... I'm fan of Rust, but while trying to use it one thing was obvious: it
> > takes _significantly_ longer than C to compile and needs gigabyte a lot of 
> > RAM.
> > 
> > Kernel is quite big project, can CI infrastructure handle additional load?
> > 
> > Will developers see significantly longer compile times when Rust is 
> > widespread?
> 
> I wouldn't expect the addition of Rust to the kernel to substantially
> impact overall build time; on balance, I'd expect the major bottleneck
> in kernel builds to continue to be linking and other serialized steps,
> not compiling and other highly parallel steps.

Well.. not everyone has 32 cores in their notebook.

> There are also *many* things that can be done to improve Rust build time
> in a project. And I don't expect that in-kernel Rust will have many
> dependencies on third-party crates (since they'd need to be checked into

Okay. I did some refactoring recently and I really wished kernel was
in Rust (and not in C)... so lets see what happens.

Best regards,

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


signature.asc
Description: PGP signature

[tip: efi/core] Merge tag 'efi-next-for-v5.11-3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/core

[tip-bot2 for Thomas Gleixner]

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

Commit-ID: 3dcb8b53cbd2cc5618863b19ef00f8ea82f27e83
Gitweb:
https://git.kernel.org/tip/3dcb8b53cbd2cc5618863b19ef00f8ea82f27e83
Author:Thomas Gleixner 
AuthorDate:Tue, 15 Dec 2020 12:14:38 +01:00
Committer: Thomas Gleixner 
CommitterDate: Tue, 15 Dec 2020 12:14:38 +01:00

Merge tag 'efi-next-for-v5.11-3' of 
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/core

Pull followup fixes for EFI from Ard Biesheuvel:

 - fix the build breakage on IA64 caused by recent capsule loader changes

 - suppress a type mismatch build warning in the expansion of
   EFI_PHYS_ALIGN on ARM

Link: https://lore.kernel.org/r/20201215080144.17077-1-a...@kernel.org
---

[tip: irq/core] Merge tag 'irqchip-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core

[tip-bot2 for Thomas Gleixner]

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

Commit-ID: 3c41e57a1e168d879e923c5583adeae47eec9f64
Gitweb:
https://git.kernel.org/tip/3c41e57a1e168d879e923c5583adeae47eec9f64
Author:Thomas Gleixner 
AuthorDate:Tue, 15 Dec 2020 10:48:07 +01:00
Committer: Thomas Gleixner 
CommitterDate: Tue, 15 Dec 2020 10:48:07 +01:00

Merge tag 'irqchip-5.11' of 
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core

Pull irqchip updates for 5.11 from Marc Zyngier:

  - Preliminary support for managed interrupts on platform devices
  - Correctly identify allocation of MSIs proxyied by another device
  - Remove the fasteoi IPI flow which has been proved useless
  - Generalise the Ocelot support to new SoCs
  - Improve GICv4.1 vcpu entry, matching the corresponding KVM optimisation
  - Work around spurious interrupts on Qualcomm PDC
  - Random fixes and cleanups

Link: https://lore.kernel.org/r/20201212135626.1479884-1-...@kernel.org
---

[tip: irq/core] Merge tag 'irqchip-5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core

[tip-bot2 for Thomas Gleixner]

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

Commit-ID: 559db8c7e6ed1f24baf7264a6966ee4f051c6446
Gitweb:
https://git.kernel.org/tip/559db8c7e6ed1f24baf7264a6966ee4f051c6446
Author:Thomas Gleixner 
AuthorDate:Sat, 12 Dec 2020 20:35:24 +01:00
Committer: Thomas Gleixner 
CommitterDate: Sat, 12 Dec 2020 20:35:24 +01:00

Merge tag 'irqchip-5.11' of 
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/core

Pull irqchip updates for 5.11 from Marc Zyngier:

 - Preliminary support for managed interrupts on platform devices
 - Correctly identify allocation of MSIs proxyied by another device
 - Remove the fasteoi IPI flow which has been proved useless
 - Generalise the Ocelot support to new SoCs
 - Improve GICv4.1 vcpu entry, matching the corresponding KVM optimisation
 - Work around spurious interrupts on Qualcomm PDC
 - Random fixes and cleanups

Link: https://lore.kernel.org/r/20201212135626.1479884-1-...@kernel.org
---

Re: Pass modules to Linux kernel without initrd

[Theodore Y. Ts'o]

On Tue, Dec 08, 2020 at 10:24:08AM +0100, Paul Menzel wrote:
> Dear Linux folks,
> 
> Trying to reduce the boot time of standard distributions, I would like to
> get rid of the initrd. The initrd is for mounting the root file system and
> on most end user systems with standard distributions that means loading the
> bus driver for the drive and the file system driver. Everyone could build
> their own Linux kernel and build the drivers into the Linux kernel, but most
> users enjoy using the distribution Linux kernel, which build the drivers as
> modules to support a lot of systems. (I think Fedora builds the default file
> system driver (of the installer) into the Linux kernel.)

It's unclear what you are trying to speed up by replacing the initrd
with "appending the required modules to the Linux kernel image".  Why
do you think this will speed things up?  What do you think is
currently slow with using an initrd?

If what you are concerned about is the speed to load an initrd which
has all of the kernel modules shipped by the distribution, including
those not needed by a particular hardware platform, there are
distributions which can be configured to automatically include only
those kernel modules needed for a particular system.

There are also some shell scripts which some people have written that
will automatically create a kernel config file which only has the
device drivers needed for a particular system.  Creating a system
which used such a script, and then compiled a custom kernel image
would also not be hard.

You seem to be assuming that building a custom kernel image ish
hard(tm), and so no user would want to do this.  If this were 
automated, what is your objection to such an approach?

Without a clear understanding what part of the boot process you think
is slow, and which you are trying to optimize, and what precisely your
constraints are, or at least, what you *think* your constraints are,
and why you think things have to be that way, it's going to be hard to
comment further.

Cheers,

- Ted

Re: Pass modules to Linux kernel without initrd

[Ben Hutchings]

On Tue, 2020-12-08 at 10:24 +0100, Paul Menzel wrote:
Dear Linux folks,


Trying to reduce the boot time of standard distributions, I would like 
to get rid of the initrd. The initrd is for mounting the root file 
system and on most end user systems with standard distributions that 
means loading the bus driver for the drive and the file system driver.
[...]

I would expect most end user systems to use at least one of LVM and
cryptsetup, which need user-space to configure them.

Debian has the "tiny-initramfs" package that covers the simple cases
you're targetting, and can be used instead of initramfs-tools or
dracut.  The upstream of that is:
.

But I don't anticipate that we would change the default initramfs
builder any time soon.

Ben.

-- 
Ben Hutchings
The world is coming to an end.  Please log off.


signature.asc
Description: This is a digitally signed message part

Re: Pass modules to Linux kernel without initrd

[Enrico Weigelt, metux IT consult]

On 08.12.20 11:58, Paul Menzel wrote:

> Thank you. I know this and do it myself. But, the requirement is to use
> the distribution Linux kernel (package). I am sorry for being unclear.

What about rebuilding the distro package ?

Actually, I wonder why using a generic (bloated) full-blown distro
when resources are that scarce.


--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Re: Pass modules to Linux kernel without initrd

[Paul Menzel]

Dear Enrico,


Am 08.12.20 um 10:38 schrieb Enrico Weigelt, metux IT consult:

On 08.12.20 10:24, Paul Menzel wrote:


Similar to passing firmware and microcode update files to Linux or
building these into the Linux kernel image, would it be possible to
append the required modules to the Linux kernel image, and Linux would
load these?


Indeed, yes it does. Just set the corresponding CONFIG_ symbols to 'y'
instead of 'm'. If you don't need to dynamically load any modules
(already have everything you need compiled-in), you can completely
disable module support via disabling CONFIG_MODULES.


[…]

Thank you. I know this and do it myself. But, the requirement is to use 
the distribution Linux kernel (package). I am sorry for being unclear.



Kind regards,

Paul

Re: Pass modules to Linux kernel without initrd

[Enrico Weigelt, metux IT consult]

On 08.12.20 10:24, Paul Menzel wrote:

> Similar to passing firmware and microcode update files to Linux or
> building these into the Linux kernel image, would it be possible to
> append the required modules to the Linux kernel image, and Linux would
> load these?

Indeed, yes it does. Just set the corresponding CONFIG_ symbols to 'y'
instead of 'm'. If you don't need to dynamically load any modules
(already have everything you need compiled-in), you can completely
disable module support via disabling CONFIG_MODULES.

For embedded systems, this is quite common. I'm also using it for
trimmed down virtualized workloads that don't ever need to dynamically
load modules.

--mtx

-- 
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
i...@metux.net -- +49-151-27565287

Pass modules to Linux kernel without initrd

[Paul Menzel]

Dear Linux folks,


Trying to reduce the boot time of standard distributions, I would like 
to get rid of the initrd. The initrd is for mounting the root file 
system and on most end user systems with standard distributions that 
means loading the bus driver for the drive and the file system driver. 
Everyone could build their own Linux kernel and build the drivers into 
the Linux kernel, but most users enjoy using the distribution Linux 
kernel, which build the drivers as modules to support a lot of systems. 
(I think Fedora builds the default file system driver (of the installer) 
into the Linux kernel.)


A custom minimal initrd init script only loading the modules would also 
work, but as libkmod depends on libcrypto, which as a shared library is 
already three megabytes in size. Building libkmod statically would mean 
for distributions, that you need hooks to rebuild libkmod each time 
OpenSSL is updated (to get the changes).


Similar to passing firmware and microcode update files to Linux or 
building these into the Linux kernel image, would it be possible to 
append the required modules to the Linux kernel image, and Linux would 
load these?


Probably you are going to say, that is not how it works, but maybe I am 
lucky and you know a solution, or could point me to the right direction 
how such a think could be implemented.



Kind regards,

Paul

linux-kernel confirm for me

[Juaquin Dabeer]

Good day,

Please confirm receipt of the previous  mail I sent to  
linux-kernel@vger.kernel.org or do I resend it again?

Regards

Juaquin Dabeer
juaquindab...@mail.com.tr

[PATCH -V7 3/3] NOT kernel/numactl: Support to enable Linux kernel NUMA balancing

[Huang Ying]

A new API: numa_set_membind_balancing() is added to libnuma.  It is
same as numa_set_membind() except that the Linux kernel NUMA balancing
will be enabled for the task if the feature is supported by the
kernel.

At the same time, a new option: --balancing (-b) is added to numactl.
Which can be used before the --membind/-m memory policy in the command
line.  With it, the Linux kernel NUMA balancing will be enabled for
the process if --membind/-m is used and the feature is supported by
the kernel.

Signed-off-by: "Huang, Ying" 
---
 libnuma.c | 14 ++
 numa.3| 15 +++
 numa.h|  4 
 numactl.8 | 12 
 numactl.c | 17 ++---
 numaif.h  |  3 +++
 versions.ldscript |  8 
 7 files changed, 70 insertions(+), 3 deletions(-)

diff --git a/libnuma.c b/libnuma.c
index 88f479b..f073c50 100644
--- a/libnuma.c
+++ b/libnuma.c
@@ -1064,6 +1064,20 @@ numa_set_membind_v2(struct bitmask *bmp)
 
 make_internal_alias(numa_set_membind_v2);
 
+void
+numa_set_membind_balancing(struct bitmask *bmp)
+{
+   /* MPOL_F_NUMA_BALANCING: ignore if unsupported */
+   if (set_mempolicy(MPOL_BIND | MPOL_F_NUMA_BALANCING,
+ bmp->maskp, bmp->size + 1) < 0) {
+   if (errno == EINVAL) {
+   errno = 0;
+   numa_set_membind_v2(bmp);
+   } else
+   numa_error("set_mempolicy");
+   }
+}
+
 /*
  * copy a bitmask map body to a numa.h nodemask_t structure
  */
diff --git a/numa.3 b/numa.3
index 3e18098..af01c8f 100644
--- a/numa.3
+++ b/numa.3
@@ -80,6 +80,8 @@ numa \- NUMA policy library
 .br
 .BI "void numa_set_membind(struct bitmask *" nodemask );
 .br
+.BI "void numa_set_membind_balancing(struct bitmask *" nodemask );
+.br
 .B struct bitmask *numa_get_membind(void);
 .sp
 .BI "void *numa_alloc_onnode(size_t " size ", int " node );
@@ -538,6 +540,19 @@ that contains nodes other than those in the mask returned 
by
 .IR numa_get_mems_allowed ()
 will result in an error.
 
+.BR numa_set_membind_balancing ()
+sets the memory allocation mask and enable the Linux kernel NUMA
+balancing for the task if the feature is supported by the kernel.
+The task will only allocate memory from the nodes set in
+.IR nodemask .
+Passing an empty
+.I nodemask
+or a
+.I nodemask
+that contains nodes other than those in the mask returned by
+.IR numa_get_mems_allowed ()
+will result in an error.
+
 .BR numa_get_membind ()
 returns the mask of nodes from which memory can currently be allocated.
 If the returned mask is equal to
diff --git a/numa.h b/numa.h
index bd1d676..5d8543a 100644
--- a/numa.h
+++ b/numa.h
@@ -192,6 +192,10 @@ void numa_set_localalloc(void);
 /* Only allocate memory from the nodes set in mask. 0 to turn off */
 void numa_set_membind(struct bitmask *nodemask);
 
+/* Only allocate memory from the nodes set in mask. Optimize page
+   placement with Linux kernel NUMA balancing if possible. 0 to turn off */
+void numa_set_membind_balancing(struct bitmask *bmp);
+
 /* Return current membind */
 struct bitmask *numa_get_membind(void);
 
diff --git a/numactl.8 b/numactl.8
index f3bb22b..7d52688 100644
--- a/numactl.8
+++ b/numactl.8
@@ -25,6 +25,8 @@ numactl \- Control NUMA policy for processes or shared memory
 [
 .B \-\-all
 ] [
+.B \-\-balancing
+] [
 .B \-\-interleave nodes
 ] [
 .B \-\-preferred node 
@@ -168,6 +170,12 @@ but if memory cannot be allocated there fall back to other 
nodes.
 This option takes only a single node number.
 Relative notation may be used.
 .TP
+.B \-\-balancing, \-b
+Enable Linux kernel NUMA balancing for the process if it is supported by 
kernel.
+This should only be used with
+.I \-\-membind, \-m
+only, otherwise ignored.
+.TP
 .B \-\-show, \-s
 Show NUMA policy settings of the current process. 
 .TP
@@ -278,6 +286,10 @@ numactl \-\-cpunodebind=0 \-\-membind=0,1 -- process -l
 Run process as above, but with an option (-l) that would be confused with
 a numactl option.
 
+numactl \-\-cpunodebind=0 \-\-balancing \-\-membind=0,1 process
+Run process on node 0 with memory allocated on node 0 and 1.  Optimize the
+page placement with Linux kernel NUMA balancing mechanism if possible.
+
 numactl \-\-cpunodebind=netdev:eth0 \-\-membind=netdev:eth0 network-server
 Run network-server on the node of network device eth0 with its memory
 also in the same node.
diff --git a/numactl.c b/numactl.c
index df9dbcb..5a9d2df 100644
--- a/numactl.c
+++ b/numactl.c
@@ -45,6 +45,7 @@ struct option opts[] = {
{"membind", 1, 0, 'm'},
{"show", 0, 0, 's' },
{"localalloc", 0,0, 'l'},
+   {"balancing", 0, 0, 'b'},
{"hardware", 0,0,'H' },
 
{"shm", 1, 0, 'S'},
@@ -65,9 +66,10 @@ struct option opts[] = {
 void usage(void)
 {
fprintf(stderr,
-

Re: [Linux-kernel-mentees] [PATCH -mmots] checkpatch: add fix for non-standard signature - co-authored-by

[Joe Perches]

On Thu, 2020-12-03 at 20:25 +0100, Greg KH wrote:
> On Thu, Dec 03, 2020 at 08:00:58PM +0100, Lukas Bulwahn wrote:
> > On Thu, Dec 3, 2020 at 7:56 PM Greg KH  wrote:
> > > 
> > > On Thu, Dec 03, 2020 at 11:59:54AM +0100, Lukas Bulwahn wrote:
> > > > On Thu, Dec 3, 2020 at 10:59 AM Aditya  wrote:
> > > > > 
> > > > > On 3/12/20 12:26 am, Joe Perches wrote:
> > > > > > On Thu, 2020-12-03 at 00:00 +0530, Aditya Srivastava wrote:
> > > > > > > Currently, checkpatch.pl warns us for BAD_SIGN_OFF on the usage of
> > > > > > > non-standard signatures.
[]
> > > co-developed-by is the correct tag for this.  It is documented exactly
> > > for this reason, please do not try to use something that is not already
> > > accepted by the kernel developers for this type of thing.

Postel's law should apply here.

And there is a concurrent thread on the ksummit-discuss mailing list
that applies:

https://lore.kernel.org/ksummit-discuss/cafhkne9zsbwrh6-g7og2bbeedgd6scdnztng3znqlvldcdf...@mail.gmail.com/T/#t

I hope all this becomes moot eventually.

Re: [Linux-kernel-mentees] [PATCH -mmots] checkpatch: add fix for non-standard signature - co-authored-by

[Greg KH]

On Thu, Dec 03, 2020 at 08:00:58PM +0100, Lukas Bulwahn wrote:
> On Thu, Dec 3, 2020 at 7:56 PM Greg KH  wrote:
> >
> > On Thu, Dec 03, 2020 at 11:59:54AM +0100, Lukas Bulwahn wrote:
> > > On Thu, Dec 3, 2020 at 10:59 AM Aditya  wrote:
> > > >
> > > > On 3/12/20 12:26 am, Joe Perches wrote:
> > > > > On Thu, 2020-12-03 at 00:00 +0530, Aditya Srivastava wrote:
> > > > >> Currently, checkpatch.pl warns us for BAD_SIGN_OFF on the usage of
> > > > >> non-standard signatures.
> > > > >>
> > > > >> An evaluation on v4.13..v5.8 showed that out of 539 warnings due to
> > > > >> non-standard signatures, 43 are due to the use of 'Co-authored-by'
> > > > >> tag, which may seem correct, but is not standard.
> > > > >>
> > > > >> The standard signature equivalent for 'Co-authored-by' is
> > > > >> 'Co-developed-by'.
> > > > >
> > > > > I'm not going to ack this as I don't mind non-standard signatures.
> > > > >
> > > >
> > > > What do you suggest?
> > > > Should I drop this patch and move on?
> > > >
> > >
> > > Joe does not ack this, but he also does not nack it.
> > >
> > > You either move on (which is perfectly fine), or
> > >
> > > you either wait that Andrew Morton reviews it and accepts it because
> > > he thinks it useful, or
> > >
> > > you reach out to the git committers that have been using
> > > Co-authored-by in the past and ask them if this kind of feature would
> > > have been helpful for them and you get an ack from them that convinces
> > > Andrew Morton to pick this.
> >
> > co-developed-by is the correct tag for this.  It is documented exactly
> > for this reason, please do not try to use something that is not already
> > accepted by the kernel developers for this type of thing.
> >
> 
> Well, Greg, so do we get your Acked-by on a feature that checkpatch
> warns that Co-authored-by is non-standard and that then fixes up the
> patch automatically to Co-developed-by with checkpatch --fix?
> 
> If so, please add your Acked-by on this patch here and let Andrew know
> to pick it...

I have not reviewed the patch, sorry, just was commenting on the fact
that we do have a standard for this.

thanks,

greg k-h

Re: [Linux-kernel-mentees] [PATCH -mmots] checkpatch: add fix for non-standard signature - co-authored-by

[Lukas Bulwahn]

On Thu, Dec 3, 2020 at 7:56 PM Greg KH  wrote:
>
> On Thu, Dec 03, 2020 at 11:59:54AM +0100, Lukas Bulwahn wrote:
> > On Thu, Dec 3, 2020 at 10:59 AM Aditya  wrote:
> > >
> > > On 3/12/20 12:26 am, Joe Perches wrote:
> > > > On Thu, 2020-12-03 at 00:00 +0530, Aditya Srivastava wrote:
> > > >> Currently, checkpatch.pl warns us for BAD_SIGN_OFF on the usage of
> > > >> non-standard signatures.
> > > >>
> > > >> An evaluation on v4.13..v5.8 showed that out of 539 warnings due to
> > > >> non-standard signatures, 43 are due to the use of 'Co-authored-by'
> > > >> tag, which may seem correct, but is not standard.
> > > >>
> > > >> The standard signature equivalent for 'Co-authored-by' is
> > > >> 'Co-developed-by'.
> > > >
> > > > I'm not going to ack this as I don't mind non-standard signatures.
> > > >
> > >
> > > What do you suggest?
> > > Should I drop this patch and move on?
> > >
> >
> > Joe does not ack this, but he also does not nack it.
> >
> > You either move on (which is perfectly fine), or
> >
> > you either wait that Andrew Morton reviews it and accepts it because
> > he thinks it useful, or
> >
> > you reach out to the git committers that have been using
> > Co-authored-by in the past and ask them if this kind of feature would
> > have been helpful for them and you get an ack from them that convinces
> > Andrew Morton to pick this.
>
> co-developed-by is the correct tag for this.  It is documented exactly
> for this reason, please do not try to use something that is not already
> accepted by the kernel developers for this type of thing.
>

Well, Greg, so do we get your Acked-by on a feature that checkpatch
warns that Co-authored-by is non-standard and that then fixes up the
patch automatically to Co-developed-by with checkpatch --fix?

If so, please add your Acked-by on this patch here and let Andrew know
to pick it...

Lukas

Re: [Linux-kernel-mentees] [PATCH -mmots] checkpatch: add fix for non-standard signature - co-authored-by

[Greg KH]

On Thu, Dec 03, 2020 at 11:59:54AM +0100, Lukas Bulwahn wrote:
> On Thu, Dec 3, 2020 at 10:59 AM Aditya  wrote:
> >
> > On 3/12/20 12:26 am, Joe Perches wrote:
> > > On Thu, 2020-12-03 at 00:00 +0530, Aditya Srivastava wrote:
> > >> Currently, checkpatch.pl warns us for BAD_SIGN_OFF on the usage of
> > >> non-standard signatures.
> > >>
> > >> An evaluation on v4.13..v5.8 showed that out of 539 warnings due to
> > >> non-standard signatures, 43 are due to the use of 'Co-authored-by'
> > >> tag, which may seem correct, but is not standard.
> > >>
> > >> The standard signature equivalent for 'Co-authored-by' is
> > >> 'Co-developed-by'.
> > >
> > > I'm not going to ack this as I don't mind non-standard signatures.
> > >
> >
> > What do you suggest?
> > Should I drop this patch and move on?
> >
> 
> Joe does not ack this, but he also does not nack it.
> 
> You either move on (which is perfectly fine), or
> 
> you either wait that Andrew Morton reviews it and accepts it because
> he thinks it useful, or
> 
> you reach out to the git committers that have been using
> Co-authored-by in the past and ask them if this kind of feature would
> have been helpful for them and you get an ack from them that convinces
> Andrew Morton to pick this.

co-developed-by is the correct tag for this.  It is documented exactly
for this reason, please do not try to use something that is not already
accepted by the kernel developers for this type of thing.

thanks,

greg k-h

Re: [PATCH -V6 RESEND 3/3] NOT kernel/numactl: Support to enable Linux kernel NUMA balancing

[Mel Gorman]

On Wed, Dec 02, 2020 at 04:42:34PM +0800, Huang Ying wrote:
> A new API: numa_set_membind_balancing() is added to libnuma.  It is
> same as numa_set_membind() except that the Linux kernel NUMA balancing
> will be enabled for the task if the feature is supported by the
> kernel.
> 
> At the same time, a new option: --balancing (-b) is added to numactl.
> Which can be used before the memory policy options in the command
> line.  With it, the Linux kernel NUMA balancing will be enabled for
> the process if the feature is supported by the kernel.
> 
> Signed-off-by: "Huang, Ying" 
> index f3bb22b..109dd8f 100644
> --- a/numactl.8
> +++ b/numactl.8
> @@ -25,6 +25,8 @@ numactl \- Control NUMA policy for processes or shared 
> memory
>  [
>  .B \-\-all
>  ] [
> +.B \-\-balancing
> +] [

--balancing is a bit vague, maybe --balance-bind? The intent is to hint
that it's specific to MPOL_BIND at this time.

-- 
Mel Gorman
SUSE Labs

[PATCH -V6 RESEND 3/3] NOT kernel/numactl: Support to enable Linux kernel NUMA balancing

[Huang Ying]

A new API: numa_set_membind_balancing() is added to libnuma.  It is
same as numa_set_membind() except that the Linux kernel NUMA balancing
will be enabled for the task if the feature is supported by the
kernel.

At the same time, a new option: --balancing (-b) is added to numactl.
Which can be used before the memory policy options in the command
line.  With it, the Linux kernel NUMA balancing will be enabled for
the process if the feature is supported by the kernel.

Signed-off-by: "Huang, Ying" 
---
 libnuma.c | 14 ++
 numa.3| 15 +++
 numa.h|  4 
 numactl.8 |  9 +
 numactl.c | 17 ++---
 numaif.h  |  3 +++
 versions.ldscript |  8 
 7 files changed, 67 insertions(+), 3 deletions(-)

diff --git a/libnuma.c b/libnuma.c
index 88f479b..f073c50 100644
--- a/libnuma.c
+++ b/libnuma.c
@@ -1064,6 +1064,20 @@ numa_set_membind_v2(struct bitmask *bmp)
 
 make_internal_alias(numa_set_membind_v2);
 
+void
+numa_set_membind_balancing(struct bitmask *bmp)
+{
+   /* MPOL_F_NUMA_BALANCING: ignore if unsupported */
+   if (set_mempolicy(MPOL_BIND | MPOL_F_NUMA_BALANCING,
+ bmp->maskp, bmp->size + 1) < 0) {
+   if (errno == EINVAL) {
+   errno = 0;
+   numa_set_membind_v2(bmp);
+   } else
+   numa_error("set_mempolicy");
+   }
+}
+
 /*
  * copy a bitmask map body to a numa.h nodemask_t structure
  */
diff --git a/numa.3 b/numa.3
index 3e18098..af01c8f 100644
--- a/numa.3
+++ b/numa.3
@@ -80,6 +80,8 @@ numa \- NUMA policy library
 .br
 .BI "void numa_set_membind(struct bitmask *" nodemask );
 .br
+.BI "void numa_set_membind_balancing(struct bitmask *" nodemask );
+.br
 .B struct bitmask *numa_get_membind(void);
 .sp
 .BI "void *numa_alloc_onnode(size_t " size ", int " node );
@@ -538,6 +540,19 @@ that contains nodes other than those in the mask returned 
by
 .IR numa_get_mems_allowed ()
 will result in an error.
 
+.BR numa_set_membind_balancing ()
+sets the memory allocation mask and enable the Linux kernel NUMA
+balancing for the task if the feature is supported by the kernel.
+The task will only allocate memory from the nodes set in
+.IR nodemask .
+Passing an empty
+.I nodemask
+or a
+.I nodemask
+that contains nodes other than those in the mask returned by
+.IR numa_get_mems_allowed ()
+will result in an error.
+
 .BR numa_get_membind ()
 returns the mask of nodes from which memory can currently be allocated.
 If the returned mask is equal to
diff --git a/numa.h b/numa.h
index bd1d676..5d8543a 100644
--- a/numa.h
+++ b/numa.h
@@ -192,6 +192,10 @@ void numa_set_localalloc(void);
 /* Only allocate memory from the nodes set in mask. 0 to turn off */
 void numa_set_membind(struct bitmask *nodemask);
 
+/* Only allocate memory from the nodes set in mask. Optimize page
+   placement with Linux kernel NUMA balancing if possible. 0 to turn off */
+void numa_set_membind_balancing(struct bitmask *bmp);
+
 /* Return current membind */
 struct bitmask *numa_get_membind(void);
 
diff --git a/numactl.8 b/numactl.8
index f3bb22b..109dd8f 100644
--- a/numactl.8
+++ b/numactl.8
@@ -25,6 +25,8 @@ numactl \- Control NUMA policy for processes or shared memory
 [
 .B \-\-all
 ] [
+.B \-\-balancing
+] [
 .B \-\-interleave nodes
 ] [
 .B \-\-preferred node 
@@ -168,6 +170,9 @@ but if memory cannot be allocated there fall back to other 
nodes.
 This option takes only a single node number.
 Relative notation may be used.
 .TP
+.B \-\-balancing, \-b
+Enable Linux kernel NUMA balancing for the process if it is supported by 
kernel.
+.TP
 .B \-\-show, \-s
 Show NUMA policy settings of the current process. 
 .TP
@@ -278,6 +283,10 @@ numactl \-\-cpunodebind=0 \-\-membind=0,1 -- process -l
 Run process as above, but with an option (-l) that would be confused with
 a numactl option.
 
+numactl \-\-cpunodebind=0 \-\-balancing \-\-membind=0,1 process
+Run process on node 0 with memory allocated on node 0 and 1.  Optimize the
+page placement with Linux kernel NUMA balancing mechanism if possible.
+
 numactl \-\-cpunodebind=netdev:eth0 \-\-membind=netdev:eth0 network-server
 Run network-server on the node of network device eth0 with its memory
 also in the same node.
diff --git a/numactl.c b/numactl.c
index df9dbcb..5a9d2df 100644
--- a/numactl.c
+++ b/numactl.c
@@ -45,6 +45,7 @@ struct option opts[] = {
{"membind", 1, 0, 'm'},
{"show", 0, 0, 's' },
{"localalloc", 0,0, 'l'},
+   {"balancing", 0, 0, 'b'},
{"hardware", 0,0,'H' },
 
{"shm", 1, 0, 'S'},
@@ -65,9 +66,10 @@ struct option opts[] = {
 void usage(void)
 {
fprintf(stderr,
-   "usage: numactl [--all | -a] [--interleave= | -i ] 
[--preferred= | -p ]\n"
-   "

Re: linux-kernel: Unused static inline functions

[Joe Perches]

On Fri, 2020-03-06 at 16:07 -0800, Joe Perches wrote:
> On Fri, 2020-03-06 at 11:02 -0800, Nick Desaulniers wrote:
> > Turns out there are hundreds of unused static inline
> > > functions in kernel .h files.
> > > 
> > > A trivial script to find some of them (with likely
> > > false positives as some might actually be used via ##
> > > token pasting mechanisms).

Hey Nick.  It's been several months.  Did you want to do
anything with this list?  Maybe your newbie minions?

> > > (and there's almost certainly a better way to do this
> > >  too as it takes a _very_ long time to run)
> > > 
> > > $ grep-2.5.4 -rP --include=*.h '^[ 
> > > \t]*static\s+inline\s+(?:\w+\s+){1,3}\w+[ \t]*\(' * | \
> > >   grep -P -oh '\w+\s*\(' | \
> > >   sort | uniq -c | sort -n | grep -P '^\s+1\b' | \
> > >   sed -r -e 's/^\s+1\s+//' -e 's/\(//' | \
> > >   while read line ; do \
> > > echo -n "$line: " ; git grep -w $line | wc -l ; \
> > >   done | \
> > >   grep ": 1$"
> > 
> > Please start sending patches to remove them and I'll review.  If this
> > is a good amount of work, I have newbies that are looking to
> > contribute and can help.
> 
> Hello Nick.
> 
> Here is the current result of a slightly different run
> excluding ALL_UPPERCASE variants.  Those upper case entries
> may have been autogenerated and are likely inappropriate to
> be removed.
> 
> There are 1395 functions.  Some are uapi and those should
> likely not be removed.
> 
> All of these below may be unused, defined but unused, but
> it's possible some may be used by token-pasting.
> 
> arch/alpha/include/asm/io.h:183:static inline void generic_iounmap(volatile 
> void __iomem *a)
> arch/alpha/include/asm/io.h:188:static inline int generic_is_ioaddr(unsigned 
> long a)
> arch/alpha/include/asm/io.h:193:static inline int generic_is_mmio(const 
> volatile void __iomem *a)
> arch/alpha/include/asm/pal.h:121:qemu_get_walltime(void)
> arch/alpha/include/asm/pal.h:135:qemu_get_alarm(void)
> arch/alpha/include/uapi/asm/fpu.h:109:ieee_fpcr_to_swcr(unsigned long fp)
> arch/arc/include/asm/unwind.h:117:arch_unwind_init_running(struct 
> unwind_frame_info *info,
> arch/arc/include/asm/unwind.h:125:static inline int arch_unw_user_mode(const 
> struct unwind_frame_info *info)
> arch/arc/include/asm/unwind.h:130:static inline void 
> arch_unw_init_blocked(struct unwind_frame_info *info)
> arch/arc/include/asm/unwind.h:135:static inline void 
> arch_unw_init_frame_info(struct unwind_frame_info *info,
> arch/arm64/include/asm/arch_timer.h:67:static inline notrace u32 
> arch_timer_read_cntp_tval_el0(void)
> arch/arm64/include/asm/arch_timer.h:72:static inline notrace u32 
> arch_timer_read_cntv_tval_el0(void)
> arch/arm64/include/asm/arch_timer.h:77:static inline notrace u64 
> arch_timer_read_cntpct_el0(void)
> arch/arm64/include/asm/arch_timer.h:82:static inline notrace u64 
> arch_timer_read_cntvct_el0(void)
> arch/arm64/include/asm/atomic_ll_sc.h:237:__ll_sc_atomic64_dec_if_positive(atomic64_t
>  *v)
> arch/arm64/include/asm/atomic_lse.h:111:static inline void 
> __lse_atomic_sub(int i, atomic_t *v)
> arch/arm64/include/asm/atomic_lse.h:233:static inline void 
> __lse_atomic64_and(s64 i, atomic64_t *v)
> arch/arm64/include/asm/atomic_lse.h:264:static inline void 
> __lse_atomic64_sub(s64 i, atomic64_t *v)
> arch/arm64/include/asm/atomic_lse.h:319:static inline s64 
> __lse_atomic64_dec_if_positive(atomic64_t *v)
> arch/arm64/include/asm/atomic_lse.h:80:static inline void 
> __lse_atomic_and(int i, atomic_t *v)
> arch/arm64/include/asm/kvm_emulate.h:140:static inline unsigned long 
> vcpu_read_elr_el1(const struct kvm_vcpu *vcpu)
> arch/arm64/include/asm/kvm_emulate.h:197:static inline unsigned long 
> vcpu_read_spsr(const struct kvm_vcpu *vcpu)
> arch/arm64/include/asm/module.h:65:static inline bool 
> plt_entry_is_initialized(const struct plt_entry *e)
> arch/arm64/include/asm/pgtable.h:191:static inline pte_t pte_mknoncont(pte_t 
> pte)
> arch/arm64/include/asm/pgtable.h:316:static inline pmd_t pud_pmd(pud_t pud)
> arch/arm64/include/asm/uaccess.h:176:static inline void 
> __uaccess_disable_hw_pan(void)
> arch/arm/include/asm/bitops.h:107:atomic_test_and_change_bit(unsigned int 
> bit, volatile unsigned long *p)
> arch/arm/include/asm/bitops.h:36:static inline void 
> atomic_set_bit(unsigned int bit, volatile unsigned long *p)
> arch/arm/include/asm/bitops.h:48:static inline void 
> atomic_clear_bit(unsigned int bit, volatile unsigned long *p)
> arch/arm/include/asm/bitops.h:60:static inline void 
> atomic_change_bit(unsigned int bit, volatile unsigned long *p)
> arch/arm/include/asm/bitops.h:73:atomic_test_and_set_bit(unsigned int 
> bit, volatile unsigned long *p)
> arch/arm/include/asm/bitops.h:90:atomic_test_and_clear_bit(unsigned int 
> bit, volatile unsigned long *p)
> arch/arm/include/asm/cputype.h:246:static inline unsigned int 
> __attribute_const__ xscale_cpu_arch_version(void)
> arch/arm/include/asm/floppy.h:75:static inline void 

[PATCH -V6 3/3] NOT kernel/numactl: Support to enable Linux kernel NUMA balancing

[Huang Ying]

From: Huang Ying 

A new API: numa_set_membind_balancing() is added to libnuma.  It is
same as numa_set_membind() except that the Linux kernel NUMA balancing
will be enabled for the task if the feature is supported by the
kernel.

At the same time, a new option: --balancing (-b) is added to numactl.
Which can be used before the memory policy options in the command
line.  With it, the Linux kernel NUMA balancing will be enabled for
the process if the feature is supported by the kernel.

Signed-off-by: "Huang, Ying" 
---
 libnuma.c | 14 ++
 numa.3| 15 +++
 numa.h|  4 
 numactl.8 |  9 +
 numactl.c | 17 ++---
 numaif.h  |  3 +++
 versions.ldscript |  8 
 7 files changed, 67 insertions(+), 3 deletions(-)

diff --git a/libnuma.c b/libnuma.c
index 88f479b..f073c50 100644
--- a/libnuma.c
+++ b/libnuma.c
@@ -1064,6 +1064,20 @@ numa_set_membind_v2(struct bitmask *bmp)
 
 make_internal_alias(numa_set_membind_v2);
 
+void
+numa_set_membind_balancing(struct bitmask *bmp)
+{
+   /* MPOL_F_NUMA_BALANCING: ignore if unsupported */
+   if (set_mempolicy(MPOL_BIND | MPOL_F_NUMA_BALANCING,
+ bmp->maskp, bmp->size + 1) < 0) {
+   if (errno == EINVAL) {
+   errno = 0;
+   numa_set_membind_v2(bmp);
+   } else
+   numa_error("set_mempolicy");
+   }
+}
+
 /*
  * copy a bitmask map body to a numa.h nodemask_t structure
  */
diff --git a/numa.3 b/numa.3
index 3e18098..c44ee50 100644
--- a/numa.3
+++ b/numa.3
@@ -80,6 +80,8 @@ numa \- NUMA policy library
 .br
 .BI "void numa_set_membind(struct bitmask *" nodemask );
 .br
+.BI "void numa_set_membind_balancing(struct bitmask *" nodemask );
+.br
 .B struct bitmask *numa_get_membind(void);
 .sp
 .BI "void *numa_alloc_onnode(size_t " size ", int " node );
@@ -538,6 +540,19 @@ that contains nodes other than those in the mask returned 
by
 .IR numa_get_mems_allowed ()
 will result in an error.
 
+.BR numa_set_membind_balancing ()
+sets the memory allocation mask and enable the Linux kernel NUMA
+balancing for the task if the feature is supported by the kernel.  The
+task will only allocate memory from the nodes set in
+.IR nodemask .
+Passing an empty
+.I nodemask
+or a
+.I nodemask
+that contains nodes other than those in the mask returned by
+.IR numa_get_mems_allowed ()
+will result in an error.
+
 .BR numa_get_membind ()
 returns the mask of nodes from which memory can currently be allocated.
 If the returned mask is equal to
diff --git a/numa.h b/numa.h
index bd1d676..5d8543a 100644
--- a/numa.h
+++ b/numa.h
@@ -192,6 +192,10 @@ void numa_set_localalloc(void);
 /* Only allocate memory from the nodes set in mask. 0 to turn off */
 void numa_set_membind(struct bitmask *nodemask);
 
+/* Only allocate memory from the nodes set in mask. Optimize page
+   placement with Linux kernel NUMA balancing if possible. 0 to turn off */
+void numa_set_membind_balancing(struct bitmask *bmp);
+
 /* Return current membind */
 struct bitmask *numa_get_membind(void);
 
diff --git a/numactl.8 b/numactl.8
index f3bb22b..109dd8f 100644
--- a/numactl.8
+++ b/numactl.8
@@ -25,6 +25,8 @@ numactl \- Control NUMA policy for processes or shared memory
 [
 .B \-\-all
 ] [
+.B \-\-balancing
+] [
 .B \-\-interleave nodes
 ] [
 .B \-\-preferred node 
@@ -168,6 +170,9 @@ but if memory cannot be allocated there fall back to other 
nodes.
 This option takes only a single node number.
 Relative notation may be used.
 .TP
+.B \-\-balancing, \-b
+Enable Linux kernel NUMA balancing for the process if it is supported by 
kernel.
+.TP
 .B \-\-show, \-s
 Show NUMA policy settings of the current process. 
 .TP
@@ -278,6 +283,10 @@ numactl \-\-cpunodebind=0 \-\-membind=0,1 -- process -l
 Run process as above, but with an option (-l) that would be confused with
 a numactl option.
 
+numactl \-\-cpunodebind=0 \-\-balancing \-\-membind=0,1 process
+Run process on node 0 with memory allocated on node 0 and 1.  Optimize the
+page placement with Linux kernel NUMA balancing mechanism if possible.
+
 numactl \-\-cpunodebind=netdev:eth0 \-\-membind=netdev:eth0 network-server
 Run network-server on the node of network device eth0 with its memory
 also in the same node.
diff --git a/numactl.c b/numactl.c
index df9dbcb..5a9d2df 100644
--- a/numactl.c
+++ b/numactl.c
@@ -45,6 +45,7 @@ struct option opts[] = {
{"membind", 1, 0, 'm'},
{"show", 0, 0, 's' },
{"localalloc", 0,0, 'l'},
+   {"balancing", 0, 0, 'b'},
{"hardware", 0,0,'H' },
 
{"shm", 1, 0, 'S'},
@@ -65,9 +66,10 @@ struct option opts[] = {
 void usage(void)
 {
fprintf(stderr,
-   "usage: numactl [--all | -a] [--interleave= | -i ] 
[--preferred= | -p ]

[tip: irq/urgent] Merge tag 'irqchip-fixes-5.10-2' of git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent

[tip-bot2 for Thomas Gleixner]

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

Commit-ID: 7032908cd5842af9710de4815a456241b5e6d2d1
Gitweb:
https://git.kernel.org/tip/7032908cd5842af9710de4815a456241b5e6d2d1
Author:Thomas Gleixner 
AuthorDate:Wed, 25 Nov 2020 00:56:28 +01:00
Committer: Thomas Gleixner 
CommitterDate: Wed, 25 Nov 2020 00:56:28 +01:00

Merge tag 'irqchip-fixes-5.10-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms into irq/urgent

Pull irqchip fixes from Marc Zyngier:

 - Fix Exiu driver trigger type when using ACPI

 - Fix GICv3 ITS suspend/resume to use the in-kernel path
   at all times, sidestepping braindead firmware support

Link: https://lore.kernel.org/r/20201122184752.553990-1-...@kernel.org
---

linux-kernel@vger.kernel.org waiting to hear from you

[Mazer]

Greetings,

I write to solicit for your assistance in a benefiting  business 
proposal and I will be pleased to explain my plans 
and carried it out legally and transparently, so i want to know 
if i can trust you to discuss details of the business and send 
you my proposal and my credentials once i receive your humble 
reply.

Mazer

Re: [Linux-kernel-mentees] [PATCH v5 net] rose: Fix Null pointer dereference in rose_send_frame()

[Jakub Kicinski]

On Fri, 20 Nov 2020 00:40:43 +0530 Anmol Karn wrote:
> rose_send_frame() dereferences `neigh->dev` when called from
> rose_transmit_clear_request(), and the first occurrence of the
> `neigh` is in rose_loopback_timer() as `rose_loopback_neigh`,
> and it is initialized in rose_add_loopback_neigh() as NULL.
> i.e when `rose_loopback_neigh` used in rose_loopback_timer()
> its `->dev` was still NULL and rose_loopback_timer() was calling
> rose_rx_call_request() without checking for NULL.
> 
> - net/rose/rose_link.c
> This bug seems to get triggered in this line:
> 
> rose_call = (ax25_address *)neigh->dev->dev_addr;
> 
> Fix it by adding NULL checking for `rose_loopback_neigh->dev`
> in rose_loopback_timer().
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Suggested-by: Jakub Kicinski 
> Reported-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
> Tested-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
> Link: 
> https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3
> Signed-off-by: Anmol Karn 

Applied to net, thanks!

[Linux-kernel-mentees] [PATCH v5 net] rose: Fix Null pointer dereference in rose_send_frame()

[Anmol Karn]

rose_send_frame() dereferences `neigh->dev` when called from
rose_transmit_clear_request(), and the first occurrence of the
`neigh` is in rose_loopback_timer() as `rose_loopback_neigh`,
and it is initialized in rose_add_loopback_neigh() as NULL.
i.e when `rose_loopback_neigh` used in rose_loopback_timer()
its `->dev` was still NULL and rose_loopback_timer() was calling
rose_rx_call_request() without checking for NULL.

- net/rose/rose_link.c
This bug seems to get triggered in this line:

rose_call = (ax25_address *)neigh->dev->dev_addr;

Fix it by adding NULL checking for `rose_loopback_neigh->dev`
in rose_loopback_timer().

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Suggested-by: Jakub Kicinski 
Reported-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
Tested-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
Link: 
https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3
Signed-off-by: Anmol Karn 
---
Changes in v5:
- Free `dev` in rose_rx_call_request() and add NULL check for `dev` 
before freeing it.
(Suggested-by: Jakub Kicinski )
Changes in v4:
- Free `dev`(on dev_hold()), when neigh->dev is NULL. (Suggested-by: 
Jakub Kicinski )
Changes in v3:
- Corrected checkpatch warnings and errors (Suggested-by: Saeed 
Mahameed )
- Added "Fixes:" tag (Suggested-by: Saeed Mahameed )
Changes in v2:
- Added NULL check in rose_loopback_timer() (Suggested-by: Greg KH 
)

 net/rose/rose_loopback.c | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)

diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
index 7b094275ea8b..11c45c8c6c16 100644
--- a/net/rose/rose_loopback.c
+++ b/net/rose/rose_loopback.c
@@ -96,10 +96,19 @@ static void rose_loopback_timer(struct timer_list *unused)
}

if (frametype == ROSE_CALL_REQUEST) {
-   if ((dev = rose_dev_get(dest)) != NULL) {
-   if (rose_rx_call_request(skb, dev, 
rose_loopback_neigh, lci_o) == 0)
-   kfree_skb(skb);
-   } else {
+   if (!rose_loopback_neigh->dev) {
+   kfree_skb(skb);
+   continue;
+   }
+
+   dev = rose_dev_get(dest);
+   if (!dev) {
+   kfree_skb(skb);
+   continue;
+   }
+
+   if (rose_rx_call_request(skb, dev, rose_loopback_neigh, 
lci_o) == 0) {
+   dev_put(dev);
kfree_skb(skb);
}
} else {
--
2.29.2

Re: [Linux-kernel-mentees] [PATCH v4 net] rose: Fix Null pointer dereference in rose_send_frame()

[Anmol Karn]

On Sat, Nov 14, 2020 at 11:18:38AM -0800, Jakub Kicinski wrote:
> On Wed, 11 Nov 2020 22:29:54 +0530 Anmol Karn wrote:
> > rose_send_frame() dereferences `neigh->dev` when called from
> > rose_transmit_clear_request(), and the first occurrence of the
> > `neigh` is in rose_loopback_timer() as `rose_loopback_neigh`,
> > and it is initialized in rose_add_loopback_neigh() as NULL.
> > i.e when `rose_loopback_neigh` used in rose_loopback_timer()
> > its `->dev` was still NULL and rose_loopback_timer() was calling
> > rose_rx_call_request() without checking for NULL.
> > 
> > - net/rose/rose_link.c
> > This bug seems to get triggered in this line:
> > 
> > rose_call = (ax25_address *)neigh->dev->dev_addr;
> > 
> > Fix it by adding NULL checking for `rose_loopback_neigh->dev`
> > in rose_loopback_timer().
> > 
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Reported-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
> > Tested-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
> > Link: 
> > https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3
> > Signed-off-by: Anmol Karn 
> 
> > diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
> > index 7b094275ea8b..6a71b6947d92 100644
> > --- a/net/rose/rose_loopback.c
> > +++ b/net/rose/rose_loopback.c
> > @@ -96,10 +96,12 @@ static void rose_loopback_timer(struct timer_list 
> > *unused)
> > }
> > 
> > if (frametype == ROSE_CALL_REQUEST) {
> > -   if ((dev = rose_dev_get(dest)) != NULL) {
> > +   dev = rose_dev_get(dest);
> > +   if (rose_loopback_neigh->dev && dev) {
> > if (rose_rx_call_request(skb, dev, 
> > rose_loopback_neigh, lci_o) == 0)
> > kfree_skb(skb);
> > } else {
> > +   dev_put(dev);
> > kfree_skb(skb);
> > }
> > } else {
> 
> This is still not correct. With this code dev_put() could be called with
> NULL, which would cause a crash.
> 
> There is also a dev_put() missing if rose_rx_call_request() returns 0.
> 
> I think that this is the correct code:
> 
> diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
> index 7b094275ea8b..ff252ef73592 100644
> --- a/net/rose/rose_loopback.c
> +++ b/net/rose/rose_loopback.c
> @@ -96,11 +96,22 @@ static void rose_loopback_timer(struct timer_list *unused)
>   }
>  
>   if (frametype == ROSE_CALL_REQUEST) {
> - if ((dev = rose_dev_get(dest)) != NULL) {
> - if (rose_rx_call_request(skb, dev, 
> rose_loopback_neigh, lci_o) == 0)
> - kfree_skb(skb);
> - } else {
> + if (!rose_loopback_neigh->dev) {
>   kfree_skb(skb);
> + continue;
> + }
> +
> + dev = rose_dev_get(dest);
> + if (!dev) {
> + kfree_skb(skb);
> + continue;
> + }
> +
> + if (rose_rx_call_request(skb, dev, rose_loopback_neigh,
> +  lci_o) == 0) {
> + dev_put(dev);
> + kfree_skb(skb);
>   }
>   } else {
>   kfree_skb(skb);
> 
> Please test this and resubmit it if it works.

Sure sir, I will test it and resend, if it works.


Thanks,
Anmol

Re: Has the linux-kernel already implemented the functions in apollo-kernel?

[Greg KH]

On Sat, Oct 31, 2020 at 02:44:07PM +0800, Hongyi Zhao wrote:
> Hi,
> 
> The apollo-kernel (https://github.com/ApolloAuto/apollo-kernel) is a
> patched Linux Kernel based on official Linux Kernel 4.4.32 with some
> modifications on the kernel level, especially for the scenario
> necessary to run the Apollo (https://github.com/ApolloAuto/apollo)
> open autonomous driving platform software stack.
> 
> According to the official description as shown
> <https://github.com/ApolloAuto/apollo-kernel#what-is-the-difference>,
> the major difference from the original Linux kernel is as follows:
> 
> 
> - Realtime patch (https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO)
> - Latest e1000e intel ethernet driver
> - Bugfix for Nvidia driver under realtime patch
> - Double free in the inet_csk_clone_lock function patch
> (https://bugzilla.redhat.com/show_bug.cgi?id=1450972)
> - Other cve security patches
> 
> 
> However, considering that Linux Kernel 4.4.32 is a fairly old version,
> so I want to know whether the modifications/fixes applied/added have
> been already available in the current Linux kernel.
> 
> Any hints will be highly appreciated.

As you have the source to both trees, why not compare them and see if
all of this is true or not?  That's the best way to be sure.

good luck!

greg k-h

Re: [Linux-kernel-mentees] [PATCH v4 net] rose: Fix Null pointer dereference in rose_send_frame()

[Jakub Kicinski]

On Wed, 11 Nov 2020 22:29:54 +0530 Anmol Karn wrote:
> rose_send_frame() dereferences `neigh->dev` when called from
> rose_transmit_clear_request(), and the first occurrence of the
> `neigh` is in rose_loopback_timer() as `rose_loopback_neigh`,
> and it is initialized in rose_add_loopback_neigh() as NULL.
> i.e when `rose_loopback_neigh` used in rose_loopback_timer()
> its `->dev` was still NULL and rose_loopback_timer() was calling
> rose_rx_call_request() without checking for NULL.
> 
> - net/rose/rose_link.c
> This bug seems to get triggered in this line:
> 
> rose_call = (ax25_address *)neigh->dev->dev_addr;
> 
> Fix it by adding NULL checking for `rose_loopback_neigh->dev`
> in rose_loopback_timer().
> 
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reported-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
> Tested-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
> Link: 
> https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3
> Signed-off-by: Anmol Karn 

> diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
> index 7b094275ea8b..6a71b6947d92 100644
> --- a/net/rose/rose_loopback.c
> +++ b/net/rose/rose_loopback.c
> @@ -96,10 +96,12 @@ static void rose_loopback_timer(struct timer_list *unused)
>   }
> 
>   if (frametype == ROSE_CALL_REQUEST) {
> - if ((dev = rose_dev_get(dest)) != NULL) {
> + dev = rose_dev_get(dest);
> + if (rose_loopback_neigh->dev && dev) {
>   if (rose_rx_call_request(skb, dev, 
> rose_loopback_neigh, lci_o) == 0)
>   kfree_skb(skb);
>   } else {
> + dev_put(dev);
>   kfree_skb(skb);
>   }
>   } else {

This is still not correct. With this code dev_put() could be called with
NULL, which would cause a crash.

There is also a dev_put() missing if rose_rx_call_request() returns 0.

I think that this is the correct code:

diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
index 7b094275ea8b..ff252ef73592 100644
--- a/net/rose/rose_loopback.c
+++ b/net/rose/rose_loopback.c
@@ -96,11 +96,22 @@ static void rose_loopback_timer(struct timer_list *unused)
}
 
if (frametype == ROSE_CALL_REQUEST) {
-   if ((dev = rose_dev_get(dest)) != NULL) {
-   if (rose_rx_call_request(skb, dev, 
rose_loopback_neigh, lci_o) == 0)
-   kfree_skb(skb);
-   } else {
+   if (!rose_loopback_neigh->dev) {
kfree_skb(skb);
+   continue;
+   }
+
+   dev = rose_dev_get(dest);
+   if (!dev) {
+   kfree_skb(skb);
+   continue;
+   }
+
+   if (rose_rx_call_request(skb, dev, rose_loopback_neigh,
+lci_o) == 0) {
+   dev_put(dev);
+   kfree_skb(skb);
}
} else {
kfree_skb(skb);

Please test this and resubmit it if it works.

[Linux-kernel-mentees] [PATCH v4 net] rose: Fix Null pointer dereference in rose_send_frame()

[Anmol Karn]

rose_send_frame() dereferences `neigh->dev` when called from
rose_transmit_clear_request(), and the first occurrence of the
`neigh` is in rose_loopback_timer() as `rose_loopback_neigh`,
and it is initialized in rose_add_loopback_neigh() as NULL.
i.e when `rose_loopback_neigh` used in rose_loopback_timer()
its `->dev` was still NULL and rose_loopback_timer() was calling
rose_rx_call_request() without checking for NULL.

- net/rose/rose_link.c
This bug seems to get triggered in this line:

rose_call = (ax25_address *)neigh->dev->dev_addr;

Fix it by adding NULL checking for `rose_loopback_neigh->dev`
in rose_loopback_timer().

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
Tested-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
Link: 
https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3
Signed-off-by: Anmol Karn 
---
Changes in v4:
- Free `dev`(on dev_hold()), when neigh->dev is NULL. (Suggested-by: 
Jakub Kicinski )
Changes in v3:
- Corrected checkpatch warnings and errors (Suggested-by: Saeed 
Mahameed )
- Added "Fixes:" tag (Suggested-by: Saeed Mahameed )
Changes in v2:
- Added NULL check in rose_loopback_timer() (Suggested-by: Greg KH 
)

 net/rose/rose_loopback.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
index 7b094275ea8b..6a71b6947d92 100644
--- a/net/rose/rose_loopback.c
+++ b/net/rose/rose_loopback.c
@@ -96,10 +96,12 @@ static void rose_loopback_timer(struct timer_list *unused)
}

if (frametype == ROSE_CALL_REQUEST) {
-   if ((dev = rose_dev_get(dest)) != NULL) {
+   dev = rose_dev_get(dest);
+   if (rose_loopback_neigh->dev && dev) {
if (rose_rx_call_request(skb, dev, 
rose_loopback_neigh, lci_o) == 0)
kfree_skb(skb);
} else {
+   dev_put(dev);
kfree_skb(skb);
}
} else {
--
2.29.2

Re: [Linux-kernel-mentees] [PATCH net v2] Bluetooth: Fix slab-out-of-bounds read in hci_le_direct_adv_report_evt()

[Peilin Ye]

On Mon, Nov 09, 2020 at 01:16:53PM +0100, Marcel Holtmann wrote:
> Hi Peilin,
> 
> > `num_reports` is not being properly checked. A malformed event packet with
> > a large `num_reports` number makes hci_le_direct_adv_report_evt() read out
> > of bounds. Fix it.
> > 
> > Cc: sta...@vger.kernel.org
> > Fixes: 2f010b55884e ("Bluetooth: Add support for handling LE Direct 
> > Advertising Report events")
> > Reported-and-tested-by: 
> > syzbot+24ebd650e20bd263c...@syzkaller.appspotmail.com
> > Link: https://syzkaller.appspot.com/bug?extid=24ebd650e20bd263ca01
> > Signed-off-by: Peilin Ye 
> > ---
> > Change in v2:
> >- add "Cc: stable@" tag.
> > 
> > net/bluetooth/hci_event.c | 12 +---
> > 1 file changed, 5 insertions(+), 7 deletions(-)
> > 
> > diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> > index 4b7fc430793c..aec43ae488d1 100644
> > --- a/net/bluetooth/hci_event.c
> > +++ b/net/bluetooth/hci_event.c
> > @@ -5863,21 +5863,19 @@ static void hci_le_direct_adv_report_evt(struct 
> > hci_dev *hdev,
> >  struct sk_buff *skb)
> > {
> > u8 num_reports = skb->data[0];
> > -   void *ptr = >data[1];
> > +   struct hci_ev_le_direct_adv_info *ev = (void *)>data[1];
> > 
> > -   hci_dev_lock(hdev);
> > +   if (!num_reports || skb->len < num_reports * sizeof(*ev) + 1)
> > +   return;
> > 
> > -   while (num_reports--) {
> > -   struct hci_ev_le_direct_adv_info *ev = ptr;
> > +   hci_dev_lock(hdev);
> > 
> > +   for (; num_reports; num_reports--, ev++)
> > process_adv_report(hdev, ev->evt_type, >bdaddr,
> >ev->bdaddr_type, >direct_addr,
> >ev->direct_addr_type, ev->rssi, NULL, 0,
> >false);
> > 
> > -   ptr += sizeof(*ev);
> > -   }
> > -
> > hci_dev_unlock(hdev);
> > }
> 
> patch has been applied to bluetooth-next tree.

Thank you for reviewing it,

Peilin Ye

Re: [Linux-kernel-mentees] [PATCH v3 net] rose: Fix Null pointer dereference in rose_send_frame()

[Anmol Karn]

Hello Sir,

On Tue, Nov 10, 2020 at 09:58:15AM -0800, Jakub Kicinski wrote:
> On Sun,  8 Nov 2020 00:48:35 +0530 Anmol Karn wrote:
> > +   dev = rose_dev_get(dest);
> 
> this calls dev_hold internally, you never release that reference in
> case ..neigh->dev is NULL
> 
> > +   if (rose_loopback_neigh->dev && dev) {

Ah, I missed to `dev_put()` the `dev` after checking for, if neigh->dev is NULL,
I will fix it soon and send another version.

Thank you for review.


Anmol

Re: [Linux-kernel-mentees] [PATCH v3 net] rose: Fix Null pointer dereference in rose_send_frame()

[Jakub Kicinski]

On Sun,  8 Nov 2020 00:48:35 +0530 Anmol Karn wrote:
> + dev = rose_dev_get(dest);

this calls dev_hold internally, you never release that reference in
case ..neigh->dev is NULL

> + if (rose_loopback_neigh->dev && dev) {

Re: [Linux-kernel-mentees] [PATCH net v2] Bluetooth: Fix slab-out-of-bounds read in hci_le_direct_adv_report_evt()

[Marcel Holtmann]

Hi Peilin,

> `num_reports` is not being properly checked. A malformed event packet with
> a large `num_reports` number makes hci_le_direct_adv_report_evt() read out
> of bounds. Fix it.
> 
> Cc: sta...@vger.kernel.org
> Fixes: 2f010b55884e ("Bluetooth: Add support for handling LE Direct 
> Advertising Report events")
> Reported-and-tested-by: syzbot+24ebd650e20bd263c...@syzkaller.appspotmail.com
> Link: https://syzkaller.appspot.com/bug?extid=24ebd650e20bd263ca01
> Signed-off-by: Peilin Ye 
> ---
> Change in v2:
>- add "Cc: stable@" tag.
> 
> net/bluetooth/hci_event.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
> 
> diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
> index 4b7fc430793c..aec43ae488d1 100644
> --- a/net/bluetooth/hci_event.c
> +++ b/net/bluetooth/hci_event.c
> @@ -5863,21 +5863,19 @@ static void hci_le_direct_adv_report_evt(struct 
> hci_dev *hdev,
>struct sk_buff *skb)
> {
>   u8 num_reports = skb->data[0];
> - void *ptr = >data[1];
> + struct hci_ev_le_direct_adv_info *ev = (void *)>data[1];
> 
> - hci_dev_lock(hdev);
> + if (!num_reports || skb->len < num_reports * sizeof(*ev) + 1)
> + return;
> 
> - while (num_reports--) {
> - struct hci_ev_le_direct_adv_info *ev = ptr;
> + hci_dev_lock(hdev);
> 
> + for (; num_reports; num_reports--, ev++)
>   process_adv_report(hdev, ev->evt_type, >bdaddr,
>  ev->bdaddr_type, >direct_addr,
>  ev->direct_addr_type, ev->rssi, NULL, 0,
>  false);
> 
> - ptr += sizeof(*ev);
> - }
> -
>   hci_dev_unlock(hdev);
> }

patch has been applied to bluetooth-next tree.

Regards

Marcel

[Linux-kernel-mentees] [PATCH v3 net] rose: Fix Null pointer dereference in rose_send_frame()

[Anmol Karn]

rose_send_frame() dereferences `neigh->dev` when called from
rose_transmit_clear_request(), and the first occurrence of the
`neigh` is in rose_loopback_timer() as `rose_loopback_neigh`,
and it is initialized in rose_add_loopback_neigh() as NULL.
i.e when `rose_loopback_neigh` used in rose_loopback_timer()
its `->dev` was still NULL and rose_loopback_timer() was calling
rose_rx_call_request() without checking for NULL.

- net/rose/rose_link.c
This bug seems to get triggered in this line:

rose_call = (ax25_address *)neigh->dev->dev_addr;

Fix it by adding NULL checking for `rose_loopback_neigh->dev`
in rose_loopback_timer().

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
Tested-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
Link: 
https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3
Signed-off-by: Anmol Karn 
---
Changes in v3:
- Corrected checkpatch warnings and errors (Suggested-by: Saeed 
Mahameed )
- Added "Fixes:" tag (Suggested-by: Saeed Mahameed )
Changes in v2:
- Added NULL check in rose_loopback_timer() (Suggested-by: Greg KH 
)

 net/rose/rose_loopback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
index 7b094275ea8b..2c51756ed7bf 100644
--- a/net/rose/rose_loopback.c
+++ b/net/rose/rose_loopback.c
@@ -96,7 +96,8 @@ static void rose_loopback_timer(struct timer_list *unused)
}

if (frametype == ROSE_CALL_REQUEST) {
-   if ((dev = rose_dev_get(dest)) != NULL) {
+   dev = rose_dev_get(dest);
+   if (rose_loopback_neigh->dev && dev) {
if (rose_rx_call_request(skb, dev, 
rose_loopback_neigh, lci_o) == 0)
kfree_skb(skb);
} else {
-
2.29.2

Re: [Linux-kernel-mentees] [PATCH v2] net: rose: Fix Null pointer dereference in rose_send_frame()

[Anmol karn]

Hello,

Sorry for this wrong subject(It should be v3 instead of v2),
please ignore this patch.

I will send a new one with the corrected subject.

Thanks,
Anmol

On Sun, Nov 8, 2020 at 12:27 AM Anmol Karn  wrote:
>
> rose_send_frame() dereferences `neigh->dev` when called from
> rose_transmit_clear_request(), and the first occurrence of the
> `neigh` is in rose_loopback_timer() as `rose_loopback_neigh`,
> and it is initialized in rose_add_loopback_neigh() as NULL.
> i.e when `rose_loopback_neigh` used in rose_loopback_timer()
> its `->dev` was still NULL and rose_loopback_timer() was calling
> rose_rx_call_request() without checking for NULL.
>
> - net/rose/rose_link.c
> This bug seems to get triggered in this line:
>
> rose_call = (ax25_address *)neigh->dev->dev_addr;
>
> Fix it by adding NULL checking for `rose_loopback_neigh->dev`
> in rose_loopback_timer().
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reported-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
> Tested-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
> Link: 
> https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3
> Signed-off-by: Anmol Karn 
> ---
> Changes in v3:
> - Corrected checkpatch warnings and errors (Suggested-by: Saeed 
> Mahameed )
> - Added "Fixes:" tag (Suggested-by: Saeed Mahameed )
> Changes in v2:
> - Added NULL check in rose_loopback_timer() (Suggested-by: Greg KH 
> )
>
>  net/rose/rose_loopback.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
> index 7b094275ea8b..2c51756ed7bf 100644
> --- a/net/rose/rose_loopback.c
> +++ b/net/rose/rose_loopback.c
> @@ -96,7 +96,8 @@ static void rose_loopback_timer(struct timer_list *unused)
> }
>
> if (frametype == ROSE_CALL_REQUEST) {
> -   if ((dev = rose_dev_get(dest)) != NULL) {
> +   dev = rose_dev_get(dest);
> +   if (rose_loopback_neigh->dev && dev) {
> if (rose_rx_call_request(skb, dev, 
> rose_loopback_neigh, lci_o) == 0)
> kfree_skb(skb);
> } else {
> -
> 2.29.2
>

[Linux-kernel-mentees] [PATCH v2] net: rose: Fix Null pointer dereference in rose_send_frame()

[Anmol Karn]

rose_send_frame() dereferences `neigh->dev` when called from
rose_transmit_clear_request(), and the first occurrence of the
`neigh` is in rose_loopback_timer() as `rose_loopback_neigh`,
and it is initialized in rose_add_loopback_neigh() as NULL.
i.e when `rose_loopback_neigh` used in rose_loopback_timer()
its `->dev` was still NULL and rose_loopback_timer() was calling
rose_rx_call_request() without checking for NULL.

- net/rose/rose_link.c
This bug seems to get triggered in this line:

rose_call = (ax25_address *)neigh->dev->dev_addr;

Fix it by adding NULL checking for `rose_loopback_neigh->dev`
in rose_loopback_timer().

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reported-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
Tested-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
Link: 
https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3
Signed-off-by: Anmol Karn 
---
Changes in v3:
- Corrected checkpatch warnings and errors (Suggested-by: Saeed 
Mahameed )
- Added "Fixes:" tag (Suggested-by: Saeed Mahameed )
Changes in v2:
- Added NULL check in rose_loopback_timer() (Suggested-by: Greg KH 
)

 net/rose/rose_loopback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
index 7b094275ea8b..2c51756ed7bf 100644
--- a/net/rose/rose_loopback.c
+++ b/net/rose/rose_loopback.c
@@ -96,7 +96,8 @@ static void rose_loopback_timer(struct timer_list *unused)
}

if (frametype == ROSE_CALL_REQUEST) {
-   if ((dev = rose_dev_get(dest)) != NULL) {
+   dev = rose_dev_get(dest);
+   if (rose_loopback_neigh->dev && dev) {
if (rose_rx_call_request(skb, dev, 
rose_loopback_neigh, lci_o) == 0)
kfree_skb(skb);
} else {
-
2.29.2

Re: [Linux-kernel-mentees] [PATCH v2 net] rose: Fix Null pointer dereference in rose_send_frame()

[Anmol Karn]

Hello Sir,

On Fri, Nov 06, 2020 at 01:04:27PM -0800, Saeed Mahameed wrote:
> On Thu, 2020-11-05 at 21:26 +0530, Anmol Karn wrote:
> > rose_send_frame() dereferences `neigh->dev` when called from
> > rose_transmit_clear_request(), and the first occurance of the `neigh`
> > is in rose_loopback_timer() as `rose_loopback_neigh`, and it is
> > initialized
> > in rose_add_loopback_neigh() as NULL. i.e when `rose_loopback_neigh`
> > used in 
> > rose_loopback_timer() its `->dev` was still NULL and
> > rose_loopback_timer() 
> > was calling rose_rx_call_request() without checking for NULL.
> > 
> > - net/rose/rose_link.c
> > This bug seems to get triggered in this line:
> > 
> > rose_call = (ax25_address *)neigh->dev->dev_addr;
> > 
> > Fix it by adding NULL checking for `rose_loopback_neigh->dev` in
> > rose_loopback_timer(). 
> > 
> > Reported-and-tested-by: 
> > syzbot+a1c743815982d9496...@syzkaller.appspotmail.com 
> > Link: 
> > https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3
> >  
> > Signed-off-by: Anmol Karn 
> 
> missing proper fixes tag.
> 
> > ---
> >  net/rose/rose_loopback.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
> > index 7b094275ea8b..cd7774cb1d07 100644
> > --- a/net/rose/rose_loopback.c
> > +++ b/net/rose/rose_loopback.c
> > @@ -96,7 +96,7 @@ static void rose_loopback_timer(struct timer_list
> > *unused)
> > }
> >  
> > if (frametype == ROSE_CALL_REQUEST) {
> > -   if ((dev = rose_dev_get(dest)) != NULL) {
> > +   if (rose_loopback_neigh->dev && (dev =
> > rose_dev_get(dest)) != NULL) {
> > if (rose_rx_call_request(skb, dev,
> > rose_loopback_neigh, lci_o) == 0)
> > kfree_skb(skb);
> > } else {
> 
> check patch is not happy:
> 
> WARNING:TYPO_SPELLING: 'occurance' may be misspelled - perhaps
> 'occurrence'?
> #7: 
> rose_transmit_clear_request(), and the first occurance of the `neigh`
> 
> ERROR:ASSIGN_IN_IF: do not use assignment in if condition
> #36: FILE: net/rose/rose_loopback.c:99:
> +   if (rose_loopback_neigh->dev && (dev =
> rose_dev_get(dest)) != NULL) {
> 
> total: 1 errors, 1 warnings, 0 checks, 8 lines checked
> 
> 

Thank you for your review will rectify these and send another version.

Thanks,
Anmol

Re: [Linux-kernel-mentees] [PATCH v2 net] rose: Fix Null pointer dereference in rose_send_frame()

[Saeed Mahameed]

On Thu, 2020-11-05 at 21:26 +0530, Anmol Karn wrote:
> rose_send_frame() dereferences `neigh->dev` when called from
> rose_transmit_clear_request(), and the first occurance of the `neigh`
> is in rose_loopback_timer() as `rose_loopback_neigh`, and it is
> initialized
> in rose_add_loopback_neigh() as NULL. i.e when `rose_loopback_neigh`
> used in 
> rose_loopback_timer() its `->dev` was still NULL and
> rose_loopback_timer() 
> was calling rose_rx_call_request() without checking for NULL.
> 
> - net/rose/rose_link.c
> This bug seems to get triggered in this line:
> 
> rose_call = (ax25_address *)neigh->dev->dev_addr;
> 
> Fix it by adding NULL checking for `rose_loopback_neigh->dev` in
> rose_loopback_timer(). 
> 
> Reported-and-tested-by: 
> syzbot+a1c743815982d9496...@syzkaller.appspotmail.com 
> Link: 
> https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3
>  
> Signed-off-by: Anmol Karn 

missing proper fixes tag.

> ---
>  net/rose/rose_loopback.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
> index 7b094275ea8b..cd7774cb1d07 100644
> --- a/net/rose/rose_loopback.c
> +++ b/net/rose/rose_loopback.c
> @@ -96,7 +96,7 @@ static void rose_loopback_timer(struct timer_list
> *unused)
>   }
>  
>   if (frametype == ROSE_CALL_REQUEST) {
> - if ((dev = rose_dev_get(dest)) != NULL) {
> + if (rose_loopback_neigh->dev && (dev =
> rose_dev_get(dest)) != NULL) {
>   if (rose_rx_call_request(skb, dev,
> rose_loopback_neigh, lci_o) == 0)
>   kfree_skb(skb);
>   } else {

check patch is not happy:

WARNING:TYPO_SPELLING: 'occurance' may be misspelled - perhaps
'occurrence'?
#7: 
rose_transmit_clear_request(), and the first occurance of the `neigh`

ERROR:ASSIGN_IN_IF: do not use assignment in if condition
#36: FILE: net/rose/rose_loopback.c:99:
+   if (rose_loopback_neigh->dev && (dev =
rose_dev_get(dest)) != NULL) {

total: 1 errors, 1 warnings, 0 checks, 8 lines checked

[Linux-kernel-mentees] [PATCH v2 net] rose: Fix Null pointer dereference in rose_send_frame()

[Anmol Karn]

rose_send_frame() dereferences `neigh->dev` when called from
rose_transmit_clear_request(), and the first occurance of the `neigh`
is in rose_loopback_timer() as `rose_loopback_neigh`, and it is initialized
in rose_add_loopback_neigh() as NULL. i.e when `rose_loopback_neigh` used in 
rose_loopback_timer() its `->dev` was still NULL and rose_loopback_timer() 
was calling rose_rx_call_request() without checking for NULL.

- net/rose/rose_link.c
This bug seems to get triggered in this line:

rose_call = (ax25_address *)neigh->dev->dev_addr;

Fix it by adding NULL checking for `rose_loopback_neigh->dev` in 
rose_loopback_timer(). 

Reported-and-tested-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com 
Link: 
https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3 
Signed-off-by: Anmol Karn 
---
 net/rose/rose_loopback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
index 7b094275ea8b..cd7774cb1d07 100644
--- a/net/rose/rose_loopback.c
+++ b/net/rose/rose_loopback.c
@@ -96,7 +96,7 @@ static void rose_loopback_timer(struct timer_list *unused)
}
 
if (frametype == ROSE_CALL_REQUEST) {
-   if ((dev = rose_dev_get(dest)) != NULL) {
+   if (rose_loopback_neigh->dev && (dev = 
rose_dev_get(dest)) != NULL) {
if (rose_rx_call_request(skb, dev, 
rose_loopback_neigh, lci_o) == 0)
kfree_skb(skb);
} else {
-- 
2.29.2

Linux Kernel Code of Conduct Committee: October 2020 report

[Greg KH]

Despite our previously hoped-for timely release of these reports that
were mentioned last time:
https://lore.kernel.org/lkml/20200103105614.gc1047...@kroah.com/
that hasn't happened, so here's the report for the first 10 months of
2020.  I will work to do better on this in the future, my apologies.

Linux Kernel Code of Conduct Committee: October 2020

In the period of January 1, 2020 through October 31, 2020 the Committee
received the following reports:
  - Unacceptable behavior or comments in email: 1
  - Unacceptable comments in github repo by non-community members: 1
  - Unacceptable comments toward a company: 1

The result of the investigation:
  - Education and coaching: 1
  - Locking of github repo for any comments: 1
  - Clarification that the Code of Conduct covers conduct related to
individual developers only: 1

We would like to thank the Linux kernel community members who have
supported the adoption of the Code of Conduct and who continue to uphold
the professional standards of our community.  If you have questions
about this report, please write to .



The website at https://www.kernel.org/code-of-conduct.html has a list of
this, and other past Code Of Conduct Committee reports.

thanks,

greg k-h

Re: [Linux-kernel-mentees] [PATCH] net: rose: Fix Null pointer dereference in rose_send_frame()

[Anmol Karn]

On Sun, Nov 01, 2020 at 12:02:58PM +0100, Greg KH wrote:
> On Fri, Oct 30, 2020 at 04:24:13PM +0530, Anmol Karn wrote:
> > On Thu, Oct 15, 2020 at 05:50:51PM +0200, Greg KH wrote:
> > > On Thu, Oct 15, 2020 at 07:40:12PM +0530, Anmol Karn wrote:
> > > > On Thu, Oct 15, 2020 at 07:12:25AM +0200, Greg KH wrote:
> > > > > On Thu, Oct 15, 2020 at 05:47:12AM +0530, Anmol Karn wrote:
> > > > > > In rose_send_frame(), when comparing two ax.25 addresses, it 
> > > > > > assigns rose_call to 
> > > > > > either global ROSE callsign or default port, but when the former 
> > > > > > block triggers and 
> > > > > > rose_call is assigned by (ax25_address *)neigh->dev->dev_addr, a 
> > > > > > NULL pointer is 
> > > > > > dereferenced by 'neigh' when dereferencing 'dev'.
> > > > > > 
> > > > > > - net/rose/rose_link.c
> > > > > > This bug seems to get triggered in this line:
> > > > > > 
> > > > > > rose_call = (ax25_address *)neigh->dev->dev_addr;
> > > > > > 
> > > > > > Prevent it by checking NULL condition for neigh->dev before 
> > > > > > comparing addressed for 
> > > > > > rose_call initialization.
> > > > > > 
> > > > > > Reported-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com 
> > > > > > Link: 
> > > > > > https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3
> > > > > >  
> > > > > > Signed-off-by: Anmol Karn 
> > > > > > ---
> > > > > > I am bit sceptical about the error return code, please suggest if 
> > > > > > anything else is 
> > > > > > appropriate in place of '-ENODEV'.
> > > > > > 
> > > > > >  net/rose/rose_link.c | 3 +++
> > > > > >  1 file changed, 3 insertions(+)
> > > > > > 
> > > > > > diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c
> > > > > > index f6102e6f5161..92ea6a31d575 100644
> > > > > > --- a/net/rose/rose_link.c
> > > > > > +++ b/net/rose/rose_link.c
> > > > > > @@ -97,6 +97,9 @@ static int rose_send_frame(struct sk_buff *skb, 
> > > > > > struct rose_neigh *neigh)
> > > > > > ax25_address *rose_call;
> > > > > > ax25_cb *ax25s;
> > > > > >  
> > > > > > +   if (!neigh->dev)
> > > > > > +   return -ENODEV;
> > > > > 
> > > > > How can ->dev not be set at this point in time?  Shouldn't that be
> > > > > fixed, because it could change right after you check this, right?
> > > > > 
> > > > > thanks,
> > > > > 
> > > > > greg k-h
> > > > 
> > > > Hello Sir,
> > > > 
> > > > Thanks for the review,
> > > > After following the call trace i thought, if neigh->dev is NULL it 
> > > > should
> > > > be checked, but I will figure out what is going on with the crash 
> > > > reproducer,
> > > > and I think rose_loopback_timer() is the place where problem started. 
> > > > 
> > > > Also, I have created a diff for checking neigh->dev before assigning 
> > > > ROSE callsign
> > > > , please give your suggestions on this.
> > > > 
> > > > 
> > > > diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c
> > > > index f6102e6f5161..2ddd5e559442 100644
> > > > --- a/net/rose/rose_link.c
> > > > +++ b/net/rose/rose_link.c
> > > > @@ -97,10 +97,14 @@ static int rose_send_frame(struct sk_buff *skb, 
> > > > struct rose_neigh *neigh)
> > > > ax25_address *rose_call;
> > > > ax25_cb *ax25s;
> > > >  
> > > > -   if (ax25cmp(_callsign, _ax25_address) == 0)
> > > > -   rose_call = (ax25_address *)neigh->dev->dev_addr;
> > > > -   else
> > > > -   rose_call = _callsign;
> > > > +   if (neigh->dev) {
> > > > +   if (ax25cmp(_callsign, _ax25_address) == 0)
> > > > +   rose_call = (ax25_address 
> > > > *)neigh->dev->dev_addr;
> > > > +   else
> > > > +   rose_call = _callsign;
> > > > +   } else {
> > > > +   return -ENODEV;
> > > > +   }
> > > 
> > > The point I am trying to make is that if someone else is setting ->dev
> > > to NULL in some other thread/context/whatever, while this is running,
> > > checking for it like this will not work.
> > > 
> > > What is the lifetime rules of that pointer?  Who initializes it, and who
> > > sets it to NULL.  Figure that out first please to determine how to check
> > > for this properly.
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > 
> > Hello All,
> > 
> > I investigated further on this,
> > 
> > Here is some things i noticed:
> > 
> > When I followed the call trace,
> > 
> > [ 84.241331][ C3] Call Trace:
> > [ 84.241331][ C3] rose_transmit_clear_request 
> > ($SOURCE/net/rose/rose_link.c:255)
> > [ 84.241331][ C3] ? lockdep_hardirqs_on 
> > ($SOURCE/kernel/locking/lockdep.c:4161)
> > [ 84.241331][ C3] rose_rx_call_request ($SOURCE/net/rose/af_rose.c:999)
> > [ 84.241331][ C3] ? rose_release ($SOURCE/net/rose/af_rose.c:970)
> > [ 84.241331][ C3] rose_loopback_timer ($SOURCE/net/rose/rose_loopback.c:100)
> > [ 84.241331][ C3] ? rose_transmit_link ($SOURCE/net/rose/rose_loopback.c:60)
> > 
> > in the rose_send_frame() it dereferenced `neigh->dev` when called from 
> > 

Re: [Linux-kernel-mentees] [PATCH] net: rose: Fix Null pointer dereference in rose_send_frame()

[Greg KH]

On Fri, Oct 30, 2020 at 04:24:13PM +0530, Anmol Karn wrote:
> On Thu, Oct 15, 2020 at 05:50:51PM +0200, Greg KH wrote:
> > On Thu, Oct 15, 2020 at 07:40:12PM +0530, Anmol Karn wrote:
> > > On Thu, Oct 15, 2020 at 07:12:25AM +0200, Greg KH wrote:
> > > > On Thu, Oct 15, 2020 at 05:47:12AM +0530, Anmol Karn wrote:
> > > > > In rose_send_frame(), when comparing two ax.25 addresses, it assigns 
> > > > > rose_call to 
> > > > > either global ROSE callsign or default port, but when the former 
> > > > > block triggers and 
> > > > > rose_call is assigned by (ax25_address *)neigh->dev->dev_addr, a NULL 
> > > > > pointer is 
> > > > > dereferenced by 'neigh' when dereferencing 'dev'.
> > > > > 
> > > > > - net/rose/rose_link.c
> > > > > This bug seems to get triggered in this line:
> > > > > 
> > > > > rose_call = (ax25_address *)neigh->dev->dev_addr;
> > > > > 
> > > > > Prevent it by checking NULL condition for neigh->dev before comparing 
> > > > > addressed for 
> > > > > rose_call initialization.
> > > > > 
> > > > > Reported-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com 
> > > > > Link: 
> > > > > https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3
> > > > >  
> > > > > Signed-off-by: Anmol Karn 
> > > > > ---
> > > > > I am bit sceptical about the error return code, please suggest if 
> > > > > anything else is 
> > > > > appropriate in place of '-ENODEV'.
> > > > > 
> > > > >  net/rose/rose_link.c | 3 +++
> > > > >  1 file changed, 3 insertions(+)
> > > > > 
> > > > > diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c
> > > > > index f6102e6f5161..92ea6a31d575 100644
> > > > > --- a/net/rose/rose_link.c
> > > > > +++ b/net/rose/rose_link.c
> > > > > @@ -97,6 +97,9 @@ static int rose_send_frame(struct sk_buff *skb, 
> > > > > struct rose_neigh *neigh)
> > > > >   ax25_address *rose_call;
> > > > >   ax25_cb *ax25s;
> > > > >  
> > > > > + if (!neigh->dev)
> > > > > + return -ENODEV;
> > > > 
> > > > How can ->dev not be set at this point in time?  Shouldn't that be
> > > > fixed, because it could change right after you check this, right?
> > > > 
> > > > thanks,
> > > > 
> > > > greg k-h
> > > 
> > > Hello Sir,
> > > 
> > > Thanks for the review,
> > > After following the call trace i thought, if neigh->dev is NULL it should
> > > be checked, but I will figure out what is going on with the crash 
> > > reproducer,
> > > and I think rose_loopback_timer() is the place where problem started. 
> > > 
> > > Also, I have created a diff for checking neigh->dev before assigning ROSE 
> > > callsign
> > > , please give your suggestions on this.
> > > 
> > > 
> > > diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c
> > > index f6102e6f5161..2ddd5e559442 100644
> > > --- a/net/rose/rose_link.c
> > > +++ b/net/rose/rose_link.c
> > > @@ -97,10 +97,14 @@ static int rose_send_frame(struct sk_buff *skb, 
> > > struct rose_neigh *neigh)
> > > ax25_address *rose_call;
> > > ax25_cb *ax25s;
> > >  
> > > -   if (ax25cmp(_callsign, _ax25_address) == 0)
> > > -   rose_call = (ax25_address *)neigh->dev->dev_addr;
> > > -   else
> > > -   rose_call = _callsign;
> > > +   if (neigh->dev) {
> > > +   if (ax25cmp(_callsign, _ax25_address) == 0)
> > > +   rose_call = (ax25_address *)neigh->dev->dev_addr;
> > > +   else
> > > +   rose_call = _callsign;
> > > +   } else {
> > > +   return -ENODEV;
> > > +   }
> > 
> > The point I am trying to make is that if someone else is setting ->dev
> > to NULL in some other thread/context/whatever, while this is running,
> > checking for it like this will not work.
> > 
> > What is the lifetime rules of that pointer?  Who initializes it, and who
> > sets it to NULL.  Figure that out first please to determine how to check
> > for this properly.
> > 
> > thanks,
> > 
> > greg k-h
> 
> Hello All,
> 
> I investigated further on this,
> 
> Here is some things i noticed:
> 
> When I followed the call trace,
> 
> [ 84.241331][ C3] Call Trace:
> [ 84.241331][ C3] rose_transmit_clear_request 
> ($SOURCE/net/rose/rose_link.c:255)
> [ 84.241331][ C3] ? lockdep_hardirqs_on 
> ($SOURCE/kernel/locking/lockdep.c:4161)
> [ 84.241331][ C3] rose_rx_call_request ($SOURCE/net/rose/af_rose.c:999)
> [ 84.241331][ C3] ? rose_release ($SOURCE/net/rose/af_rose.c:970)
> [ 84.241331][ C3] rose_loopback_timer ($SOURCE/net/rose/rose_loopback.c:100)
> [ 84.241331][ C3] ? rose_transmit_link ($SOURCE/net/rose/rose_loopback.c:60)
> 
> in the rose_send_frame() it dereferenced `neigh->dev` when called from 
> rose_transmit_clear_request(), and the first occurance of the `neigh`
> is in rose_loopback_timer() as `rose_loopback_neigh`, and it is initialized 
> in rose_add_loopback_neighh() as NULL.
> 
> - net/rose/rose_route.c:381
> 
> void rose_add_loopback_neigh(void)
> {
>   struct rose_neigh *sn;
> 
>   

Has the linux-kernel already implemented the functions in apollo-kernel?

[Hongyi Zhao]

Hi,

The apollo-kernel (https://github.com/ApolloAuto/apollo-kernel) is a
patched Linux Kernel based on official Linux Kernel 4.4.32 with some
modifications on the kernel level, especially for the scenario
necessary to run the Apollo (https://github.com/ApolloAuto/apollo)
open autonomous driving platform software stack.

According to the official description as shown
<https://github.com/ApolloAuto/apollo-kernel#what-is-the-difference>,
the major difference from the original Linux kernel is as follows:


- Realtime patch (https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO)
- Latest e1000e intel ethernet driver
- Bugfix for Nvidia driver under realtime patch
- Double free in the inet_csk_clone_lock function patch
(https://bugzilla.redhat.com/show_bug.cgi?id=1450972)
- Other cve security patches


However, considering that Linux Kernel 4.4.32 is a fairly old version,
so I want to know whether the modifications/fixes applied/added have
been already available in the current Linux kernel.

Any hints will be highly appreciated.

Regards,
-- 
Assoc. Prof. Hongyi Zhao 
Theory and Simulation of Materials, Xingtai Polytechnic College
NO. 552 North Gangtie Road, Xingtai, China

Re: Queries on ARM SDEI Linux kernel code

[James Morse]

Hi Neeraj,

On 21/10/2020 18:31, Neeraj Upadhyay wrote:
> On 10/16/2020 9:57 PM, James Morse wrote:
>> On 15/10/2020 07:07, Neeraj Upadhyay wrote:
>>> 1. Looks like interrupt bind interface (SDEI_1_0_FN_SDEI_INTERRUPT_BIND) is 
>>> not available
>>> for clients to use; can you please share information on
>>> why it is not provided?
>>
>> There is no compelling use-case for it, and its very complex to support as 
>> the driver can
>> no longer hide things like hibernate.
>>
>> Last time I looked, it looked like the SDEI driver would need to ask the 
>> irqchip to
>> prevent modification while firmware re-configures the irq. I couldn't work 
>> out how this
>> would work if the irq is in-progress on another CPU.

> Got it. I will think in this direction, on how to achieve this.

I'm really not keen on supporting it! Its basically unusable.


>> The reasons to use bound-interrupts can equally be supported with an event 
>> provided by
>> firmware.
>>
>>
> Ok, I will explore in that direction.

Great!


[...]

>> Ideally the driver would register the event, and provide a call_on_cpu() 
>> helper to trigger
>> it. This should fit in with however the GIC's PMR based NMI does its PPI 
>> based
>> crash/stacktrace call so that the caller doesn't need to know if its back by 
>> IRQ, pNMI or
>> SDEI.

> Ok; I will explore how PMR based NMIs work; I thought it was SGI based. But 
> will recheck.

This is where the recent work has been. (One of) Julien's cover-letter's 
describes it as
supporting PPI and SPI: https://lwn.net/Articles/755906/


>>> 3. Can kernel panic() be triggered from sdei event handler?
>>
>> Yes,
>>
>>
>>> Is it a safe operation?
>>
>> panic() wipes out the machine... did you expect it to keep running?
> 
> I wanted to check the case where panic triggers kexec/kdump path into capture 
> kernel.
> 
>> What does safe mean here?

> I think I didn't put it correctly; I meant what possible scenarios can 
> happen in this case and you explained one below, thanks!

Ah, kdump. You will certainly get into the kdump kernel, but I think the SDEI 
reset calls
will fail as there is still an event in progress, so the kernel will leave it 
masked to
prevent any new events being taken.
This shouldn't affect kdumps work of dumping memory, and calling reset.


>> You should probably call nmi_panic() if there is the risk that the event 
>> occurred during
>> panic() on the same CPU, as it would otherwise just block.
>>
>>
>>> The spec says, synchronous exceptions should not be triggered; I think panic
>>> won't do it; but anything which triggers a WARN
>>> or other sync exception in that path can cause undefined behavior. Can you 
>>> share your
>>> thoughts on this?
>>
>> What do you mean by undefined behaviour?

> I was thinking, if SDEI event preempts EL1, at the point, where EL1 has just 
> entered an
> exception, and hasn't captured the registers like spsr_el1, elr_el1 and other 
> registers,
> what will be the behavior?

Exceptions to/from EL3 don't affect them, so those registers keep their value 
until the
next exception taken by EL1 (which overwrites them), or ERET from EL1 (which 
makes them
UNKNOWN). Kdump may change exception level on nVHE systems to do a reset.

If you need them for kdump, they should be saved in the crash handler... they 
aren't
needed in the general case as we learn what those values were by unwinding the 
stack,
which is also true for SDEI. (it gets the original PC from firmware to build a 
stack frame)

[...]

>>> "The handler code should not enable asynchronous exceptions by clearing any 
>>> of the
>>> PSTATE.DAIF bits, and should not cause synchronous exceptions to the client 
>>> Exception
>>> level."
>>
>>
>> What are you using this thing for?

> Usecase is, a watchdog SPI interrupt, which we want to bound to a SDEI event. 
> Below is the
> flow:
> 
> wdog expiry -> SDEI event -> HLOS panic -> trigger kexec/kdump

Having a common interface to this would be a good thing, that way firmware can 
hide how
its implemented.


Thanks,

James

Re: [Linux-kernel-mentees] [PATCH] net: rose: Fix Null pointer dereference in rose_send_frame()

[Anmol Karn]

On Thu, Oct 15, 2020 at 05:50:51PM +0200, Greg KH wrote:
> On Thu, Oct 15, 2020 at 07:40:12PM +0530, Anmol Karn wrote:
> > On Thu, Oct 15, 2020 at 07:12:25AM +0200, Greg KH wrote:
> > > On Thu, Oct 15, 2020 at 05:47:12AM +0530, Anmol Karn wrote:
> > > > In rose_send_frame(), when comparing two ax.25 addresses, it assigns 
> > > > rose_call to 
> > > > either global ROSE callsign or default port, but when the former block 
> > > > triggers and 
> > > > rose_call is assigned by (ax25_address *)neigh->dev->dev_addr, a NULL 
> > > > pointer is 
> > > > dereferenced by 'neigh' when dereferencing 'dev'.
> > > > 
> > > > - net/rose/rose_link.c
> > > > This bug seems to get triggered in this line:
> > > > 
> > > > rose_call = (ax25_address *)neigh->dev->dev_addr;
> > > > 
> > > > Prevent it by checking NULL condition for neigh->dev before comparing 
> > > > addressed for 
> > > > rose_call initialization.
> > > > 
> > > > Reported-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com 
> > > > Link: 
> > > > https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3
> > > >  
> > > > Signed-off-by: Anmol Karn 
> > > > ---
> > > > I am bit sceptical about the error return code, please suggest if 
> > > > anything else is 
> > > > appropriate in place of '-ENODEV'.
> > > > 
> > > >  net/rose/rose_link.c | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > > 
> > > > diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c
> > > > index f6102e6f5161..92ea6a31d575 100644
> > > > --- a/net/rose/rose_link.c
> > > > +++ b/net/rose/rose_link.c
> > > > @@ -97,6 +97,9 @@ static int rose_send_frame(struct sk_buff *skb, 
> > > > struct rose_neigh *neigh)
> > > > ax25_address *rose_call;
> > > > ax25_cb *ax25s;
> > > >  
> > > > +   if (!neigh->dev)
> > > > +   return -ENODEV;
> > > 
> > > How can ->dev not be set at this point in time?  Shouldn't that be
> > > fixed, because it could change right after you check this, right?
> > > 
> > > thanks,
> > > 
> > > greg k-h
> > 
> > Hello Sir,
> > 
> > Thanks for the review,
> > After following the call trace i thought, if neigh->dev is NULL it should
> > be checked, but I will figure out what is going on with the crash 
> > reproducer,
> > and I think rose_loopback_timer() is the place where problem started. 
> > 
> > Also, I have created a diff for checking neigh->dev before assigning ROSE 
> > callsign
> > , please give your suggestions on this.
> > 
> > 
> > diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c
> > index f6102e6f5161..2ddd5e559442 100644
> > --- a/net/rose/rose_link.c
> > +++ b/net/rose/rose_link.c
> > @@ -97,10 +97,14 @@ static int rose_send_frame(struct sk_buff *skb, struct 
> > rose_neigh *neigh)
> > ax25_address *rose_call;
> > ax25_cb *ax25s;
> >  
> > -   if (ax25cmp(_callsign, _ax25_address) == 0)
> > -   rose_call = (ax25_address *)neigh->dev->dev_addr;
> > -   else
> > -   rose_call = _callsign;
> > +   if (neigh->dev) {
> > +   if (ax25cmp(_callsign, _ax25_address) == 0)
> > +   rose_call = (ax25_address *)neigh->dev->dev_addr;
> > +   else
> > +   rose_call = _callsign;
> > +   } else {
> > +   return -ENODEV;
> > +   }
> 
> The point I am trying to make is that if someone else is setting ->dev
> to NULL in some other thread/context/whatever, while this is running,
> checking for it like this will not work.
> 
> What is the lifetime rules of that pointer?  Who initializes it, and who
> sets it to NULL.  Figure that out first please to determine how to check
> for this properly.
> 
> thanks,
> 
> greg k-h

Hello All,

I investigated further on this,

Here is some things i noticed:

When I followed the call trace,

[ 84.241331][ C3] Call Trace:
[ 84.241331][ C3] rose_transmit_clear_request ($SOURCE/net/rose/rose_link.c:255)
[ 84.241331][ C3] ? lockdep_hardirqs_on ($SOURCE/kernel/locking/lockdep.c:4161)
[ 84.241331][ C3] rose_rx_call_request ($SOURCE/net/rose/af_rose.c:999)
[ 84.241331][ C3] ? rose_release ($SOURCE/net/rose/af_rose.c:970)
[ 84.241331][ C3] rose_loopback_timer ($SOURCE/net/rose/rose_loopback.c:100)
[ 84.241331][ C3] ? rose_transmit_link ($SOURCE/net/rose/rose_loopback.c:60)

in the rose_send_frame() it dereferenced `neigh->dev` when called from 
rose_transmit_clear_request(), and the first occurance of the `neigh`
is in rose_loopback_timer() as `rose_loopback_neigh`, and it is initialized 
in rose_add_loopback_neighh() as NULL.

- net/rose/rose_route.c:381

void rose_add_loopback_neigh(void)
{
struct rose_neigh *sn;

rose_loopback_neigh = kmalloc(sizeof(struct rose_neigh), GFP_KERNEL);
if (!rose_loopback_neigh)
return;
sn = rose_loopback_neigh;

sn->callsign  = null_ax25_address;
sn->digipeat  = NULL;
sn->ax25  = NULL;
sn->dev   = NULL;

price offer for linux-kernel@vger.kernel.org

[iraqofficgenerationchemicals]

Hello Dear,

Any possibilities to get price offer for your product at
earliest? Customer is waiting.

Please confirm me below with your price offer.

*  Delivery time after payment of requested Order? [I have to
confirm delivery time to our clients]

*  Each item approximate weight? [This is important to calculate
freight cost]

Your early reply is highly appreciated.


Thanks in advance.
Regards
Mr. Kasim Fadhil
Import manager


This e-mail may contain confidential and/or privileged 
information. If you are not the intended recipient (or have 
received this e-mail in error) please notify the sender 
immediately and destroy this e-mail. Any unauthorised copying, 
disclosure or distribution of the material in this e-mail is 
strictly forbidden

Este e-mail pode conter informações confidenciais e / ou 
privilegiadas. Se você não for o destinatário pretendido (ou 
tiver recebido este e-mail por engano), notifique o remetente 
imediatamente e destrua este e-mail. Qualquer cópia, divulgação 
ou distribuição não autorizada do material neste e-mail é 
estritamente proibida.

 Before printing think about your responsibility for the 
ENVIRONMENT

Re: Queries on ARM SDEI Linux kernel code

[Neeraj Upadhyay]

Hi James,

Sorry for late reply. Thanks for your comments!

On 10/16/2020 9:57 PM, James Morse wrote:

Hi Neeraj,

On 15/10/2020 07:07, Neeraj Upadhyay wrote:

1. Looks like interrupt bind interface (SDEI_1_0_FN_SDEI_INTERRUPT_BIND) is not 
available
for clients to use; can you please share information on
why it is not provided?


There is no compelling use-case for it, and its very complex to support as the 
driver can
no longer hide things like hibernate.

Last time I looked, it looked like the SDEI driver would need to ask the 
irqchip to
prevent modification while firmware re-configures the irq. I couldn't work out 
how this
would work if the irq is in-progress on another CPU.



Got it. I will think in this direction, on how to achieve this.


The reasons to use bound-interrupts can equally be supported with an event 
provided by
firmware.



Ok, I will explore in that direction.


While trying to dig information on this, I saw  that [1] says:
   Now the hotplug callbacks save  nothing, and restore the OS-view of 
registered/enabled.
This makes bound-interrupts harder to work with.



Based on this comment, the changes from v4 [2], which I could understand is, 
cpu down path
does not save the current event enable status, and we rely on the enable status
`event->reenable', which is set, when register/unregister, enable/disable calls 
are made;
this enable status is used during cpu up path, to decide whether to reenable 
the interrupt.



Does this make, bound-interrupts harder to work with? how? Can you please 
explain? Or
above save/restore is not the reason and you meant something else?


If you bind a level-triggered interrupt, how does firmware know how to clear 
the interrupt
from whatever is generating it?

What happens if the OS can't do this either, as it needs to allocate memory, or 
take a
lock, which it can't do in nmi context?

Ok, makes sense.
The people that wrote the SDEI spec's answer to this was that the handler can 
disable the
event from inside the handler... and firmware will do, something, to stop the 
interrupt
screaming.

So now an event can become disabled anytime its registered, which makes it more
complicated to save/restore.



Also, does shared bound interrupts


Shared-interrupts as an NMI made me jump. But I think you mean a bound 
interrupt as a
shared event. i.e. and SPI not a PPI.



Sorry I should have worded properly; yes I meant SPI as shared event.


also have the same problem, as save/restore behavior
was only for private events?


See above, the problem is the event disabling itself.


This makes sense now.


Additionally those changes to unregister the private-event mean the code can't 
tell the
difference between cpuhp and hibernate... only hibernate additionally loses the 
state in
firmware.



Got it!

2. SDEI_EVENT_SIGNAL api is not provided? What is the reason for it? Its 
handling has the
same problems, which are there for bound interrupts?


Its not supported as no-one showed up with a use-case.
While firmware is expected to back it with a PPI, its doesn't have the same 
problems as
bound-interrupts as its not an interrupt the OS ever knows about.



Also, if it is provided, clients need to register event 0 ? Vendor events or 
other event
nums are not supported, as per spec.


Ideally the driver would register the event, and provide a call_on_cpu() helper 
to trigger
it. This should fit in with however the GIC's PMR based NMI does its PPI based
crash/stacktrace call so that the caller doesn't need to know if its back by 
IRQ, pNMI or
SDEI.


Ok; I will explore how PMR based NMIs work; I thought it was SGI based. 
But will recheck.



3. Can kernel panic() be triggered from sdei event handler?


Yes,



Is it a safe operation?


panic() wipes out the machine... did you expect it to keep running?


I wanted to check the case where panic triggers kexec/kdump path into 
capture kernel.



What does safe mean here?
I think I didn't put it correctly; I meant what possible scenarios can 

happen in this case and you explained one below, thanks!


You should probably call nmi_panic() if there is the risk that the event 
occurred during
panic() on the same CPU, as it would otherwise just block.



The spec says, synchronous exceptions should not be triggered; I think panic
won't do it; but anything which triggers a WARN
or other sync exception in that path can cause undefined behavior. Can you 
share your
thoughts on this?


What do you mean by undefined behaviour?

I was thinking, if SDEI event preempts EL1, at the point, where EL1 has 
just entered an exception, and hasn't captured the registers like 
spsr_el1, elr_el1 and other registers, what will be the behavior?



SDEI was originally to report external abort to the OS in regions where the OS 
can't take
an exception because the exception-registers are live, just after and exception 
and just
before eret.

If you take another exception from the NMI handler, chances are you're going to 
go back
round the 

Re: Dts for eth network based on marvell's mv88e6390x crashes Xilinx's linux-kernel v5.4

[Andrew Lunn]

On Mon, Oct 19, 2020 at 05:05:08PM +0300, michael alayev wrote:
> Hello Andrew,
> 
> 
> > Please fix your email client and
> 
> 
> > post the DT file for review. I will
> 
>     > then point out some of the errors.
> 
> 
> 
>  {
>     status = "okay";
>     phy-mode = "rgmii-id";
>     phy-handle = <>;

The diagram you showed had gem0 connected directly to the switch. So
this phy-handle is wrong. Or the diagram is wrong.

> 
>     mdio {
>         #address-cells = <1>;
>         #size-cells = <0>;
> 
>         phy0: ethernet-phy@0 {
>             compatible = "marvell";
>             reg = <0>;
>             device_type = "ethernet-phy";
>             fixed-link {
>                 speed = <1000>;
>                 full-duplex;
>             };
>         };
> 
>         debug_phy: ethernet-phy@1 {
>         compatible = "marvell";
>         reg = <1>;
>         device_type = "ethernet-phy";
>         label = "debug-phy";
>     };

indentation is all wrong here.

>     switch0: switch@2 {
>         compatible = "marvell,mv88e6190";
>         #address-cells = <1>;
>         #size-cells = <0>;
>         reg = <2>;
> 
>         dsa,member = <0 0>;
> 
>         ports {
>             #address-cells = <1>;
>             #size-cells = <0>;
> 
>             switch0phy1: port@0 {
>                 reg = <0>;
>                 label = "uid208-cpu";
>                 ethernet = <>;
>                 phy-mode = "rgmii-id";

You have gem0 using gphy-mode = "rgmii-id" as well. Both doing delays
will not work. You should drop the one in gem0.

>                 fixed-link {
>                     speed = <1000>;
>                     full-duplex;
>                 };
>             };
> 
> 
>             port@1 {
>                 reg = <1>;
>                 label = "uid201-1A";
>             };
> 
>             port@2 {
>                 reg = <2>;
>                 label = "uid202-2A-p9-1A";
>                 phy-mode = "1000base-x";
>                 fixed-link {
>                     speed = <1000>;
>                     full-duplex;
>                 };

Why both 1000base-x and fixed link? Do you have an SFP connected? If
so, describe the SFP in DT.

>             };
> 
>             switch0port10: port@10 {
>                 reg = <10>;
>                 label = "dsa";
>                 link = <>;
>                 phy-mode = "1000base-x";
>                 fixed-link {
>                     speed = <1000>;
>                     full-duplex;
>                 };
>             };

This is a 6390X right? Why limit it to 1000base-X when it could be
doing 10G?

  Andrew