- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] scsi: core: Fix unremoved procfs host directory regression
by Li Lingfeng 07 May '24

07 May '24

From: "Guilherme G. Piccoli" <gpiccoli(a)igalia.com> stable inclusion from stable-v5.10.215 commit 5c2386ba80e779a92ec3bb64ccadbedd88f779b1 category: bugfix bugzilla: 189877 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit f23a4d6e07570826fe95023ca1aa96a011fa9f84 upstream. Commit fc663711b944 ("scsi: core: Remove the /proc/scsi/${proc_name} directory earlier") fixed a bug related to modules loading/unloading, by adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led to a potential duplicate call to the hostdir_rm() routine, since it's also called from scsi_host_dev_release(). That triggered a regression report, which was then fixed by commit be03df3d4bfe ("scsi: core: Fix a procfs host directory removal regression"). The fix just dropped the hostdir_rm() call from dev_release(). But it happens that this proc directory is created on scsi_host_alloc(), and that function "pairs" with scsi_host_dev_release(), while scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the reason for removing the proc directory on dev_release() was meant to cover cases in which a SCSI host structure was allocated, but the call to scsi_add_host() didn't happen. And that pattern happens to exist in some error paths, for example. Syzkaller causes that by using USB raw gadget device, error'ing on usb-storage driver, at usb_stor_probe2(). By checking that path, we can see that the BadDevice label leads to a scsi_host_put() after a SCSI host allocation, but there's no call to scsi_add_host() in such path. That leads to messages like this in dmesg (and a leak of the SCSI host proc structure): usb-storage 4-1:87.51: USB Mass Storage device detected proc_dir_entry 'scsi/usb-storage' already registered WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376 The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(), but guard that with the state check for SHOST_CREATED; there is even a comment in scsi_host_dev_release() detailing that: such conditional is meant for cases where the SCSI host was allocated but there was no calls to {add,remove}_host(), like the usb-storage case. This is what we propose here and with that, the error path of usb-storage does not trigger the warning anymore. Reported-by: syzbot+c645abf505ed21f931b5(a)syzkaller.appspotmail.com Fixes: be03df3d4bfe ("scsi: core: Fix a procfs host directory removal regression") Cc: stable(a)vger.kernel.org Cc: Bart Van Assche <bvanassche(a)acm.org> Cc: John Garry <john.g.garry(a)oracle.com> Cc: Shin'ichiro Kawasaki <shinichiro.kawasaki(a)wdc.com> Signed-off-by: Guilherme G. Piccoli <gpiccoli(a)igalia.com> Link: https://lore.kernel.org/r/20240313113006.2834799-1-gpiccoli@igalia.com Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/scsi/hosts.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/hosts.c b/drivers/scsi/hosts.c index 5bac4936c647..3feaa61f948f 100644 --- a/drivers/scsi/hosts.c +++ b/drivers/scsi/hosts.c @@ -334,12 +334,13 @@ static void scsi_host_dev_release(struct device *dev) if (shost->shost_state == SHOST_CREATED) { /* - * Free the shost_dev device name here if scsi_host_alloc() - * and scsi_host_put() have been called but neither + * Free the shost_dev device name and remove the proc host dir + * here if scsi_host_{alloc,put}() have been called but neither * scsi_host_add() nor scsi_host_remove() has been called. * This avoids that the memory allocated for the shost_dev - * name is leaked. + * name as well as the proc dir structure are leaked. */ + scsi_proc_hostdir_rm(shost->hostt); kfree(dev_name(&shost->shost_dev)); } -- 2.31.1

2 1

[PATCH OLK-5.10 0/1] CVE-2023-52650
by Yuntao Liu 07 May '24

07 May '24

CVE-2023-52650 Chen Ni (1): [Backport] drm/tegra: dsi: Add missing check for of_find_device_by_node drivers/gpu/drm/tegra/dsi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH openEuler-1.0-LTS 0/1] CVE-2023-52650
by Yuntao Liu 07 May '24

07 May '24

CVE-2023-52650 Chen Ni (1): [Backport] drm/tegra: dsi: Add missing check for of_find_device_by_node drivers/gpu/drm/tegra/dsi.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) -- 2.34.1

2 2

[PATCH OLK-5.10] fs: sysfs: Fix reference leak in sysfs_break_active_protection()
by Yifan Qiao 07 May '24

07 May '24

From: Alan Stern <stern(a)rowland.harvard.edu> stable inclusion from stable-v6.8.8 commit a4c99b57d43bab45225ba92d574a8683f9edc8e4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5IQ CVE: CVE-2024-26993 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a90bca2228c0646fc29a72689d308e5fe03e6d78 upstream. The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when kn is NULL. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Fixes: 2afc9166f79b ("scsi: sysfs: Introduce sysfs_{un,}break_active_protection()") Cc: Bart Van Assche <bvanassche(a)acm.org> Cc: stable(a)vger.kernel.org Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Acked-by: Tejun Heo <tj(a)kernel.org> Link: https://lore.kernel.org/r/8a4d3f0f-c5e3-4b70-a188-0ca433f9e6f9@rowland.harv… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/sysfs/file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index a12ac0356c69..f21e73d10724 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -450,6 +450,8 @@ struct kernfs_node *sysfs_break_active_protection(struct kobject *kobj, kn = kernfs_find_and_get(kobj->sd, attr->name); if (kn) kernfs_break_active_protection(kn); + else + kobject_put(kobj); return kn; } EXPORT_SYMBOL_GPL(sysfs_break_active_protection); -- 2.39.2

2 1

[PATCH OLK-6.6] fs: sysfs: Fix reference leak in sysfs_break_active_protection()
by Yifan Qiao 07 May '24

07 May '24

From: Alan Stern <stern(a)rowland.harvard.edu> stable inclusion from stable-v6.8.8 commit a4c99b57d43bab45225ba92d574a8683f9edc8e4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5IQ CVE: CVE-2024-26993 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a90bca2228c0646fc29a72689d308e5fe03e6d78 upstream. The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when kn is NULL. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Fixes: 2afc9166f79b ("scsi: sysfs: Introduce sysfs_{un,}break_active_protection()") Cc: Bart Van Assche <bvanassche(a)acm.org> Cc: stable(a)vger.kernel.org Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Acked-by: Tejun Heo <tj(a)kernel.org> Link: https://lore.kernel.org/r/8a4d3f0f-c5e3-4b70-a188-0ca433f9e6f9@rowland.harv… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/sysfs/file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index a12ac0356c69..f21e73d10724 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -450,6 +450,8 @@ struct kernfs_node *sysfs_break_active_protection(struct kobject *kobj, kn = kernfs_find_and_get(kobj->sd, attr->name); if (kn) kernfs_break_active_protection(kn); + else + kobject_put(kobj); return kn; } EXPORT_SYMBOL_GPL(sysfs_break_active_protection); -- 2.39.2

2 1

[PATCH openEuler-1.0-LTS] fs: sysfs: Fix reference leak in sysfs_break_active_protection()
by Yifan Qiao 07 May '24

07 May '24

From: Alan Stern <stern(a)rowland.harvard.edu> stable inclusion from stable-v6.8.8 commit a4c99b57d43bab45225ba92d574a8683f9edc8e4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5IQ CVE: CVE-2024-26993 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a90bca2228c0646fc29a72689d308e5fe03e6d78 upstream. The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when kn is NULL. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Fixes: 2afc9166f79b ("scsi: sysfs: Introduce sysfs_{un,}break_active_protection()") Cc: Bart Van Assche <bvanassche(a)acm.org> Cc: stable(a)vger.kernel.org Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Acked-by: Tejun Heo <tj(a)kernel.org> Link: https://lore.kernel.org/r/8a4d3f0f-c5e3-4b70-a188-0ca433f9e6f9@rowland.harv… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/sysfs/file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index a12ac0356c69..f21e73d10724 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -450,6 +450,8 @@ struct kernfs_node *sysfs_break_active_protection(struct kobject *kobj, kn = kernfs_find_and_get(kobj->sd, attr->name); if (kn) kernfs_break_active_protection(kn); + else + kobject_put(kobj); return kn; } EXPORT_SYMBOL_GPL(sysfs_break_active_protection); -- 2.39.2

2 1

[openeuler:OLK-5.10] BUILD SUCCESS 93f42c5daddd692f4cc1f56387774d46e083147c
by kernel test robot 07 May '24

07 May '24

tree/branch: https://gitee.com/openeuler/kernel.git OLK-5.10 branch HEAD: 93f42c5daddd692f4cc1f56387774d46e083147c !6798 media: ir_toy: fix a memleak in irtoy_tx Warning ids grouped by kconfigs: clang_recent_errors |-- arm64-allyesconfig | |-- Documentation-devicetree-bindings-arm-cpu.yaml:properties:capacity-dmips-mhz:ref-should-not-be-valid-under-const:ref | |-- Documentation-devicetree-bindings-arm-cpu.yaml:title:ARM-CPUs-bindings-should-not-be-valid-under-pattern:(-Bb-inding-Ss-chema) | |-- Documentation-devicetree-bindings-arm-cpus.yaml:examples:cpus-arm-pbha-performance-only-bits-arm-pbha-no-aliases-bits-ncpu-device_type-cpu-compatible-arm-cortex-a57-...-n-is-not-of-type-array | |-- Documentation-devicetree-bindings-arm-cpus.yaml:maintainers-is-a-required-property | |-- description:Display-controller-reference-clock-source-is-not-of-type-object-boolean | |-- description:Display-controller-reference-clock-source-is-too-short | |-- description:Offset-and-length-of-the-memory-mapped-registers-is-too-short | |-- items-is-not-one-of-type-description-dependencies-dependentRequired-dependentSchemas-properties-patternProperties-additionalProperties-unevaluatedProperties-deprecated-required-not-allOf-anyOf-oneOf-r | `-- minItems-is-not-one-of-type-description-dependencies-dependentRequired-dependentSchemas-properties-patternProperties-additionalProperties-unevaluatedProperties-deprecated-required-not-allOf-anyOf-oneO `-- x86_64-allnoconfig |-- Warning:openEuler-MAINTAINERS-references-a-file-that-doesn-t-exist:Documentation-networking-hinic3.rst `-- drivers-net-ethernet-mucse-rnpm-rnpm_common.h:linux-version.h-not-needed. elapsed time: 729m configs tested: 35 configs skipped: 149 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig clang arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20240507 clang arm64 randconfig-002-20240507 clang arm64 randconfig-003-20240507 clang arm64 randconfig-004-20240507 clang x86_64 allnoconfig clang x86_64 allyesconfig clang x86_64 buildonly-randconfig-001-20240507 clang x86_64 buildonly-randconfig-002-20240507 clang x86_64 buildonly-randconfig-003-20240507 clang x86_64 buildonly-randconfig-004-20240507 clang x86_64 buildonly-randconfig-005-20240507 clang x86_64 buildonly-randconfig-006-20240507 gcc x86_64 defconfig gcc x86_64 randconfig-001-20240507 gcc x86_64 randconfig-002-20240507 clang x86_64 randconfig-003-20240507 clang x86_64 randconfig-004-20240507 gcc x86_64 randconfig-005-20240507 gcc x86_64 randconfig-006-20240507 gcc x86_64 randconfig-011-20240507 gcc x86_64 randconfig-012-20240507 clang x86_64 randconfig-013-20240507 clang x86_64 randconfig-014-20240507 clang x86_64 randconfig-015-20240507 clang x86_64 randconfig-016-20240507 clang x86_64 randconfig-071-20240507 gcc x86_64 randconfig-072-20240507 gcc x86_64 randconfig-073-20240507 clang x86_64 randconfig-074-20240507 clang x86_64 randconfig-075-20240507 clang x86_64 randconfig-076-20240507 clang x86_64 rhel-8.3-rust clang -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[openEuler-1.0-LTS] nouveau: fix instmem race condition around ptr stores
by Yipeng Zou 07 May '24

07 May '24

From: Dave Airlie <airlied(a)redhat.com> stable inclusion from stable-v5.10 commit 13d76b2f443dc371842916dd8768009ff1594716 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9LK8M CVE: CVE-2024-26984 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit fff1386cc889d8fb4089d285f883f8cba62d82ce upstream. Running a lot of VK CTS in parallel against nouveau, once every few hours you might see something like this crash. BUG: kernel NULL pointer dereference, address: 0000000000000008 PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27 Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021 RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] Code: c7 48 01 c8 49 89 45 58 85 d2 0f 84 95 00 00 00 41 0f b7 46 12 49 8b 7e 08 89 da 42 8d 2c f8 48 8b 47 08 41 83 c7 01 48 89 ee <48> 8b 40 08 ff d0 0f 1f 00 49 8b 7e 08 48 89 d9 48 8d 75 04 48 c1 RSP: 0000:ffffac20c5857838 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001 RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180 RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10 R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c FS: 00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ... ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau] ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau] nvkm_vmm_iter+0x351/0xa20 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] ? __lock_acquire+0x3ed/0x2170 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau] ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau] ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau] nvkm_vmm_map_locked+0x224/0x3a0 [nouveau] Adding any sort of useful debug usually makes it go away, so I hand wrote the function in a line, and debugged the asm. Every so often pt->memory->ptrs is NULL. This ptrs ptr is set in the nv50_instobj_acquire called from nvkm_kmap. If Thread A and Thread B both get to nv50_instobj_acquire around the same time, and Thread A hits the refcount_set line, and in lockstep thread B succeeds at refcount_inc_not_zero, there is a chance the ptrs value won't have been stored since refcount_set is unordered. Force a memory barrier here, I picked smp_mb, since we want it on all CPUs and it's write followed by a read. v2: use paired smp_rmb/smp_wmb. Cc: <stable(a)vger.kernel.org> Fixes: be55287aa5ba ("drm/nouveau/imem/nv50: embed nvkm_instobj directly into nv04_instobj") Signed-off-by: Dave Airlie <airlied(a)redhat.com> Signed-off-by: Danilo Krummrich <dakr(a)redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240411011510.2546857-1-airl… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c index db48a1daca0c..f8ca79eaa7f7 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/instmem/nv50.c @@ -221,8 +221,11 @@ nv50_instobj_acquire(struct nvkm_memory *memory) void __iomem *map = NULL; /* Already mapped? */ - if (refcount_inc_not_zero(&iobj->maps)) + if (refcount_inc_not_zero(&iobj->maps)) { + /* read barrier match the wmb on refcount set */ + smp_rmb(); return iobj->map; + } /* Take the lock, and re-check that another thread hasn't * already mapped the object in the meantime. @@ -249,6 +252,8 @@ nv50_instobj_acquire(struct nvkm_memory *memory) iobj->base.memory.ptrs = &nv50_instobj_fast; else iobj->base.memory.ptrs = &nv50_instobj_slow; + /* barrier to ensure the ptrs are written before refcount is set */ + smp_wmb(); refcount_set(&iobj->maps, 1); } -- 2.34.1

1 0

[PATCH OLK-5.10] kprobes: Fix check for probe enabled in kill_kprobe()
by Pu Lehui 07 May '24

07 May '24

From: Li Huafei <lihuafei1(a)huawei.com> mainline inclusion from mainline-v6.2-rc1 commit 0c76ef3f26d5ef2ac2c21b47e7620cff35809fbb category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9MXH3 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- In kill_kprobe(), the check whether disarm_kprobe_ftrace() needs to be called always fails. This is because before that we set the KPROBE_FLAG_GONE flag for kprobe so that "!kprobe_disabled(p)" is always false. The disarm_kprobe_ftrace() call introduced by commit: 0cb2f1372baa ("kprobes: Fix NULL pointer dereference at kprobe_ftrace_handler") to fix the NULL pointer reference problem. When the probe is enabled, if we do not disarm it, this problem still exists. Fix it by putting the probe enabled check before setting the KPROBE_FLAG_GONE flag. Link: https://lore.kernel.org/all/20221126114316.201857-1-lihuafei1@huawei.com/ Fixes: 3031313eb3d54 ("kprobes: Fix to check probe enabled before disarm_kprobe_ftrace()") Signed-off-by: Li Huafei <lihuafei1(a)huawei.com> Acked-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Reviewed-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> Signed-off-by: Masami Hiramatsu (Google) <mhiramat(a)kernel.org> Signed-off-by: Pu Lehui <pulehui(a)huawei.com> --- kernel/kprobes.c | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/kernel/kprobes.c b/kernel/kprobes.c index 6fd66a47b476..325a81f9c38f 100644 --- a/kernel/kprobes.c +++ b/kernel/kprobes.c @@ -2281,6 +2281,14 @@ static void kill_kprobe(struct kprobe *p) if (WARN_ON_ONCE(kprobe_gone(p))) return; + /* + * The module is going away. We should disarm the kprobe which + * is using ftrace, because ftrace framework is still available at + * MODULE_STATE_GOING notification. + */ + if (kprobe_ftrace(p) && !kprobe_disabled(p) && !kprobes_all_disarmed) + disarm_kprobe_ftrace(p); + p->flags |= KPROBE_FLAG_GONE; if (kprobe_aggrprobe(p)) { /* @@ -2297,14 +2305,6 @@ static void kill_kprobe(struct kprobe *p) * the original probed function (which will be freed soon) any more. */ arch_remove_kprobe(p); - - /* - * The module is going away. We should disarm the kprobe which - * is using ftrace, because ftrace framework is still available at - * MODULE_STATE_GOING notification. - */ - if (kprobe_ftrace(p) && !kprobe_disabled(p) && !kprobes_all_disarmed) - disarm_kprobe_ftrace(p); } /* Disable one kprobe */ -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] fs: sysfs: Fix reference leak in sysfs_break_active_protection()
by Yifan Qiao 07 May '24

07 May '24

From: Alan Stern <stern(a)rowland.harvard.edu> stable inclusion from stable-v6.8.8 commit a4c99b57d43bab45225ba92d574a8683f9edc8e4 category: bugfix bugzilla: 189875 CVE: CVE-2024-26993 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a90bca2228c0646fc29a72689d308e5fe03e6d78 upstream. The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when kn is NULL. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Fixes: 2afc9166f79b ("scsi: sysfs: Introduce sysfs_{un,}break_active_protection()") Cc: Bart Van Assche <bvanassche(a)acm.org> Cc: stable(a)vger.kernel.org Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Acked-by: Tejun Heo <tj(a)kernel.org> Link: https://lore.kernel.org/r/8a4d3f0f-c5e3-4b70-a188-0ca433f9e6f9@rowland.harv… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/sysfs/file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index a12ac0356c69..f21e73d10724 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -450,6 +450,8 @@ struct kernfs_node *sysfs_break_active_protection(struct kobject *kobj, kn = kernfs_find_and_get(kobj->sd, attr->name); if (kn) kernfs_break_active_protection(kn); + else + kobject_put(kobj); return kn; } EXPORT_SYMBOL_GPL(sysfs_break_active_protection); -- 2.39.2

2 1

[PATCH OLK-5.10] fs: sysfs: Fix reference leak in sysfs_break_active_protection()
by Yifan Qiao 07 May '24

07 May '24

From: Alan Stern <stern(a)rowland.harvard.edu> stable inclusion from stable-v6.8.8 commit a4c99b57d43bab45225ba92d574a8683f9edc8e4 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5IQ CVE: CVE-2024-26993 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a90bca2228c0646fc29a72689d308e5fe03e6d78 upstream. The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when kn is NULL. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Fixes: 2afc9166f79b ("scsi: sysfs: Introduce sysfs_{un,}break_active_protection()") Cc: Bart Van Assche <bvanassche(a)acm.org> Cc: stable(a)vger.kernel.org Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Acked-by: Tejun Heo <tj(a)kernel.org> Link: https://lore.kernel.org/r/8a4d3f0f-c5e3-4b70-a188-0ca433f9e6f9@rowland.harv… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/sysfs/file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index a12ac0356c69..f21e73d10724 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -450,6 +450,8 @@ struct kernfs_node *sysfs_break_active_protection(struct kobject *kobj, kn = kernfs_find_and_get(kobj->sd, attr->name); if (kn) kernfs_break_active_protection(kn); + else + kobject_put(kobj); return kn; } EXPORT_SYMBOL_GPL(sysfs_break_active_protection); -- 2.39.2

2 1

[PATCH OLK-6.6] fs: sysfs: Fix reference leak in sysfs_break_active_protection()
by Yifan Qiao 07 May '24

07 May '24

From: Alan Stern <stern(a)rowland.harvard.edu> stable inclusion from stable-v6.8.8 commit a4c99b57d43bab45225ba92d574a8683f9edc8e4 category: bugfix bugzilla: 189875 CVE: CVE-2024-26993 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit a90bca2228c0646fc29a72689d308e5fe03e6d78 upstream. The sysfs_break_active_protection() routine has an obvious reference leak in its error path. If the call to kernfs_find_and_get() fails then kn will be NULL, so the companion sysfs_unbreak_active_protection() routine won't get called (and would only cause an access violation by trying to dereference kn->parent if it was called). As a result, the reference to kobj acquired at the start of the function will never be released. Fix the leak by adding an explicit kobject_put() call when kn is NULL. Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu> Fixes: 2afc9166f79b ("scsi: sysfs: Introduce sysfs_{un,}break_active_protection()") Cc: Bart Van Assche <bvanassche(a)acm.org> Cc: stable(a)vger.kernel.org Reviewed-by: Bart Van Assche <bvanassche(a)acm.org> Acked-by: Tejun Heo <tj(a)kernel.org> Link: https://lore.kernel.org/r/8a4d3f0f-c5e3-4b70-a188-0ca433f9e6f9@rowland.harv… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/sysfs/file.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/sysfs/file.c b/fs/sysfs/file.c index a12ac0356c69..f21e73d10724 100644 --- a/fs/sysfs/file.c +++ b/fs/sysfs/file.c @@ -450,6 +450,8 @@ struct kernfs_node *sysfs_break_active_protection(struct kobject *kobj, kn = kernfs_find_and_get(kobj->sd, attr->name); if (kn) kernfs_break_active_protection(kn); + else + kobject_put(kobj); return kn; } EXPORT_SYMBOL_GPL(sysfs_break_active_protection); -- 2.39.2

2 1

[PATCH OLK-5.10] perf/x86/amd: Fix crash due to race between amd_pmu_enable_all, perf NMI and throttling
by Luo Gengkun 07 May '24

07 May '24

From: Ravi Bangoria <ravi.bangoria(a)amd.com> mainline inclusion from mainline-v6.1-rc6v6.1 commit baa014b9543c8e5e94f5d15b66abfe60750b8284 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9MMNG Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- amd_pmu_enable_all() does: if (!test_bit(idx, cpuc->active_mask)) continue; amd_pmu_enable_event(cpuc->events[idx]); A perf NMI of another event can come between these two steps. Perf NMI handler internally disables and enables _all_ events, including the one which nmi-intercepted amd_pmu_enable_all() was in process of enabling. If that unintentionally enabled event has very low sampling period and causes immediate successive NMI, causing the event to be throttled, cpuc->events[idx] and cpuc->active_mask gets cleared by x86_pmu_stop(). This will result in amd_pmu_enable_event() getting called with event=NULL when amd_pmu_enable_all() resumes after handling the NMIs. This causes a kernel crash: BUG: kernel NULL pointer dereference, address: 0000000000000198 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page [...] Call Trace: <TASK> amd_pmu_enable_all+0x68/0xb0 ctx_resched+0xd9/0x150 event_function+0xb8/0x130 ? hrtimer_start_range_ns+0x141/0x4a0 ? perf_duration_warn+0x30/0x30 remote_function+0x4d/0x60 __flush_smp_call_function_queue+0xc4/0x500 flush_smp_call_function_queue+0x11d/0x1b0 do_idle+0x18f/0x2d0 cpu_startup_entry+0x19/0x20 start_secondary+0x121/0x160 secondary_startup_64_no_verify+0xe5/0xeb </TASK> amd_pmu_disable_all()/amd_pmu_enable_all() calls inside perf NMI handler were recently added as part of BRS enablement but I'm not sure whether we really need them. We can just disable BRS in the beginning and enable it back while returning from NMI. This will solve the issue by not enabling those events whose active_masks are set but are not yet enabled in hw pmu. Fixes: ada543459cab ("perf/x86/amd: Add AMD Fam19h Branch Sampling support") Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> Signed-off-by: Ravi Bangoria <ravi.bangoria(a)amd.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Link: https://lkml.kernel.org/r/20221114044029.373-1-ravi.bangoria@amd.com Signed-off-by: Luo Gengkun <luogengkun2(a)huawei.com> --- arch/x86/events/amd/core.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/events/amd/core.c b/arch/x86/events/amd/core.c index 2c082abb930b..3127519281f5 100644 --- a/arch/x86/events/amd/core.c +++ b/arch/x86/events/amd/core.c @@ -900,8 +900,7 @@ static int amd_pmu_handle_irq(struct pt_regs *regs) pmu_enabled = cpuc->enabled; cpuc->enabled = 0; - /* stop everything (includes BRS) */ - amd_pmu_disable_all(); + amd_brs_disable_all(); /* Drain BRS is in use (could be inactive) */ if (cpuc->lbr_users) @@ -912,7 +911,7 @@ static int amd_pmu_handle_irq(struct pt_regs *regs) cpuc->enabled = pmu_enabled; if (pmu_enabled) - amd_pmu_enable_all(0); + amd_brs_enable_all(); return amd_pmu_adjust_nmi_window(handled); } -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] fat: fix uninitialized field in nostale filehandles
by Yifan Qiao 07 May '24

07 May '24

From: Jan Kara <jack(a)suse.cz> stable inclusion from stable-v6.8.3 commit cdd33d54e789d229d6d5007cbf3f53965ca1a5c6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5QJ CVE: CVE-2024-26973 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fde2497d2bc3a063d8af88b258dbadc86bd7b57c ] When fat_encode_fh_nostale() encodes file handle without a parent it stores only first 10 bytes of the file handle. However the length of the file handle must be a multiple of 4 so the file handle is actually 12 bytes long and the last two bytes remain uninitialized. This is not great at we potentially leak uninitialized information with the handle to userspace. Properly initialize the full handle length. Link: https://lkml.kernel.org/r/20240205122626.13701-1-jack@suse.cz Reported-by: syzbot+3ce5dea5b1539ff36769(a)syzkaller.appspotmail.com Fixes: ea3983ace6b7 ("fat: restructure export_operations") Signed-off-by: Jan Kara <jack(a)suse.cz> Acked-by: OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp> Cc: Amir Goldstein <amir73il(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/fat/nfs.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/fat/nfs.c b/fs/fat/nfs.c index af191371c352..bab63eeaf9cb 100644 --- a/fs/fat/nfs.c +++ b/fs/fat/nfs.c @@ -130,6 +130,12 @@ fat_encode_fh_nostale(struct inode *inode, __u32 *fh, int *lenp, fid->parent_i_gen = parent->i_generation; type = FILEID_FAT_WITH_PARENT; *lenp = FAT_FID_SIZE_WITH_PARENT; + } else { + /* + * We need to initialize this field because the fh is actually + * 12 bytes long + */ + fid->parent_i_pos_hi = 0; } return type; -- 2.39.2

2 1

[PATCH OLK-5.10] fat: fix uninitialized field in nostale filehandles
by Yifan Qiao 07 May '24

07 May '24

From: Jan Kara <jack(a)suse.cz> stable inclusion from stable-v6.8.3 commit cdd33d54e789d229d6d5007cbf3f53965ca1a5c6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5QJ CVE: CVE-2024-26973 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fde2497d2bc3a063d8af88b258dbadc86bd7b57c ] When fat_encode_fh_nostale() encodes file handle without a parent it stores only first 10 bytes of the file handle. However the length of the file handle must be a multiple of 4 so the file handle is actually 12 bytes long and the last two bytes remain uninitialized. This is not great at we potentially leak uninitialized information with the handle to userspace. Properly initialize the full handle length. Link: https://lkml.kernel.org/r/20240205122626.13701-1-jack@suse.cz Reported-by: syzbot+3ce5dea5b1539ff36769(a)syzkaller.appspotmail.com Fixes: ea3983ace6b7 ("fat: restructure export_operations") Signed-off-by: Jan Kara <jack(a)suse.cz> Acked-by: OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp> Cc: Amir Goldstein <amir73il(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/fat/nfs.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/fat/nfs.c b/fs/fat/nfs.c index af191371c352..bab63eeaf9cb 100644 --- a/fs/fat/nfs.c +++ b/fs/fat/nfs.c @@ -130,6 +130,12 @@ fat_encode_fh_nostale(struct inode *inode, __u32 *fh, int *lenp, fid->parent_i_gen = parent->i_generation; type = FILEID_FAT_WITH_PARENT; *lenp = FAT_FID_SIZE_WITH_PARENT; + } else { + /* + * We need to initialize this field because the fh is actually + * 12 bytes long + */ + fid->parent_i_pos_hi = 0; } return type; -- 2.39.2

2 1

[PATCH OLK-6.6] fat: fix uninitialized field in nostale filehandles
by Yifan Qiao 07 May '24

07 May '24

From: Jan Kara <jack(a)suse.cz> stable inclusion from stable-v6.8.3 commit cdd33d54e789d229d6d5007cbf3f53965ca1a5c6 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L5QJ CVE: CVE-2024-26973 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit fde2497d2bc3a063d8af88b258dbadc86bd7b57c ] When fat_encode_fh_nostale() encodes file handle without a parent it stores only first 10 bytes of the file handle. However the length of the file handle must be a multiple of 4 so the file handle is actually 12 bytes long and the last two bytes remain uninitialized. This is not great at we potentially leak uninitialized information with the handle to userspace. Properly initialize the full handle length. Link: https://lkml.kernel.org/r/20240205122626.13701-1-jack@suse.cz Reported-by: syzbot+3ce5dea5b1539ff36769(a)syzkaller.appspotmail.com Fixes: ea3983ace6b7 ("fat: restructure export_operations") Signed-off-by: Jan Kara <jack(a)suse.cz> Acked-by: OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp> Cc: Amir Goldstein <amir73il(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yifan Qiao <qiaoyifan4(a)huawei.com> --- fs/fat/nfs.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/fat/nfs.c b/fs/fat/nfs.c index af191371c352..bab63eeaf9cb 100644 --- a/fs/fat/nfs.c +++ b/fs/fat/nfs.c @@ -130,6 +130,12 @@ fat_encode_fh_nostale(struct inode *inode, __u32 *fh, int *lenp, fid->parent_i_gen = parent->i_generation; type = FILEID_FAT_WITH_PARENT; *lenp = FAT_FID_SIZE_WITH_PARENT; + } else { + /* + * We need to initialize this field because the fh is actually + * 12 bytes long + */ + fid->parent_i_pos_hi = 0; } return type; -- 2.39.2

2 1

[openEuler-1.0-LTS] media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity
by Yipeng Zou 07 May '24

07 May '24

From: Zhipeng Lu <alexious(a)zju.edu.cn> stable inclusion from stable-v5.10.214 commit afd2a82fe300032f63f8be5d6cd6981e75f8bbf2 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9L9JK CVE: CVE-2024-27077 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- The entity->name (i.e. name) is allocated in v4l2_m2m_register_entity but isn't freed in its following error-handling paths. This patch adds such deallocation to prevent memleak of entity->name. Fixes: be2fff656322 ("media: add helpers for memory-to-memory media controller") Signed-off-by: Zhipeng Lu <alexious(a)zju.edu.cn> Signed-off-by: Hans Verkuil <hverkuil-cisco(a)xs4all.nl> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Yipeng Zou <zouyipeng(a)huawei.com> --- drivers/media/v4l2-core/v4l2-mem2mem.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c b/drivers/media/v4l2-core/v4l2-mem2mem.c index 692b0597a35c..0a9be4c5f194 100644 --- a/drivers/media/v4l2-core/v4l2-mem2mem.c +++ b/drivers/media/v4l2-core/v4l2-mem2mem.c @@ -773,11 +773,17 @@ static int v4l2_m2m_register_entity(struct media_device *mdev, entity->function = function; ret = media_entity_pads_init(entity, num_pads, pads); - if (ret) + if (ret) { + kfree(entity->name); + entity->name = NULL; return ret; + } ret = media_device_register_entity(mdev, entity); - if (ret) + if (ret) { + kfree(entity->name); + entity->name = NULL; return ret; + } return 0; } -- 2.34.1

1 0

[PATCH OLK-6.6 0/2] Introduce CONFIG_ARCH_CUSTOM_NUMA_DISTANCE
by Hui Tang 07 May '24

07 May '24

This patchset allow arch adjust node_relaim_distance, as follow: Hui Tang (2): arm64/numa: Support node_reclaim_distance adjust for arch config: enable COBFIG_ARCH_CUSTOM_NUMA_DISTANCE for arm64 arch/arm64/Kconfig | 13 ++++ arch/arm64/configs/openeuler_defconfig | 1 + drivers/base/arch_numa.c | 85 ++++++++++++++++++++++++++ 3 files changed, 99 insertions(+) -- 2.34.1

2 3

[openeuler:openEuler-1.0-LTS] BUILD SUCCESS 48d720404c6ef5c0c29a6019fa34590b3632cf4c
by kernel test robot 07 May '24

07 May '24

tree/branch: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS branch HEAD: 48d720404c6ef5c0c29a6019fa34590b3632cf4c !6705 quota: fix CVE-2024-26878 Warning ids grouped by kconfigs: gcc_recent_errors |-- x86_64-buildonly-randconfig-002-20240506 | |-- fs-proc-array.c:warning:gtime-may-be-used-uninitialized-in-this-function | |-- fs-proc-array.c:warning:maj_flt-may-be-used-uninitialized-in-this-function | `-- fs-proc-array.c:warning:min_flt-may-be-used-uninitialized-in-this-function |-- x86_64-buildonly-randconfig-006-20240506 | |-- fs-proc-array.c:warning:gtime-may-be-used-uninitialized | |-- fs-proc-array.c:warning:maj_flt-may-be-used-uninitialized | `-- fs-proc-array.c:warning:min_flt-may-be-used-uninitialized |-- x86_64-defconfig | |-- include-linux-list.h:warning:array-subscript-pfo_ret__-is-outside-array-bounds-of-struct-plist_node | |-- include-linux-plist.h:warning:array-subscript-pfo_ret__-is-outside-array-bounds-of-struct-plist_node | `-- mm-swapfile.c:warning:array-subscript-pfo_ret__-is-outside-array-bounds-of-struct-plist_node |-- x86_64-randconfig-014-20240506 | |-- include-linux-compiler.h:warning:array-subscript-index-is-outside-array-bounds-of-u32-aka-unsigned-int | `-- include-linux-compiler.h:warning:array-subscript-unknown-is-outside-array-bounds-of-const-u32-aka-const-unsigned-int |-- x86_64-randconfig-071-20240506 | |-- include-linux-compiler.h:warning:array-subscript-index-is-outside-array-bounds-of-u32-aka-unsigned-int | `-- include-linux-compiler.h:warning:array-subscript-unknown-is-outside-array-bounds-of-const-u32-aka-const-unsigned-int |-- x86_64-randconfig-073-20240506 | |-- include-linux-compiler.h:warning:array-subscript-index-is-outside-array-bounds-of-u32-aka-unsigned-int | |-- include-linux-compiler.h:warning:array-subscript-unknown-is-outside-array-bounds-of-const-u32-aka-const-unsigned-int | |-- include-linux-list.h:warning:array-subscript-pfo_ret__-is-outside-array-bounds-of-struct-plist_node | |-- include-linux-plist.h:warning:array-subscript-pfo_ret__-is-outside-array-bounds-of-struct-plist_node | `-- mm-swapfile.c:warning:array-subscript-pfo_ret__-is-outside-array-bounds-of-struct-plist_node |-- x86_64-randconfig-104-20240506 | |-- include-linux-compiler.h:warning:array-subscript-index-is-outside-array-bounds-of-u32-aka-unsigned-int | `-- include-linux-compiler.h:warning:array-subscript-unknown-is-outside-array-bounds-of-const-u32-aka-const-unsigned-int |-- x86_64-randconfig-121-20240507 | `-- net-ipv4-arp.c:sparse:sparse:incompatible-types-in-comparison-expression-(different-type-sizes): `-- x86_64-randconfig-123-20240507 |-- include-linux-compiler.h:warning:array-subscript-index-is-outside-array-bounds-of-u32-aka-unsigned-int |-- include-linux-compiler.h:warning:array-subscript-unknown-is-outside-array-bounds-of-const-u32-aka-const-unsigned-int |-- include-linux-list.h:warning:array-subscript-pfo_ret__-is-outside-array-bounds-of-struct-plist_node |-- include-linux-plist.h:warning:array-subscript-pfo_ret__-is-outside-array-bounds-of-struct-plist_node |-- mm-swapfile.c:warning:array-subscript-pfo_ret__-is-outside-array-bounds-of-struct-plist_node `-- net-ipv4-arp.c:sparse:sparse:incompatible-types-in-comparison-expression-(different-type-sizes): clang_recent_errors |-- x86_64-allyesconfig | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-001-20240506 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-002-20240506 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-003-20240506 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-004-20240506 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-005-20240506 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-006-20240506 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-072-20240506 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-074-20240506 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-076-20240506 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-101-20240506 | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) |-- x86_64-randconfig-122-20240507 | |-- net-ipv4-arp.c:sparse:sparse:incompatible-types-in-comparison-expression-(different-type-sizes): | `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) `-- x86_64-rhel-8.3-rust `-- net-ipv4-arp.c:warning:comparison-of-distinct-pointer-types-(-typeof-(dev-addr_len)-(aka-unsigned-char-)-and-typeof-(sizeof-(r-arp_ha.sa_data))-(aka-unsigned-long-)) elapsed time: 721m configs tested: 35 configs skipped: 148 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: arm64 allmodconfig gcc arm64 allnoconfig gcc arm64 defconfig gcc arm64 randconfig-001-20240506 gcc arm64 randconfig-002-20240506 gcc arm64 randconfig-003-20240506 gcc arm64 randconfig-004-20240506 gcc x86_64 allnoconfig clang x86_64 allyesconfig clang x86_64 buildonly-randconfig-001-20240506 gcc x86_64 buildonly-randconfig-002-20240506 gcc x86_64 buildonly-randconfig-003-20240506 gcc x86_64 buildonly-randconfig-004-20240506 clang x86_64 buildonly-randconfig-005-20240506 clang x86_64 buildonly-randconfig-006-20240506 gcc x86_64 defconfig gcc x86_64 randconfig-001-20240506 clang x86_64 randconfig-002-20240506 clang x86_64 randconfig-003-20240506 clang x86_64 randconfig-004-20240506 clang x86_64 randconfig-005-20240506 clang x86_64 randconfig-006-20240506 clang x86_64 randconfig-011-20240506 gcc x86_64 randconfig-012-20240506 gcc x86_64 randconfig-013-20240506 gcc x86_64 randconfig-014-20240506 gcc x86_64 randconfig-015-20240506 gcc x86_64 randconfig-016-20240506 gcc x86_64 randconfig-071-20240506 gcc x86_64 randconfig-072-20240506 clang x86_64 randconfig-073-20240506 gcc x86_64 randconfig-074-20240506 clang x86_64 randconfig-075-20240506 gcc x86_64 randconfig-076-20240506 clang x86_64 rhel-8.3-rust clang -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] sched/fair: Optimize performance by simplifying cpu_util_without()
by Li Zetao 06 May '24

06 May '24

hulk inclusion category: performance bugzilla: https://gitee.com/openeuler/kernel/issues/I9MSNE?from=project-issue CVE: NA -------------------------------- Considering that the high-frequency function cpu_util without is only called when waking up or creating for the first time, in this scenario, the performance can be optimized by simplifying the function. Signed-off-by: Zhang Qiao <zhangqiao22(a)huawei.com> Signed-off-by: Li Zetao <lizetao1(a)huawei.com> --- kernel/sched/fair.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 7b0cb2f090da..010dbf2047e5 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -8530,13 +8530,23 @@ unsigned long cpu_util_cfs_boost(int cpu) * utilization of the specified task, whenever the task is currently * contributing to the CPU utilization. */ -static unsigned long cpu_util_without(int cpu, struct task_struct *p) +static inline unsigned long cpu_util_without(int cpu, struct task_struct *p) { - /* Task has no contribution or is new */ - if (cpu != task_cpu(p) || !READ_ONCE(p->se.avg.last_update_time)) - p = NULL; + struct cfs_rq *cfs_rq = &cpu_rq(cpu)->cfs; + unsigned long util = READ_ONCE(cfs_rq->avg.util_avg); + /* + * If @dst_cpu is -1 or @p migrates from @cpu to @dst_cpu remove its + * contribution. If @p migrates from another CPU to @cpu add its + * contribution. In all the other cases @cpu is not impacted by the + * migration so its util_avg is already correct. + */ + if (sched_feat(UTIL_EST)) { + unsigned long util_est; + util_est = READ_ONCE(cfs_rq->avg.util_est.enqueued); + util = max(util, util_est); + } - return cpu_util(cpu, p, -1, 0); + return min(util, capacity_orig_of(cpu)); } /* -- 2.34.1

2 1

[PATCH OLK-6.6 v3 0/2] block: fix discard ioctl
by Li Nan 06 May '24

06 May '24

Fix patch format. Li Nan (2): block: fix overflow in blk_ioctl_discard() block: check io size before submit discard block/blk-lib.c | 8 ++++++++ block/ioctl.c | 5 +++-- 2 files changed, 11 insertions(+), 2 deletions(-) -- 2.39.2

2 3

[PATCH openEuler-1.0-LTS] s390/dasd: fix Oops in dasd_alias_get_start_dev due to missing pavgroup
by Li Zetao 06 May '24

06 May '24

From: Stefan Haberland <sth(a)linux.ibm.com> stable inclusion from stable-v4.19.260 commit aaba5ff2742043705bc4c02fd0b2b246e2e16da1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9KHGT CVE: CVE-2022-48636 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit db7ba07108a48c0f95b74fabbfd5d63e924f992d upstream. Fix Oops in dasd_alias_get_start_dev() function caused by the pavgroup pointer being NULL. The pavgroup pointer is checked on the entrance of the function but without the lcu->lock being held. Therefore there is a race window between dasd_alias_get_start_dev() and _lcu_update() which sets pavgroup to NULL with the lcu->lock held. Fix by checking the pavgroup pointer with lcu->lock held. Cc: <stable(a)vger.kernel.org> # 2.6.25+ Fixes: 8e09f21574ea ("[S390] dasd: add hyper PAV support to DASD device driver, part 1") Signed-off-by: Stefan Haberland <sth(a)linux.ibm.com> Reviewed-by: Jan Hoeppner <hoeppner(a)linux.ibm.com> Link: https://lore.kernel.org/r/20220919154931.4123002-2-sth@linux.ibm.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Zetao <lizetao1(a)huawei.com> --- drivers/s390/block/dasd_alias.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/s390/block/dasd_alias.c b/drivers/s390/block/dasd_alias.c index 99f86612f775..88530a4952a9 100644 --- a/drivers/s390/block/dasd_alias.c +++ b/drivers/s390/block/dasd_alias.c @@ -657,12 +657,12 @@ int dasd_alias_remove_device(struct dasd_device *device) struct dasd_device *dasd_alias_get_start_dev(struct dasd_device *base_device) { struct dasd_eckd_private *alias_priv, *private = base_device->private; - struct alias_pav_group *group = private->pavgroup; struct alias_lcu *lcu = private->lcu; struct dasd_device *alias_device; + struct alias_pav_group *group; unsigned long flags; - if (!group || !lcu) + if (!lcu) return NULL; if (lcu->pav == NO_PAV || lcu->flags & (NEED_UAC_UPDATE | UPDATE_PENDING)) @@ -679,6 +679,11 @@ struct dasd_device *dasd_alias_get_start_dev(struct dasd_device *base_device) } spin_lock_irqsave(&lcu->lock, flags); + group = private->pavgroup; + if (!group) { + spin_unlock_irqrestore(&lcu->lock, flags); + return NULL; + } alias_device = group->next; if (!alias_device) { if (list_empty(&group->aliaslist)) { -- 2.34.1

2 3

[PATCH OLK-6.6 v2 0/2] block: fix discard ioctl
by Li Nan 06 May '24

06 May '24

Li Nan (2): block: fix overflow in blk_ioctl_discard() block: check io size before submit discard block/blk-lib.c | 8 ++++++++ block/ioctl.c | 5 +++-- 2 files changed, 11 insertions(+), 2 deletions(-) -- 2.39.2

2 3

[PATCH OLK-5.10] mm: memcg: fix stale protection of reclaim target memcg
by Cai Xinchen 06 May '24

06 May '24

From: Yosry Ahmed <yosryahmed(a)google.com> mainline inclusion from mainline-v6.2-rc1 commit adb8213014b25c7f1d75d5b219becaadcd695efb category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9MD18 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Patch series "mm: memcg: fix protection of reclaim target memcg", v3. This series fixes a bug in calculating the protection of the reclaim target memcg where we end up using stale effective protection values from the last reclaim operation, instead of completely ignoring the protection of the reclaim target as intended. More detailed explanation and examples in patch 1, which includes the fix. Patches 2 & 3 introduce a selftest case that catches the bug. This patch (of 3): When we are doing memcg reclaim, the intended behavior is that we ignore any protection (memory.min, memory.low) of the target memcg (but not its children). Ever since the patch pointed to by the "Fixes" tag, we actually read a stale value for the target memcg protection when deciding whether to skip the memcg or not because it is protected. If the stale value happens to be high enough, we don't reclaim from the target memcg. Essentially, in some cases we may falsely skip reclaiming from the target memcg of reclaim because we read a stale protection value from last time we reclaimed from it. During reclaim, mem_cgroup_calculate_protection() is used to determine the effective protection (emin and elow) values of a memcg. The protection of the reclaim target is ignored, but we cannot set their effective protection to 0 due to a limitation of the current implementation (see comment in mem_cgroup_protection()). Instead, we leave their effective protection values unchaged, and later ignore it in mem_cgroup_protection(). However, mem_cgroup_protection() is called later in shrink_lruvec()->get_scan_count(), which is after the mem_cgroup_below_{min/low}() checks in shrink_node_memcgs(). As a result, the stale effective protection values of the target memcg may lead us to skip reclaiming from the target memcg entirely, before calling shrink_lruvec(). This can be even worse with recursive protection, where the stale target memcg protection can be higher than its standalone protection. See two examples below (a similar version of example (a) is added to test_memcontrol in a later patch). (a) A simple example with proactive reclaim is as follows. Consider the following hierarchy: ROOT | A | B (memory.min = 10M) Consider the following scenario: - B has memory.current = 10M. - The system undergoes global reclaim (or memcg reclaim in A). - In shrink_node_memcgs(): - mem_cgroup_calculate_protection() calculates the effective min (emin) of B as 10M. - mem_cgroup_below_min() returns true for B, we do not reclaim from B. - Now if we want to reclaim 5M from B using proactive reclaim (memory.reclaim), we should be able to, as the protection of the target memcg should be ignored. - In shrink_node_memcgs(): - mem_cgroup_calculate_protection() immediately returns for B without doing anything, as B is the target memcg, relying on mem_cgroup_protection() to ignore B's stale effective min (still 10M). - mem_cgroup_below_min() reads the stale effective min for B and we skip it instead of ignoring its protection as intended, as we never reach mem_cgroup_protection(). (b) An more complex example with recursive protection is as follows. Consider the following hierarchy with memory_recursiveprot: ROOT | A (memory.min = 50M) | B (memory.min = 10M, memory.high = 40M) Consider the following scenario: - B has memory.current = 35M. - The system undergoes global reclaim (target memcg is NULL). - B will have an effective min of 50M (all of A's unclaimed protection). - B will not be reclaimed from. - Now allocate 10M more memory in B, pushing it above it's high limit. - The system undergoes memcg reclaim from B (target memcg is B). - Like example (a), we do nothing in mem_cgroup_calculate_protection(), then call mem_cgroup_below_min(), which will read the stale effective min for B (50M) and skip it. In this case, it's even worse because we are not just considering B's standalone protection (10M), but we are reading a much higher stale protection (50M) which will cause us to not reclaim from B at all. This is an artifact of commit 45c7f7e1ef17 ("mm, memcg: decouple e{low,min} state mutations from protection checks") which made mem_cgroup_calculate_protection() only change the state without returning any value. Before that commit, we used to return MEMCG_PROT_NONE for the target memcg, which would cause us to skip the mem_cgroup_below_{min/low}() checks. After that commit we do not return anything and we end up checking the min & low effective protections for the target memcg, which are stale. Update mem_cgroup_supports_protection() to also check if we are reclaiming from the target, and rename it to mem_cgroup_unprotected() (now returns true if we should not protect the memcg, much simpler logic). Link: https://lkml.kernel.org/r/20221202031512.1365483-1-yosryahmed@google.com Link: https://lkml.kernel.org/r/20221202031512.1365483-2-yosryahmed@google.com Fixes: 45c7f7e1ef17 ("mm, memcg: decouple e{low,min} state mutations from protection checks") Signed-off-by: Yosry Ahmed <yosryahmed(a)google.com> Reviewed-by: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: Chris Down <chris(a)chrisdown.name> Cc: David Rientjes <rientjes(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Muchun Song <songmuchun(a)bytedance.com> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: Tejun Heo <tj(a)kernel.org> Cc: Vasily Averin <vasily.averin(a)linux.dev> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Yu Zhao <yuzhao(a)google.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: mm/vmscan.c Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- include/linux/memcontrol.h | 31 +++++++++++++++++++++---------- mm/vmscan.c | 4 ++-- 2 files changed, 23 insertions(+), 12 deletions(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 24794b56eaaf..287c54141a90 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -769,28 +769,32 @@ static inline void mem_cgroup_protection(struct mem_cgroup *root, void mem_cgroup_calculate_protection(struct mem_cgroup *root, struct mem_cgroup *memcg); -static inline bool mem_cgroup_supports_protection(struct mem_cgroup *memcg) +static inline bool mem_cgroup_unprotected(struct mem_cgroup *target, + struct mem_cgroup *memcg) { /* * The root memcg doesn't account charges, and doesn't support - * protection. + * protection. The target memcg's protection is ignored, see + * mem_cgroup_calculate_protection() and mem_cgroup_protection() */ - return !mem_cgroup_disabled() && !mem_cgroup_is_root(memcg); - + return mem_cgroup_disabled() || mem_cgroup_is_root(memcg) || + memcg == target; } -static inline bool mem_cgroup_below_low(struct mem_cgroup *memcg) +static inline bool mem_cgroup_below_low(struct mem_cgroup *target, + struct mem_cgroup *memcg) { - if (!mem_cgroup_supports_protection(memcg)) + if (mem_cgroup_unprotected(target, memcg)) return false; return READ_ONCE(memcg->memory.elow) >= page_counter_read(&memcg->memory); } -static inline bool mem_cgroup_below_min(struct mem_cgroup *memcg) +static inline bool mem_cgroup_below_min(struct mem_cgroup *target, + struct mem_cgroup *memcg) { - if (!mem_cgroup_supports_protection(memcg)) + if (mem_cgroup_unprotected(target, memcg)) return false; return READ_ONCE(memcg->memory.emin) >= @@ -1378,12 +1382,19 @@ static inline void mem_cgroup_calculate_protection(struct mem_cgroup *root, { } -static inline bool mem_cgroup_below_low(struct mem_cgroup *memcg) +static inline bool mem_cgroup_unprotected(struct mem_cgroup *target, + struct mem_cgroup *memcg) +{ + return true; +} +static inline bool mem_cgroup_below_low(struct mem_cgroup *target, + struct mem_cgroup *memcg) { return false; } -static inline bool mem_cgroup_below_min(struct mem_cgroup *memcg) +static inline bool mem_cgroup_below_min(struct mem_cgroup *target, + struct mem_cgroup *memcg) { return false; } diff --git a/mm/vmscan.c b/mm/vmscan.c index 3d383c7126e3..044bf496885b 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2860,13 +2860,13 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc) mem_cgroup_calculate_protection(target_memcg, memcg); - if (mem_cgroup_below_min(memcg)) { + if (mem_cgroup_below_min(target_memcg, memcg)) { /* * Hard protection. * If there is no reclaimable memory, OOM. */ continue; - } else if (mem_cgroup_below_low(memcg)) { + } else if (mem_cgroup_below_low(target_memcg, memcg)) { /* * Soft protection. * Respect the protection only as long as -- 2.34.1

2 1

[PATCH OLK-5.10] drivers: base: transport_class: fix possible memory leak
by dinglongwei 06 May '24

06 May '24

From: Yang Yingliang <yangyingliang(a)huawei.com> mainline inclusion from mainline-v6.3-rc1 commit a86367803838b369fe5486ac18771d14723c258c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9MMNG Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Current some drivers(like iscsi) call transport_register_device() failed, they don't call transport_destroy_device() to release the memory allocated in transport_setup_device(), because they don't know what was done, it should be internal thing to release the resource in register function. So fix this leak by calling destroy function inside register function. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Link: https://lore.kernel.org/r/20221110102307.3492557-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- include/linux/transport_class.h | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/include/linux/transport_class.h b/include/linux/transport_class.h index 63076fb835e3..2efc271a96fa 100644 --- a/include/linux/transport_class.h +++ b/include/linux/transport_class.h @@ -70,8 +70,14 @@ void transport_destroy_device(struct device *); static inline int transport_register_device(struct device *dev) { + int ret; + transport_setup_device(dev); - return transport_add_device(dev); + ret = transport_add_device(dev); + if (ret) + transport_destroy_device(dev); + + return ret; } static inline void -- 2.17.1

2 1

[PATCH] mm: memcg: fix stale protection of reclaim target memcg
by Cai Xinchen 06 May '24

06 May '24

From: Yosry Ahmed <yosryahmed(a)google.com> mainline inclusion from mainline-v6.2-rc1 commit adb8213014b25c7f1d75d5b219becaadcd695efb category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9MD18 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Patch series "mm: memcg: fix protection of reclaim target memcg", v3. This series fixes a bug in calculating the protection of the reclaim target memcg where we end up using stale effective protection values from the last reclaim operation, instead of completely ignoring the protection of the reclaim target as intended. More detailed explanation and examples in patch 1, which includes the fix. Patches 2 & 3 introduce a selftest case that catches the bug. This patch (of 3): When we are doing memcg reclaim, the intended behavior is that we ignore any protection (memory.min, memory.low) of the target memcg (but not its children). Ever since the patch pointed to by the "Fixes" tag, we actually read a stale value for the target memcg protection when deciding whether to skip the memcg or not because it is protected. If the stale value happens to be high enough, we don't reclaim from the target memcg. Essentially, in some cases we may falsely skip reclaiming from the target memcg of reclaim because we read a stale protection value from last time we reclaimed from it. During reclaim, mem_cgroup_calculate_protection() is used to determine the effective protection (emin and elow) values of a memcg. The protection of the reclaim target is ignored, but we cannot set their effective protection to 0 due to a limitation of the current implementation (see comment in mem_cgroup_protection()). Instead, we leave their effective protection values unchaged, and later ignore it in mem_cgroup_protection(). However, mem_cgroup_protection() is called later in shrink_lruvec()->get_scan_count(), which is after the mem_cgroup_below_{min/low}() checks in shrink_node_memcgs(). As a result, the stale effective protection values of the target memcg may lead us to skip reclaiming from the target memcg entirely, before calling shrink_lruvec(). This can be even worse with recursive protection, where the stale target memcg protection can be higher than its standalone protection. See two examples below (a similar version of example (a) is added to test_memcontrol in a later patch). (a) A simple example with proactive reclaim is as follows. Consider the following hierarchy: ROOT | A | B (memory.min = 10M) Consider the following scenario: - B has memory.current = 10M. - The system undergoes global reclaim (or memcg reclaim in A). - In shrink_node_memcgs(): - mem_cgroup_calculate_protection() calculates the effective min (emin) of B as 10M. - mem_cgroup_below_min() returns true for B, we do not reclaim from B. - Now if we want to reclaim 5M from B using proactive reclaim (memory.reclaim), we should be able to, as the protection of the target memcg should be ignored. - In shrink_node_memcgs(): - mem_cgroup_calculate_protection() immediately returns for B without doing anything, as B is the target memcg, relying on mem_cgroup_protection() to ignore B's stale effective min (still 10M). - mem_cgroup_below_min() reads the stale effective min for B and we skip it instead of ignoring its protection as intended, as we never reach mem_cgroup_protection(). (b) An more complex example with recursive protection is as follows. Consider the following hierarchy with memory_recursiveprot: ROOT | A (memory.min = 50M) | B (memory.min = 10M, memory.high = 40M) Consider the following scenario: - B has memory.current = 35M. - The system undergoes global reclaim (target memcg is NULL). - B will have an effective min of 50M (all of A's unclaimed protection). - B will not be reclaimed from. - Now allocate 10M more memory in B, pushing it above it's high limit. - The system undergoes memcg reclaim from B (target memcg is B). - Like example (a), we do nothing in mem_cgroup_calculate_protection(), then call mem_cgroup_below_min(), which will read the stale effective min for B (50M) and skip it. In this case, it's even worse because we are not just considering B's standalone protection (10M), but we are reading a much higher stale protection (50M) which will cause us to not reclaim from B at all. This is an artifact of commit 45c7f7e1ef17 ("mm, memcg: decouple e{low,min} state mutations from protection checks") which made mem_cgroup_calculate_protection() only change the state without returning any value. Before that commit, we used to return MEMCG_PROT_NONE for the target memcg, which would cause us to skip the mem_cgroup_below_{min/low}() checks. After that commit we do not return anything and we end up checking the min & low effective protections for the target memcg, which are stale. Update mem_cgroup_supports_protection() to also check if we are reclaiming from the target, and rename it to mem_cgroup_unprotected() (now returns true if we should not protect the memcg, much simpler logic). Link: https://lkml.kernel.org/r/20221202031512.1365483-1-yosryahmed@google.com Link: https://lkml.kernel.org/r/20221202031512.1365483-2-yosryahmed@google.com Fixes: 45c7f7e1ef17 ("mm, memcg: decouple e{low,min} state mutations from protection checks") Signed-off-by: Yosry Ahmed <yosryahmed(a)google.com> Reviewed-by: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: Chris Down <chris(a)chrisdown.name> Cc: David Rientjes <rientjes(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Muchun Song <songmuchun(a)bytedance.com> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: Tejun Heo <tj(a)kernel.org> Cc: Vasily Averin <vasily.averin(a)linux.dev> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Yu Zhao <yuzhao(a)google.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Conflicts: mm/vmscan.c Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- include/linux/memcontrol.h | 31 +++++++++++++++++++++---------- mm/vmscan.c | 4 ++-- 2 files changed, 23 insertions(+), 12 deletions(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 24794b56eaaf..287c54141a90 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -769,28 +769,32 @@ static inline void mem_cgroup_protection(struct mem_cgroup *root, void mem_cgroup_calculate_protection(struct mem_cgroup *root, struct mem_cgroup *memcg); -static inline bool mem_cgroup_supports_protection(struct mem_cgroup *memcg) +static inline bool mem_cgroup_unprotected(struct mem_cgroup *target, + struct mem_cgroup *memcg) { /* * The root memcg doesn't account charges, and doesn't support - * protection. + * protection. The target memcg's protection is ignored, see + * mem_cgroup_calculate_protection() and mem_cgroup_protection() */ - return !mem_cgroup_disabled() && !mem_cgroup_is_root(memcg); - + return mem_cgroup_disabled() || mem_cgroup_is_root(memcg) || + memcg == target; } -static inline bool mem_cgroup_below_low(struct mem_cgroup *memcg) +static inline bool mem_cgroup_below_low(struct mem_cgroup *target, + struct mem_cgroup *memcg) { - if (!mem_cgroup_supports_protection(memcg)) + if (mem_cgroup_unprotected(target, memcg)) return false; return READ_ONCE(memcg->memory.elow) >= page_counter_read(&memcg->memory); } -static inline bool mem_cgroup_below_min(struct mem_cgroup *memcg) +static inline bool mem_cgroup_below_min(struct mem_cgroup *target, + struct mem_cgroup *memcg) { - if (!mem_cgroup_supports_protection(memcg)) + if (mem_cgroup_unprotected(target, memcg)) return false; return READ_ONCE(memcg->memory.emin) >= @@ -1378,12 +1382,19 @@ static inline void mem_cgroup_calculate_protection(struct mem_cgroup *root, { } -static inline bool mem_cgroup_below_low(struct mem_cgroup *memcg) +static inline bool mem_cgroup_unprotected(struct mem_cgroup *target, + struct mem_cgroup *memcg) +{ + return true; +} +static inline bool mem_cgroup_below_low(struct mem_cgroup *target, + struct mem_cgroup *memcg) { return false; } -static inline bool mem_cgroup_below_min(struct mem_cgroup *memcg) +static inline bool mem_cgroup_below_min(struct mem_cgroup *target, + struct mem_cgroup *memcg) { return false; } diff --git a/mm/vmscan.c b/mm/vmscan.c index 3d383c7126e3..044bf496885b 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2860,13 +2860,13 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc) mem_cgroup_calculate_protection(target_memcg, memcg); - if (mem_cgroup_below_min(memcg)) { + if (mem_cgroup_below_min(target_memcg, memcg)) { /* * Hard protection. * If there is no reclaimable memory, OOM. */ continue; - } else if (mem_cgroup_below_low(memcg)) { + } else if (mem_cgroup_below_low(target_memcg, memcg)) { /* * Soft protection. * Respect the protection only as long as -- 2.34.1

1 0

[PATCH OLK-5.10 0/5] bugfix patches from mainline
by Xiongfeng Wang 06 May '24

06 May '24

Frederic Weisbecker (2): posix-cpu-timers: Force next expiration recalc after itimer reset posix-cpu-timers: Prevent spuriously armed 0-value itimer Jiri Slaby (1): x86/vdso: Use proper modifier for len's format specifier in extract() Rafael J. Wysocki (2): PM: runtime: Simplify locking in pm_runtime_put_suppliers() PM: runtime: Fix supplier device management during consumer probe arch/x86/entry/vdso/vdso2c.h | 2 +- drivers/base/core.c | 10 ++++++++++ drivers/base/power/runtime.c | 10 +--------- kernel/time/posix-cpu-timers.c | 5 ++--- 4 files changed, 14 insertions(+), 13 deletions(-) -- 2.20.1

2 6

[PATCH openEuler-1.0-LTS] drivers: base: transport_class: fix resource leak when transport_add_device() fails
by dinglongwei 06 May '24

06 May '24

From: Yang Yingliang <yangyingliang(a)huawei.com> mainline inclusion from mainline-v6.3-rc1 commit e5da06b27ff5a148e42265c8e306670a9d913969 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9MMNG Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The normal call sequence of using transport class is: Add path: transport_setup_device() transport_setup_classdev() // call sas_host_setup() here transport_add_device() // if fails, need call transport_destroy_device() transport_configure_device() Remove path: transport_remove_device() transport_remove_classdev // call sas_host_remove() here transport_destroy_device() If transport_add_device() fails, need call transport_destroy_device() to free memory, but in this case, ->remove() is not called, and the resources allocated in ->setup() are leaked. So fix these leaks by calling ->remove() in transport_add_class_device() if it returns error. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Link: https://lore.kernel.org/r/20221115031638.3816551-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- drivers/base/transport_class.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/base/transport_class.c b/drivers/base/transport_class.c index 5ed86ded6e6b..4c75dce60551 100644 --- a/drivers/base/transport_class.c +++ b/drivers/base/transport_class.c @@ -151,12 +151,27 @@ static int transport_add_class_device(struct attribute_container *cont, struct device *dev, struct device *classdev) { + struct transport_class *tclass = class_to_transport_class(cont->class); int error = attribute_container_add_class_device(classdev); struct transport_container *tcont = attribute_container_to_transport_container(cont); - if (!error && tcont->statistics) + if (error) + goto err_remove; + + if (tcont->statistics) { error = sysfs_create_group(&classdev->kobj, tcont->statistics); + if (error) + goto err_del; + } + + return 0; + +err_del: + attribute_container_class_device_del(classdev); +err_remove: + if (tclass->remove) + tclass->remove(tcont, dev, classdev); return error; } -- 2.17.1

2 1

[PATCH OLK-5.10] drivers: base: transport_class: fix resource leak when transport_add_device() fails
by dinglongwei 06 May '24

06 May '24

From: Yang Yingliang <yangyingliang(a)huawei.com> mainline inclusion from mainline-v6.3-rc1 commit e5da06b27ff5a148e42265c8e306670a9d913969 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9MMNG Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- The normal call sequence of using transport class is: Add path: transport_setup_device() transport_setup_classdev() // call sas_host_setup() here transport_add_device() // if fails, need call transport_destroy_device() transport_configure_device() Remove path: transport_remove_device() transport_remove_classdev // call sas_host_remove() here transport_destroy_device() If transport_add_device() fails, need call transport_destroy_device() to free memory, but in this case, ->remove() is not called, and the resources allocated in ->setup() are leaked. So fix these leaks by calling ->remove() in transport_add_class_device() if it returns error. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> Link: https://lore.kernel.org/r/20221115031638.3816551-1-yangyingliang@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: dinglongwei <dinglongwei1(a)huawei.com> --- drivers/base/transport_class.c | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-) diff --git a/drivers/base/transport_class.c b/drivers/base/transport_class.c index ccc86206e508..09ee2a1e35bb 100644 --- a/drivers/base/transport_class.c +++ b/drivers/base/transport_class.c @@ -155,12 +155,27 @@ static int transport_add_class_device(struct attribute_container *cont, struct device *dev, struct device *classdev) { + struct transport_class *tclass = class_to_transport_class(cont->class); int error = attribute_container_add_class_device(classdev); struct transport_container *tcont = attribute_container_to_transport_container(cont); - if (!error && tcont->statistics) + if (error) + goto err_remove; + + if (tcont->statistics) { error = sysfs_create_group(&classdev->kobj, tcont->statistics); + if (error) + goto err_del; + } + + return 0; + +err_del: + attribute_container_class_device_del(classdev); +err_remove: + if (tclass->remove) + tclass->remove(tcont, dev, classdev); return error; } -- 2.17.1

2 1

[PATCH OLK-6.6 0/2] Introduce CONFIG_ARCH_CUSTOM_NUMA_DISTANCE
by Hui Tang 06 May '24

06 May '24

This patchset allow arch adjust node_relaim_distance, as follow: Hui Tang (2): arm64/numa: Support node_reclaim_distance adjust for arch config: enable COBFIG_ARCH_CUSTOM_NUMA_DISTANCE for arm64 arch/arm64/Kconfig | 13 +++++ arch/arm64/configs/openeuler_defconfig | 1 + drivers/base/arch_numa.c | 79 ++++++++++++++++++++++++++ 3 files changed, 93 insertions(+) -- 2.34.1

4 7

[PATCH OLK-5.10] memcg: fix possible use-after-free in memcg_write_event_control()
by Cai Xinchen 06 May '24

06 May '24

From: Tejun Heo <tj(a)kernel.org> stable inclusion from stable-v5.10.159 commit f1f7f36cf682fa59db15e2089039a2eeb58ff2ad category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I7NTXH Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 4a7ba45b1a435e7097ca0f79a847d0949d0eb088 upstream. memcg_write_event_control() accesses the dentry->d_name of the specified control fd to route the write call. As a cgroup interface file can't be renamed, it's safe to access d_name as long as the specified file is a regular cgroup file. Also, as these cgroup interface files can't be removed before the directory, it's safe to access the parent too. Prior to 347c4a874710 ("memcg: remove cgroup_event->cft"), there was a call to __file_cft() which verified that the specified file is a regular cgroupfs file before further accesses. The cftype pointer returned from __file_cft() was no longer necessary and the commit inadvertently dropped the file type check with it allowing any file to slip through. With the invarients broken, the d_name and parent accesses can now race against renames and removals of arbitrary files and cause use-after-free's. Fix the bug by resurrecting the file type check in __file_cft(). Now that cgroupfs is implemented through kernfs, checking the file operations needs to go through a layer of indirection. Instead, let's check the superblock and dentry type. Link: https://lkml.kernel.org/r/Y5FRm/cfcKPGzWwl@slm.duckdns.org Fixes: 347c4a874710 ("memcg: remove cgroup_event->cft") Signed-off-by: Tejun Heo <tj(a)kernel.org> Reported-by: Jann Horn <jannh(a)google.com> Acked-by: Roman Gushchin <roman.gushchin(a)linux.dev> Acked-by: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Linus Torvalds <torvalds(a)linux-foundation.org> Cc: Michal Hocko <mhocko(a)kernel.org> Cc: Muchun Song <songmuchun(a)bytedance.com> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: <stable(a)vger.kernel.org> [3.14+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- include/linux/cgroup.h | 1 + kernel/cgroup/cgroup-internal.h | 1 - mm/memcontrol.c | 15 +++++++++++++-- 3 files changed, 14 insertions(+), 3 deletions(-) diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h index 1456b23d3ba1..b7ffef090ea7 100644 --- a/include/linux/cgroup.h +++ b/include/linux/cgroup.h @@ -68,6 +68,7 @@ struct css_task_iter { struct list_head iters_node; /* css_set->task_iters */ }; +extern struct file_system_type cgroup_fs_type; extern struct cgroup_root cgrp_dfl_root; extern struct css_set init_css_set; diff --git a/kernel/cgroup/cgroup-internal.h b/kernel/cgroup/cgroup-internal.h index 6fc71b98209e..470f196b7f74 100644 --- a/kernel/cgroup/cgroup-internal.h +++ b/kernel/cgroup/cgroup-internal.h @@ -169,7 +169,6 @@ extern struct mutex cgroup_mutex; extern spinlock_t css_set_lock; extern struct cgroup_subsys *cgroup_subsys[]; extern struct list_head cgroup_roots; -extern struct file_system_type cgroup_fs_type; /* iterate across the hierarchies */ #define for_each_root(root) \ diff --git a/mm/memcontrol.c b/mm/memcontrol.c index f5add1247f43..2aa0167863b7 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -5391,6 +5391,7 @@ static ssize_t memcg_write_event_control(struct kernfs_open_file *of, unsigned int efd, cfd; struct fd efile; struct fd cfile; + struct dentry *cdentry; const char *name; char *endp; int ret; @@ -5441,6 +5442,16 @@ static ssize_t memcg_write_event_control(struct kernfs_open_file *of, if (ret < 0) goto out_put_cfile; + /* + * The control file must be a regular cgroup1 file. As a regular cgroup + * file can't be renamed, it's safe to access its name afterwards. + */ + cdentry = cfile.file->f_path.dentry; + if (cdentry->d_sb->s_type != &cgroup_fs_type || !d_is_reg(cdentry)) { + ret = -EINVAL; + goto out_put_cfile; + } + /* * Determine the event callbacks and set them in @event. This used * to be done via struct cftype but cgroup core no longer knows @@ -5449,7 +5460,7 @@ static ssize_t memcg_write_event_control(struct kernfs_open_file *of, * * DO NOT ADD NEW FILES. */ - name = cfile.file->f_path.dentry->d_name.name; + name = cdentry->d_name.name; if (!strcmp(name, "memory.usage_in_bytes")) { event->register_event = mem_cgroup_usage_register_event; @@ -5473,7 +5484,7 @@ static ssize_t memcg_write_event_control(struct kernfs_open_file *of, * automatically removed on cgroup destruction but the removal is * asynchronous, so take an extra ref on @css. */ - cfile_css = css_tryget_online_from_dir(cfile.file->f_path.dentry->d_parent, + cfile_css = css_tryget_online_from_dir(cdentry->d_parent, &memory_cgrp_subsys); ret = -EINVAL; if (IS_ERR(cfile_css)) -- 2.34.1

2 1

[PATCH OLK-5.10 0/2] CVE-2024-26923
by Liu Jian 06 May '24

06 May '24

CVE-2024-26923 Kuniyuki Iwashima (1): af_unix: Suppress false-positive lockdep splat for spin_lock() in __unix_gc(). Michal Luczaj (1): af_unix: Fix garbage collector racing against connect() include/net/af_unix.h | 3 +++ net/unix/garbage.c | 18 +++++++++++++++++- 2 files changed, 20 insertions(+), 1 deletion(-) -- 2.34.1

2 3

[PATCH openEuler-1.0-LTS 0/2] CVE-2024-26923
by Liu Jian 06 May '24

06 May '24

CVE-2024-26923 Kuniyuki Iwashima (1): af_unix: Suppress false-positive lockdep splat for spin_lock() in __unix_gc(). Michal Luczaj (1): af_unix: Fix garbage collector racing against connect() include/net/af_unix.h | 3 +++ net/unix/garbage.c | 18 +++++++++++++++++- 2 files changed, 20 insertions(+), 1 deletion(-) -- 2.34.1

2 3

[rdma-core-2403 v2 28/29] libhns: Fix missing flexible WQE buffer page flag
by Chengchang Tang 06 May '24

06 May '24

driver inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I98HIN -------------------------------------------------------------------------- Due to the lack of this flag, this feature cannot actually take effect. Fixes: bf57963e729c ("libhns: Support flexible WQE buffer page size") Signed-off-by: Chengchang Tang <tangchengchang(a)huawei.com> --- providers/hns/hns_roce_u.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/providers/hns/hns_roce_u.c b/providers/hns/hns_roce_u.c index 7a3d1a2..c4a3ba5 100644 --- a/providers/hns/hns_roce_u.c +++ b/providers/hns/hns_roce_u.c @@ -342,7 +342,7 @@ static void ucontext_set_cmd(struct hns_roce_alloc_ucontext *cmd, struct hnsdv_context_attr *attr) { cmd->config |= HNS_ROCE_EXSGE_FLAGS | HNS_ROCE_RQ_INLINE_FLAGS | - HNS_ROCE_CQE_INLINE_FLAGS; + HNS_ROCE_CQE_INLINE_FLAGS | HNS_ROCE_UCTX_DYN_QP_PGSZ; if (!attr || !(attr->flags & HNSDV_CONTEXT_FLAGS_DCA)) return; -- 2.33.0

1 1

[PATCH OLK-6.6 0/2] Introduce CONFIG_ARCH_CUSTOM_NUMA_DISTANCE
by Hui Tang 06 May '24

06 May '24

This patchset allow arch adjust node_relaim_distance, as follow: Hui Tang (2): arm64/numa: Support node_reclaim_distance adjust for arch config: enable COBFIG_ARCH_CUSTOM_NUMA_DISTANCE for arm64 arch/arm64/Kconfig | 13 +++++ arch/arm64/configs/openeuler_defconfig | 1 + drivers/base/arch_numa.c | 79 ++++++++++++++++++++++++++ 3 files changed, 93 insertions(+) -- 2.34.1

2 3

[PATCH OLK-6.6 0/2] block: fix discard ioctl
by Li Nan 06 May '24

06 May '24

Li Nan (2): block: fix overflow in blk_ioctl_discard() block: check io size before submit discard block/blk-lib.c | 8 ++++++++ block/ioctl.c | 5 +++-- 2 files changed, 11 insertions(+), 2 deletions(-) -- 2.39.2

2 3

[PATCH openEuler-1.0-LTS] scsi: target: core: Add TMF to tmr_list handling
by Cui GaoSheng 06 May '24

06 May '24

From: Dmitry Bogdanov <d.bogdanov(a)yadro.com> stable inclusion from stable-v4.19.308 commit 425a571a7e6fc389954cf2564e1edbba3740e171 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HJQC CVE: CVE-2024-26845 -------------------------------- [ Upstream commit 83ab68168a3d990d5ff39ab030ad5754cbbccb25 ] An abort that is responded to by iSCSI itself is added to tmr_list but does not go to target core. A LUN_RESET that goes through tmr_list takes a refcounter on the abort and waits for completion. However, the abort will be never complete because it was not started in target core. Unable to locate ITT: 0x05000000 on CID: 0 Unable to locate RefTaskTag: 0x05000000 on CID: 0. wait_for_tasks: Stopping tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop wait for tasks: tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop ... INFO: task kworker/0:2:49 blocked for more than 491 seconds. task:kworker/0:2 state:D stack: 0 pid: 49 ppid: 2 flags:0x00000800 Workqueue: events target_tmr_work [target_core_mod] Call Trace: __switch_to+0x2c4/0x470 _schedule+0x314/0x1730 schedule+0x64/0x130 schedule_timeout+0x168/0x430 wait_for_completion+0x140/0x270 target_put_cmd_and_wait+0x64/0xb0 [target_core_mod] core_tmr_lun_reset+0x30/0xa0 [target_core_mod] target_tmr_work+0xc8/0x1b0 [target_core_mod] process_one_work+0x2d4/0x5d0 worker_thread+0x78/0x6c0 To fix this, only add abort to tmr_list if it will be handled by target core. Signed-off-by: Dmitry Bogdanov <d.bogdanov(a)yadro.com> Link: https://lore.kernel.org/r/20240111125941.8688-1-d.bogdanov@yadro.com Reviewed-by: Mike Christie <michael.christie(a)oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Cui GaoSheng <cuigaosheng1(a)huawei.com> --- drivers/target/target_core_device.c | 5 ----- drivers/target/target_core_transport.c | 4 ++++ 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c index e9ff2a7c0c0e..f990aae1d621 100644 --- a/drivers/target/target_core_device.c +++ b/drivers/target/target_core_device.c @@ -164,7 +164,6 @@ int transport_lookup_tmr_lun(struct se_cmd *se_cmd, u64 unpacked_lun) struct se_session *se_sess = se_cmd->se_sess; struct se_node_acl *nacl = se_sess->se_node_acl; struct se_tmr_req *se_tmr = se_cmd->se_tmr_req; - unsigned long flags; rcu_read_lock(); deve = target_nacl_find_deve(nacl, unpacked_lun); @@ -195,10 +194,6 @@ int transport_lookup_tmr_lun(struct se_cmd *se_cmd, u64 unpacked_lun) se_cmd->se_dev = rcu_dereference_raw(se_lun->lun_se_dev); se_tmr->tmr_dev = rcu_dereference_raw(se_lun->lun_se_dev); - spin_lock_irqsave(&se_tmr->tmr_dev->se_tmr_lock, flags); - list_add_tail(&se_tmr->tmr_list, &se_tmr->tmr_dev->dev_tmr_list); - spin_unlock_irqrestore(&se_tmr->tmr_dev->se_tmr_lock, flags); - return 0; } EXPORT_SYMBOL(transport_lookup_tmr_lun); diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c index 9c60a090cfd1..7bd863e2c05b 100644 --- a/drivers/target/target_core_transport.c +++ b/drivers/target/target_core_transport.c @@ -3431,6 +3431,10 @@ int transport_generic_handle_tmr( unsigned long flags; bool aborted = false; + spin_lock_irqsave(&cmd->se_dev->se_tmr_lock, flags); + list_add_tail(&cmd->se_tmr_req->tmr_list, &cmd->se_dev->dev_tmr_list); + spin_unlock_irqrestore(&cmd->se_dev->se_tmr_lock, flags); + spin_lock_irqsave(&cmd->t_state_lock, flags); if (cmd->transport_state & CMD_T_ABORTED) { aborted = true; -- 2.34.1

2 1

[PATCH OLK-5.10] x86,static_call: Fix __static_call_return0 for i386
by Yang Yingliang 06 May '24

06 May '24

From: Peter Zijlstra <peterz(a)infradead.org> mainline inclusion from mainline-v5.18-rc2 commit 1cd5f059d956e6f614ba6666ecdbcf95db05d5f5 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9JNPZ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Paolo reported that the instruction sequence that is used to replace: call __static_call_return0 namely: 66 66 48 31 c0 data16 data16 xor %rax,%rax decodes to something else on i386, namely: 66 66 48 data16 dec %ax 31 c0 xor %eax,%eax Which is a nonsensical sequence that happens to have the same outcome. *However* an important distinction is that it consists of 2 instructions which is a problem when the thing needs to be overwriten with a regular call instruction again. As such, replace the instruction with something that decodes the same on both i386 and x86_64. Fixes: 3f2a8fc4b15d ("static_call/x86: Add __static_call_return0()") Reported-by: Paolo Bonzini <pbonzini(a)redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz(a)infradead.org> Link: https://lkml.kernel.org/r/20220318204419.GT8939@worktop.programming.kicks-a… Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- arch/x86/kernel/static_call.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c index 094fa18ec9a7..a5a4a4e61b42 100644 --- a/arch/x86/kernel/static_call.c +++ b/arch/x86/kernel/static_call.c @@ -12,10 +12,9 @@ enum insn_type { }; /* - * data16 data16 xorq %rax, %rax - a single 5 byte instruction that clears %rax - * The REX.W cancels the effect of any data16. + * cs cs cs xorl %eax, %eax - a single 5 byte instruction that clears %[er]ax */ -static const u8 xor5rax[] = { 0x66, 0x66, 0x48, 0x31, 0xc0 }; +static const u8 xor5rax[] = { 0x2e, 0x2e, 0x2e, 0x31, 0xc0 }; /* * ud1 %esp, %ecx - a 3 byte #UD that is unique to trampolines, chosen such -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS,v2] scsi: target: core: Add TMF to tmr_list handling
by Cui GaoSheng 06 May '24

06 May '24

From: Dmitry Bogdanov <d.bogdanov(a)yadro.com> stable inclusion from stable-v4.19.308 commit 425a571a7e6fc389954cf2564e1edbba3740e171 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HJQC CVE: CVE-2024-26845 -------------------------------- [ Upstream commit 83ab68168a3d990d5ff39ab030ad5754cbbccb25 ] An abort that is responded to by iSCSI itself is added to tmr_list but does not go to target core. A LUN_RESET that goes through tmr_list takes a refcounter on the abort and waits for completion. However, the abort will be never complete because it was not started in target core. Unable to locate ITT: 0x05000000 on CID: 0 Unable to locate RefTaskTag: 0x05000000 on CID: 0. wait_for_tasks: Stopping tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop wait for tasks: tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop ... INFO: task kworker/0:2:49 blocked for more than 491 seconds. task:kworker/0:2 state:D stack: 0 pid: 49 ppid: 2 flags:0x00000800 Workqueue: events target_tmr_work [target_core_mod] Call Trace: __switch_to+0x2c4/0x470 _schedule+0x314/0x1730 schedule+0x64/0x130 schedule_timeout+0x168/0x430 wait_for_completion+0x140/0x270 target_put_cmd_and_wait+0x64/0xb0 [target_core_mod] core_tmr_lun_reset+0x30/0xa0 [target_core_mod] target_tmr_work+0xc8/0x1b0 [target_core_mod] process_one_work+0x2d4/0x5d0 worker_thread+0x78/0x6c0 To fix this, only add abort to tmr_list if it will be handled by target core. Signed-off-by: Dmitry Bogdanov <d.bogdanov(a)yadro.com> Link: https://lore.kernel.org/r/20240111125941.8688-1-d.bogdanov@yadro.com Reviewed-by: Mike Christie <michael.christie(a)oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Cui GaoSheng <cuigaosheng1(a)huawei.com> --- drivers/target/target_core_device.c | 5 ----- drivers/target/target_core_transport.c | 4 ++++ 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c index e9ff2a7c0c0e..f990aae1d621 100644 --- a/drivers/target/target_core_device.c +++ b/drivers/target/target_core_device.c @@ -164,7 +164,6 @@ int transport_lookup_tmr_lun(struct se_cmd *se_cmd, u64 unpacked_lun) struct se_session *se_sess = se_cmd->se_sess; struct se_node_acl *nacl = se_sess->se_node_acl; struct se_tmr_req *se_tmr = se_cmd->se_tmr_req; - unsigned long flags; rcu_read_lock(); deve = target_nacl_find_deve(nacl, unpacked_lun); @@ -195,10 +194,6 @@ int transport_lookup_tmr_lun(struct se_cmd *se_cmd, u64 unpacked_lun) se_cmd->se_dev = rcu_dereference_raw(se_lun->lun_se_dev); se_tmr->tmr_dev = rcu_dereference_raw(se_lun->lun_se_dev); - spin_lock_irqsave(&se_tmr->tmr_dev->se_tmr_lock, flags); - list_add_tail(&se_tmr->tmr_list, &se_tmr->tmr_dev->dev_tmr_list); - spin_unlock_irqrestore(&se_tmr->tmr_dev->se_tmr_lock, flags); - return 0; } EXPORT_SYMBOL(transport_lookup_tmr_lun); diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c index 9c60a090cfd1..7bd863e2c05b 100644 --- a/drivers/target/target_core_transport.c +++ b/drivers/target/target_core_transport.c @@ -3431,6 +3431,10 @@ int transport_generic_handle_tmr( unsigned long flags; bool aborted = false; + spin_lock_irqsave(&cmd->se_dev->se_tmr_lock, flags); + list_add_tail(&cmd->se_tmr_req->tmr_list, &cmd->se_dev->dev_tmr_list); + spin_unlock_irqrestore(&cmd->se_dev->se_tmr_lock, flags); + spin_lock_irqsave(&cmd->t_state_lock, flags); if (cmd->transport_state & CMD_T_ABORTED) { aborted = true; -- 2.34.1

1 0

[PATCH OLK-5.10 0/2] block: fix discard
by Li Nan 06 May '24

06 May '24

Li Nan (2): block: fix overflow in blk_ioctl_discard() block: check io size before submit discard block/blk-lib.c | 8 ++++++++ block/ioctl.c | 5 +++-- 2 files changed, 11 insertions(+), 2 deletions(-) -- 2.39.2

2 3

[PATCH openEuler-1.0-LTS] block: fix overflow in blk_ioctl_discard()
by Li Nan 06 May '24

06 May '24

mainline inclusion from mainline-v6.9-rc3 commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 category: bugfix bugzilla: 189755, https://gitee.com/openeuler/kernel/issues/I9K0H3 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- There is no check for overflow of 'start + len' in blk_ioctl_discard(). Hung task occurs if submit an discard ioctl with the following param: start = 0x80000000000ff000, len = 0x8000000000fff000; Add the overflow validation now. Signed-off-by: Li Nan <linan122(a)huawei.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Link: https://lore.kernel.org/r/20240329012319.2034550-1-linan666@huaweicloud.com Signed-off-by: Jens Axboe <axboe(a)kernel.dk> Conflict: block/ioctl.c Signed-off-by: Li Nan <linan122(a)huawei.com> --- block/ioctl.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/block/ioctl.c b/block/ioctl.c index 1d2b7f701288..1fdf496d7717 100644 --- a/block/ioctl.c +++ b/block/ioctl.c @@ -122,7 +122,7 @@ static int blk_ioctl_discard(struct block_device *bdev, fmode_t mode, unsigned long arg, unsigned long flags) { uint64_t range[2]; - uint64_t start, len; + uint64_t start, len, end; struct request_queue *q = bdev_get_queue(bdev); int err; @@ -143,7 +143,8 @@ static int blk_ioctl_discard(struct block_device *bdev, fmode_t mode, if (len & 511) return -EINVAL; - if (start + len > i_size_read(bdev->bd_inode)) + if (check_add_overflow(start, len, &end) || + end > i_size_read(bdev->bd_inode)) return -EINVAL; err = truncate_bdev_range(bdev, mode, start, start + len - 1); -- 2.39.2

2 1

[PATCH OLK-5.10] rtmutex: Add acquire semantics for rtmutex lock acquisition slow path
by Yang Yingliang 06 May '24

06 May '24

From: Mel Gorman <mgorman(a)techsingularity.net> mainline inclusion from mainline-v6.2-rc2 commit 1c0908d8e441631f5b8ba433523cf39339ee2ba0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9JNPZ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Jan Kara reported the following bug triggering on 6.0.5-rt14 running dbench on XFS on arm64. kernel BUG at fs/inode.c:625! Internal error: Oops - BUG: 0 [#1] PREEMPT_RT SMP CPU: 11 PID: 6611 Comm: dbench Tainted: G E 6.0.0-rt14-rt+ #1 pc : clear_inode+0xa0/0xc0 lr : clear_inode+0x38/0xc0 Call trace: clear_inode+0xa0/0xc0 evict+0x160/0x180 iput+0x154/0x240 do_unlinkat+0x184/0x300 __arm64_sys_unlinkat+0x48/0xc0 el0_svc_common.constprop.4+0xe4/0x2c0 do_el0_svc+0xac/0x100 el0_svc+0x78/0x200 el0t_64_sync_handler+0x9c/0xc0 el0t_64_sync+0x19c/0x1a0 It also affects 6.1-rc7-rt5 and affects a preempt-rt fork of 5.14 so this is likely a bug that existed forever and only became visible when ARM support was added to preempt-rt. The same problem does not occur on x86-64 and he also reported that converting sb->s_inode_wblist_lock to raw_spinlock_t makes the problem disappear indicating that the RT spinlock variant is the problem. Which in turn means that RT mutexes on ARM64 and any other weakly ordered architecture are affected by this independent of RT. Will Deacon observed: "I'd be more inclined to be suspicious of the slowpath tbh, as we need to make sure that we have acquire semantics on all paths where the lock can be taken. Looking at the rtmutex code, this really isn't obvious to me -- for example, try_to_take_rt_mutex() appears to be able to return via the 'takeit' label without acquire semantics and it looks like we might be relying on the caller's subsequent _unlock_ of the wait_lock for ordering, but that will give us release semantics which aren't correct." Sebastian Andrzej Siewior prototyped a fix that does work based on that comment but it was a little bit overkill and added some fences that should not be necessary. The lock owner is updated with an IRQ-safe raw spinlock held, but the spin_unlock does not provide acquire semantics which are needed when acquiring a mutex. Adds the necessary acquire semantics for lock owner updates in the slow path acquisition and the waiter bit logic. It successfully completed 10 iterations of the dbench workload while the vanilla kernel fails on the first iteration. [ bigeasy(a)linutronix.de: Initial prototype fix ] Fixes: 700318d1d7b38 ("locking/rtmutex: Use acquire/release semantics") Fixes: 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core") Reported-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Mel Gorman <mgorman(a)techsingularity.net> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20221202100223.6mevpbl7i6x5udfd@techsingularity.n… Conflicts: kernel/locking/rtmutex.c kernel/locking/rtmutex_api.c [yyl: adjust context] Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- kernel/locking/rtmutex.c | 58 ++++++++++++++++++++++++++++++++-------- 1 file changed, 47 insertions(+), 11 deletions(-) diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index a82d1176e7c6..9d24d2263a86 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -49,15 +49,31 @@ * set this bit before looking at the lock. */ -static void -rt_mutex_set_owner(struct rt_mutex *lock, struct task_struct *owner) +static struct task_struct * +rt_mutex_owner_encode(struct rt_mutex *lock, struct task_struct *owner) { unsigned long val = (unsigned long)owner; if (rt_mutex_has_waiters(lock)) val |= RT_MUTEX_HAS_WAITERS; - WRITE_ONCE(lock->owner, (struct task_struct *)val); + return (struct task_struct *)val; +} + +static void +rt_mutex_set_owner(struct rt_mutex *lock, struct task_struct *owner) +{ + /* + * lock->wait_lock is held but explicit acquire semantics are needed + * for a new lock owner so WRITE_ONCE is insufficient. + */ + xchg_acquire(&lock->owner, rt_mutex_owner_encode(lock, owner)); +} + +static void rt_mutex_clear_owner(struct rt_mutex *lock) +{ + /* lock->wait_lock is held so the unlock provides release semantics. */ + WRITE_ONCE(lock->owner, rt_mutex_owner_encode(lock, NULL)); } static inline void clear_rt_mutex_waiters(struct rt_mutex *lock) @@ -66,7 +82,7 @@ static inline void clear_rt_mutex_waiters(struct rt_mutex *lock) ((unsigned long)lock->owner & ~RT_MUTEX_HAS_WAITERS); } -static void fixup_rt_mutex_waiters(struct rt_mutex *lock) +static void fixup_rt_mutex_waiters(struct rt_mutex *lock, bool acquire_lock) { unsigned long owner, *p = (unsigned long *) &lock->owner; @@ -132,8 +148,21 @@ static void fixup_rt_mutex_waiters(struct rt_mutex *lock) * still set. */ owner = READ_ONCE(*p); - if (owner & RT_MUTEX_HAS_WAITERS) - WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); + if (owner & RT_MUTEX_HAS_WAITERS) { + /* + * See rt_mutex_set_owner() and rt_mutex_clear_owner() on + * why xchg_acquire() is used for updating owner for + * locking and WRITE_ONCE() for unlocking. + * + * WRITE_ONCE() would work for the acquire case too, but + * in case that the lock acquisition failed it might + * force other lockers into the slow path unnecessarily. + */ + if (acquire_lock) + xchg_acquire(p, owner & ~RT_MUTEX_HAS_WAITERS); + else + WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); + } } /* @@ -157,6 +186,13 @@ static inline void mark_rt_mutex_waiters(struct rt_mutex *lock) owner = *p; } while (cmpxchg_relaxed(p, owner, owner | RT_MUTEX_HAS_WAITERS) != owner); + + /* + * The cmpxchg loop above is relaxed to avoid back-to-back ACQUIRE + * operations in the event of contention. Ensure the successful + * cmpxchg is visible. + */ + smp_mb__after_atomic(); } /* @@ -1255,7 +1291,7 @@ rt_mutex_slowlock(struct rt_mutex *lock, int state, * try_to_take_rt_mutex() sets the waiter bit * unconditionally. We might have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); raw_spin_unlock_irqrestore(&lock->wait_lock, flags); @@ -1276,7 +1312,7 @@ static inline int __rt_mutex_slowtrylock(struct rt_mutex *lock) * try_to_take_rt_mutex() sets the lock waiters bit * unconditionally. Clean this up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); return ret; } @@ -1701,7 +1737,7 @@ void rt_mutex_init_proxy_locked(struct rt_mutex *lock, void rt_mutex_proxy_unlock(struct rt_mutex *lock) { debug_rt_mutex_proxy_unlock(lock); - rt_mutex_set_owner(lock, NULL); + rt_mutex_clear_owner(lock); } /** @@ -1838,7 +1874,7 @@ int rt_mutex_wait_proxy_lock(struct rt_mutex *lock, * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might * have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); raw_spin_unlock_irq(&lock->wait_lock); return ret; @@ -1894,7 +1930,7 @@ bool rt_mutex_cleanup_proxy_lock(struct rt_mutex *lock, * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might * have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, false); raw_spin_unlock_irq(&lock->wait_lock); -- 2.25.1

2 1

[PATCH OLK-5.10] media: ir_toy: fix a memleak in irtoy_tx
by Cui GaoSheng 06 May '24

06 May '24

From: Zhipeng Lu <alexious(a)zju.edu.cn> stable inclusion from stable-v5.10.210 commit 486a4176bc783df798bce2903824801af8d2c3ae category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HJP4 CVE: CVE-2024-26829 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit dc9ceb90c4b42c6e5c6757df1d6257110433788e ] When irtoy_command fails, buf should be freed since it is allocated by irtoy_tx, or there is a memleak. Fixes: 4114978dcd24 ("media: ir_toy: prevent device from hanging during transmit") Signed-off-by: Zhipeng Lu <alexious(a)zju.edu.cn> Signed-off-by: Sean Young <sean(a)mess.org> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)kernel.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Lin Yujun <linyujun809(a)huawei.com> Signed-off-by: Cui GaoSheng <cuigaosheng1(a)huawei.com> --- drivers/media/rc/ir_toy.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/rc/ir_toy.c b/drivers/media/rc/ir_toy.c index 7f394277478b..cd2fddf003bd 100644 --- a/drivers/media/rc/ir_toy.c +++ b/drivers/media/rc/ir_toy.c @@ -324,6 +324,7 @@ static int irtoy_tx(struct rc_dev *rc, uint *txbuf, uint count) sizeof(COMMAND_SMODE_EXIT), STATE_RESET); if (err) { dev_err(irtoy->dev, "exit sample mode: %d\n", err); + kfree(buf); return err; } @@ -331,6 +332,7 @@ static int irtoy_tx(struct rc_dev *rc, uint *txbuf, uint count) sizeof(COMMAND_SMODE_ENTER), STATE_COMMAND); if (err) { dev_err(irtoy->dev, "enter sample mode: %d\n", err); + kfree(buf); return err; } -- 2.34.1

2 1

[PATCH OLK-5.10] scsi: target: core: Add TMF to tmr_list handling
by Cui GaoSheng 06 May '24

06 May '24

From: Dmitry Bogdanov <d.bogdanov(a)yadro.com> stable inclusion from stable-v5.10.211 commit 168ed59170de1fd7274080fe102216162d6826cf category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HJQC CVE: CVE-2024-26845 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 83ab68168a3d990d5ff39ab030ad5754cbbccb25 ] An abort that is responded to by iSCSI itself is added to tmr_list but does not go to target core. A LUN_RESET that goes through tmr_list takes a refcounter on the abort and waits for completion. However, the abort will be never complete because it was not started in target core. Unable to locate ITT: 0x05000000 on CID: 0 Unable to locate RefTaskTag: 0x05000000 on CID: 0. wait_for_tasks: Stopping tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop wait for tasks: tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop ... INFO: task kworker/0:2:49 blocked for more than 491 seconds. task:kworker/0:2 state:D stack: 0 pid: 49 ppid: 2 flags:0x00000800 Workqueue: events target_tmr_work [target_core_mod] Call Trace: __switch_to+0x2c4/0x470 _schedule+0x314/0x1730 schedule+0x64/0x130 schedule_timeout+0x168/0x430 wait_for_completion+0x140/0x270 target_put_cmd_and_wait+0x64/0xb0 [target_core_mod] core_tmr_lun_reset+0x30/0xa0 [target_core_mod] target_tmr_work+0xc8/0x1b0 [target_core_mod] process_one_work+0x2d4/0x5d0 worker_thread+0x78/0x6c0 To fix this, only add abort to tmr_list if it will be handled by target core. Signed-off-by: Dmitry Bogdanov <d.bogdanov(a)yadro.com> Link: https://lore.kernel.org/r/20240111125941.8688-1-d.bogdanov@yadro.com Reviewed-by: Mike Christie <michael.christie(a)oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Wang Hai <wanghai38(a)huawei.com> Signed-off-by: Cui GaoSheng <cuigaosheng1(a)huawei.com> --- drivers/target/target_core_device.c | 5 ----- drivers/target/target_core_transport.c | 4 ++++ 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c index 9aeedcff7d02..daa4d06ce233 100644 --- a/drivers/target/target_core_device.c +++ b/drivers/target/target_core_device.c @@ -150,7 +150,6 @@ int transport_lookup_tmr_lun(struct se_cmd *se_cmd) struct se_session *se_sess = se_cmd->se_sess; struct se_node_acl *nacl = se_sess->se_node_acl; struct se_tmr_req *se_tmr = se_cmd->se_tmr_req; - unsigned long flags; rcu_read_lock(); deve = target_nacl_find_deve(nacl, se_cmd->orig_fe_lun); @@ -181,10 +180,6 @@ int transport_lookup_tmr_lun(struct se_cmd *se_cmd) se_cmd->se_dev = rcu_dereference_raw(se_lun->lun_se_dev); se_tmr->tmr_dev = rcu_dereference_raw(se_lun->lun_se_dev); - spin_lock_irqsave(&se_tmr->tmr_dev->se_tmr_lock, flags); - list_add_tail(&se_tmr->tmr_list, &se_tmr->tmr_dev->dev_tmr_list); - spin_unlock_irqrestore(&se_tmr->tmr_dev->se_tmr_lock, flags); - return 0; } EXPORT_SYMBOL(transport_lookup_tmr_lun); diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c index 2e97937f005f..8d294b658592 100644 --- a/drivers/target/target_core_transport.c +++ b/drivers/target/target_core_transport.c @@ -3436,6 +3436,10 @@ int transport_generic_handle_tmr( unsigned long flags; bool aborted = false; + spin_lock_irqsave(&cmd->se_dev->se_tmr_lock, flags); + list_add_tail(&cmd->se_tmr_req->tmr_list, &cmd->se_dev->dev_tmr_list); + spin_unlock_irqrestore(&cmd->se_dev->se_tmr_lock, flags); + spin_lock_irqsave(&cmd->t_state_lock, flags); if (cmd->transport_state & CMD_T_ABORTED) { aborted = true; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS v3 0/2] CVE-2024-26846
by Li Lingfeng 06 May '24

06 May '24

v1->v2: Apply patch to remove nvme_fc_wq. v2->v3: Correct commit id. Daniel Wagner (1): nvme-fc: do not wait in vain when unloading module James Smart (1): nvme-fc: remove err_work work item drivers/nvme/host/fc.c | 87 ++++++++---------------------------------- 1 file changed, 16 insertions(+), 71 deletions(-) -- 2.31.1

2 3

[PATCH openEuler-1.0-LTS] rtmutex: Add acquire semantics for rtmutex lock acquisition slow path
by Yang Yingliang 06 May '24

06 May '24

From: "Paul E. McKenney" <paulmck(a)kernel.org> mainline inclusion from mainline-v6.2-rc2 commit 1c0908d8e441631f5b8ba433523cf39339ee2ba0 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9JNPZ Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Jan Kara reported the following bug triggering on 6.0.5-rt14 running dbench on XFS on arm64. kernel BUG at fs/inode.c:625! Internal error: Oops - BUG: 0 [#1] PREEMPT_RT SMP CPU: 11 PID: 6611 Comm: dbench Tainted: G E 6.0.0-rt14-rt+ #1 pc : clear_inode+0xa0/0xc0 lr : clear_inode+0x38/0xc0 Call trace: clear_inode+0xa0/0xc0 evict+0x160/0x180 iput+0x154/0x240 do_unlinkat+0x184/0x300 __arm64_sys_unlinkat+0x48/0xc0 el0_svc_common.constprop.4+0xe4/0x2c0 do_el0_svc+0xac/0x100 el0_svc+0x78/0x200 el0t_64_sync_handler+0x9c/0xc0 el0t_64_sync+0x19c/0x1a0 It also affects 6.1-rc7-rt5 and affects a preempt-rt fork of 5.14 so this is likely a bug that existed forever and only became visible when ARM support was added to preempt-rt. The same problem does not occur on x86-64 and he also reported that converting sb->s_inode_wblist_lock to raw_spinlock_t makes the problem disappear indicating that the RT spinlock variant is the problem. Which in turn means that RT mutexes on ARM64 and any other weakly ordered architecture are affected by this independent of RT. Will Deacon observed: "I'd be more inclined to be suspicious of the slowpath tbh, as we need to make sure that we have acquire semantics on all paths where the lock can be taken. Looking at the rtmutex code, this really isn't obvious to me -- for example, try_to_take_rt_mutex() appears to be able to return via the 'takeit' label without acquire semantics and it looks like we might be relying on the caller's subsequent _unlock_ of the wait_lock for ordering, but that will give us release semantics which aren't correct." Sebastian Andrzej Siewior prototyped a fix that does work based on that comment but it was a little bit overkill and added some fences that should not be necessary. The lock owner is updated with an IRQ-safe raw spinlock held, but the spin_unlock does not provide acquire semantics which are needed when acquiring a mutex. Adds the necessary acquire semantics for lock owner updates in the slow path acquisition and the waiter bit logic. It successfully completed 10 iterations of the dbench workload while the vanilla kernel fails on the first iteration. [ bigeasy(a)linutronix.de: Initial prototype fix ] Fixes: 700318d1d7b38 ("locking/rtmutex: Use acquire/release semantics") Fixes: 23f78d4a03c5 ("[PATCH] pi-futex: rt mutex core") Reported-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Mel Gorman <mgorman(a)techsingularity.net> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20221202100223.6mevpbl7i6x5udfd@techsingularity.n… Conflicts: kernel/locking/rtmutex.c kernel/locking/rtmutex_api.c [yyl: adjust context] Signed-off-by: Yang Yingliang <yangyingliang(a)huawei.com> --- kernel/locking/rtmutex.c | 58 ++++++++++++++++++++++++++++++++-------- 1 file changed, 47 insertions(+), 11 deletions(-) diff --git a/kernel/locking/rtmutex.c b/kernel/locking/rtmutex.c index a5ec4f68527e..861e14ce1956 100644 --- a/kernel/locking/rtmutex.c +++ b/kernel/locking/rtmutex.c @@ -48,15 +48,31 @@ * set this bit before looking at the lock. */ -static void -rt_mutex_set_owner(struct rt_mutex *lock, struct task_struct *owner) +static struct task_struct * +rt_mutex_owner_encode(struct rt_mutex *lock, struct task_struct *owner) { unsigned long val = (unsigned long)owner; if (rt_mutex_has_waiters(lock)) val |= RT_MUTEX_HAS_WAITERS; - lock->owner = (struct task_struct *)val; + return (struct task_struct *)val; +} + +static void +rt_mutex_set_owner(struct rt_mutex *lock, struct task_struct *owner) +{ + /* + * lock->wait_lock is held but explicit acquire semantics are needed + * for a new lock owner so WRITE_ONCE is insufficient. + */ + xchg_acquire(&lock->owner, rt_mutex_owner_encode(lock, owner)); +} + +static void rt_mutex_clear_owner(struct rt_mutex *lock) +{ + /* lock->wait_lock is held so the unlock provides release semantics. */ + WRITE_ONCE(lock->owner, rt_mutex_owner_encode(lock, NULL)); } static inline void clear_rt_mutex_waiters(struct rt_mutex *lock) @@ -65,7 +81,7 @@ static inline void clear_rt_mutex_waiters(struct rt_mutex *lock) ((unsigned long)lock->owner & ~RT_MUTEX_HAS_WAITERS); } -static void fixup_rt_mutex_waiters(struct rt_mutex *lock) +static void fixup_rt_mutex_waiters(struct rt_mutex *lock, bool acquire_lock) { unsigned long owner, *p = (unsigned long *) &lock->owner; @@ -131,8 +147,21 @@ static void fixup_rt_mutex_waiters(struct rt_mutex *lock) * still set. */ owner = READ_ONCE(*p); - if (owner & RT_MUTEX_HAS_WAITERS) - WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); + if (owner & RT_MUTEX_HAS_WAITERS) { + /* + * See rt_mutex_set_owner() and rt_mutex_clear_owner() on + * why xchg_acquire() is used for updating owner for + * locking and WRITE_ONCE() for unlocking. + * + * WRITE_ONCE() would work for the acquire case too, but + * in case that the lock acquisition failed it might + * force other lockers into the slow path unnecessarily. + */ + if (acquire_lock) + xchg_acquire(p, owner & ~RT_MUTEX_HAS_WAITERS); + else + WRITE_ONCE(*p, owner & ~RT_MUTEX_HAS_WAITERS); + } } /* @@ -157,6 +186,13 @@ static inline void mark_rt_mutex_waiters(struct rt_mutex *lock) owner = *p; } while (cmpxchg_relaxed(p, owner, owner | RT_MUTEX_HAS_WAITERS) != owner); + + /* + * The cmpxchg loop above is relaxed to avoid back-to-back ACQUIRE + * operations in the event of contention. Ensure the successful + * cmpxchg is visible. + */ + smp_mb__after_atomic(); } /* @@ -1276,7 +1312,7 @@ rt_mutex_slowlock(struct rt_mutex *lock, int state, * try_to_take_rt_mutex() sets the waiter bit * unconditionally. We might have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); raw_spin_unlock_irqrestore(&lock->wait_lock, flags); @@ -1297,7 +1333,7 @@ static inline int __rt_mutex_slowtrylock(struct rt_mutex *lock) * try_to_take_rt_mutex() sets the lock waiters bit * unconditionally. Clean this up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); return ret; } @@ -1722,7 +1758,7 @@ void rt_mutex_init_proxy_locked(struct rt_mutex *lock, void rt_mutex_proxy_unlock(struct rt_mutex *lock) { debug_rt_mutex_proxy_unlock(lock); - rt_mutex_set_owner(lock, NULL); + rt_mutex_clear_owner(lock); } /** @@ -1859,7 +1895,7 @@ int rt_mutex_wait_proxy_lock(struct rt_mutex *lock, * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might * have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, true); raw_spin_unlock_irq(&lock->wait_lock); return ret; @@ -1915,7 +1951,7 @@ bool rt_mutex_cleanup_proxy_lock(struct rt_mutex *lock, * try_to_take_rt_mutex() sets the waiter bit unconditionally. We might * have to fix that up. */ - fixup_rt_mutex_waiters(lock); + fixup_rt_mutex_waiters(lock, false); raw_spin_unlock_irq(&lock->wait_lock); -- 2.25.1

2 1

[PATCH openEuler-1.0-LTS] scsi: target: core: Add TMF to tmr_list handling
by Cui GaoSheng 06 May '24

06 May '24

From: Dmitry Bogdanov <d.bogdanov(a)yadro.com> stable inclusion from stable-v4.19.308 commit 425a571a7e6fc389954cf2564e1edbba3740e171 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/I9HJQC CVE: CVE-2024-26845 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit 83ab68168a3d990d5ff39ab030ad5754cbbccb25 ] An abort that is responded to by iSCSI itself is added to tmr_list but does not go to target core. A LUN_RESET that goes through tmr_list takes a refcounter on the abort and waits for completion. However, the abort will be never complete because it was not started in target core. Unable to locate ITT: 0x05000000 on CID: 0 Unable to locate RefTaskTag: 0x05000000 on CID: 0. wait_for_tasks: Stopping tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop wait for tasks: tmf LUN_RESET with tag 0x0 ref_task_tag 0x0 i_state 34 t_state ISTATE_PROCESSING refcnt 2 transport_state active,stop,fabric_stop ... INFO: task kworker/0:2:49 blocked for more than 491 seconds. task:kworker/0:2 state:D stack: 0 pid: 49 ppid: 2 flags:0x00000800 Workqueue: events target_tmr_work [target_core_mod] Call Trace: __switch_to+0x2c4/0x470 _schedule+0x314/0x1730 schedule+0x64/0x130 schedule_timeout+0x168/0x430 wait_for_completion+0x140/0x270 target_put_cmd_and_wait+0x64/0xb0 [target_core_mod] core_tmr_lun_reset+0x30/0xa0 [target_core_mod] target_tmr_work+0xc8/0x1b0 [target_core_mod] process_one_work+0x2d4/0x5d0 worker_thread+0x78/0x6c0 To fix this, only add abort to tmr_list if it will be handled by target core. Signed-off-by: Dmitry Bogdanov <d.bogdanov(a)yadro.com> Link: https://lore.kernel.org/r/20240111125941.8688-1-d.bogdanov@yadro.com Reviewed-by: Mike Christie <michael.christie(a)oracle.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Cui GaoSheng <cuigaosheng1(a)huawei.com> --- drivers/target/target_core_device.c | 5 ----- drivers/target/target_core_transport.c | 4 ++++ 2 files changed, 4 insertions(+), 5 deletions(-) diff --git a/drivers/target/target_core_device.c b/drivers/target/target_core_device.c index e9ff2a7c0c0e..f990aae1d621 100644 --- a/drivers/target/target_core_device.c +++ b/drivers/target/target_core_device.c @@ -164,7 +164,6 @@ int transport_lookup_tmr_lun(struct se_cmd *se_cmd, u64 unpacked_lun) struct se_session *se_sess = se_cmd->se_sess; struct se_node_acl *nacl = se_sess->se_node_acl; struct se_tmr_req *se_tmr = se_cmd->se_tmr_req; - unsigned long flags; rcu_read_lock(); deve = target_nacl_find_deve(nacl, unpacked_lun); @@ -195,10 +194,6 @@ int transport_lookup_tmr_lun(struct se_cmd *se_cmd, u64 unpacked_lun) se_cmd->se_dev = rcu_dereference_raw(se_lun->lun_se_dev); se_tmr->tmr_dev = rcu_dereference_raw(se_lun->lun_se_dev); - spin_lock_irqsave(&se_tmr->tmr_dev->se_tmr_lock, flags); - list_add_tail(&se_tmr->tmr_list, &se_tmr->tmr_dev->dev_tmr_list); - spin_unlock_irqrestore(&se_tmr->tmr_dev->se_tmr_lock, flags); - return 0; } EXPORT_SYMBOL(transport_lookup_tmr_lun); diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c index 9c60a090cfd1..7bd863e2c05b 100644 --- a/drivers/target/target_core_transport.c +++ b/drivers/target/target_core_transport.c @@ -3431,6 +3431,10 @@ int transport_generic_handle_tmr( unsigned long flags; bool aborted = false; + spin_lock_irqsave(&cmd->se_dev->se_tmr_lock, flags); + list_add_tail(&cmd->se_tmr_req->tmr_list, &cmd->se_dev->dev_tmr_list); + spin_unlock_irqrestore(&cmd->se_dev->se_tmr_lock, flags); + spin_lock_irqsave(&cmd->t_state_lock, flags); if (cmd->transport_state & CMD_T_ABORTED) { aborted = true; -- 2.34.1

2 1

[PATCH OLK-5.10] IB/mad: Don't call to function that might sleep while in atomic context
by Liu Chuang 06 May '24

06 May '24

From: Leonid Ravich <lravich(a)gmail.com> mainline inclusion from mainline-v6.2-rc1 commit 5c20311d76cbaeb7ed2ecf9c8b8322f8fc4a7ae3 category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9MELE Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Tracepoints are not allowed to sleep, as such the following splat is generated due to call to ib_query_pkey() in atomic context. WARNING: CPU: 0 PID: 1888000 at kernel/trace/ring_buffer.c:2492 rb_commit+0xc1/0x220 CPU: 0 PID: 1888000 Comm: kworker/u9:0 Kdump: loaded Tainted: G OE --------- - - 4.18.0-305.3.1.el8.x86_64 #1 Hardware name: Red Hat KVM, BIOS 1.13.0-2.module_el8.3.0+555+a55c8938 04/01/2014 Workqueue: ib-comp-unb-wq ib_cq_poll_work [ib_core] RIP: 0010:rb_commit+0xc1/0x220 RSP: 0000:ffffa8ac80f9bca0 EFLAGS: 00010202 RAX: ffff8951c7c01300 RBX: ffff8951c7c14a00 RCX: 0000000000000246 RDX: ffff8951c707c000 RSI: ffff8951c707c57c RDI: ffff8951c7c14a00 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff8951c7c01300 R11: 0000000000000001 R12: 0000000000000246 R13: 0000000000000000 R14: ffffffff964c70c0 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffff8951fbc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f20e8f39010 CR3: 000000002ca10005 CR4: 0000000000170ef0 Call Trace: ring_buffer_unlock_commit+0x1d/0xa0 trace_buffer_unlock_commit_regs+0x3b/0x1b0 trace_event_buffer_commit+0x67/0x1d0 trace_event_raw_event_ib_mad_recv_done_handler+0x11c/0x160 [ib_core] ib_mad_recv_done+0x48b/0xc10 [ib_core] ? trace_event_raw_event_cq_poll+0x6f/0xb0 [ib_core] __ib_process_cq+0x91/0x1c0 [ib_core] ib_cq_poll_work+0x26/0x80 [ib_core] process_one_work+0x1a7/0x360 ? create_worker+0x1a0/0x1a0 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x116/0x130 ? kthread_flush_work_fn+0x10/0x10 ret_from_fork+0x35/0x40 ---[ end trace 78ba8509d3830a16 ]--- Fixes: 821bf1de45a1 ("IB/MAD: Add recv path trace point") Signed-off-by: Leonid Ravich <lravich(a)gmail.com> Link: https://lore.kernel.org/r/Y2t5feomyznrVj7V@leonid-Inspiron-3421 Signed-off-by: Leon Romanovsky <leon(a)kernel.org> Conflicts: drivers/infiniband/core/mad.c Signed-off-by: Liu Chuang <liuchuang40(a)huawei.com> --- drivers/infiniband/core/mad.c | 5 ----- include/trace/events/ib_mad.h | 13 ++++--------- 2 files changed, 4 insertions(+), 14 deletions(-) diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c index 9355e521d9f4..ca3ef65ba66a 100644 --- a/drivers/infiniband/core/mad.c +++ b/drivers/infiniband/core/mad.c @@ -59,9 +59,6 @@ static void create_mad_addr_info(struct ib_mad_send_wr_private *mad_send_wr, struct ib_mad_qp_info *qp_info, struct trace_event_raw_ib_mad_send_template *entry) { - u16 pkey; - struct ib_device *dev = qp_info->port_priv->device; - u8 pnum = qp_info->port_priv->port_num; struct ib_ud_wr *wr = &mad_send_wr->send_wr; struct rdma_ah_attr attr = {}; @@ -69,8 +66,6 @@ static void create_mad_addr_info(struct ib_mad_send_wr_private *mad_send_wr, /* These are common */ entry->sl = attr.sl; - ib_query_pkey(dev, pnum, wr->pkey_index, &pkey); - entry->pkey = pkey; entry->rqpn = wr->remote_qpn; entry->rqkey = wr->remote_qkey; entry->dlid = rdma_ah_get_dlid(&attr); diff --git a/include/trace/events/ib_mad.h b/include/trace/events/ib_mad.h index 59363a083ecb..d92691c78cff 100644 --- a/include/trace/events/ib_mad.h +++ b/include/trace/events/ib_mad.h @@ -49,7 +49,6 @@ DECLARE_EVENT_CLASS(ib_mad_send_template, __field(int, retries_left) __field(int, max_retries) __field(int, retry) - __field(u16, pkey) ), TP_fast_assign( @@ -89,7 +88,7 @@ DECLARE_EVENT_CLASS(ib_mad_send_template, "hdr : base_ver 0x%x class 0x%x class_ver 0x%x " \ "method 0x%x status 0x%x class_specific 0x%x tid 0x%llx " \ "attr_id 0x%x attr_mod 0x%x => dlid 0x%08x sl %d "\ - "pkey 0x%x rpqn 0x%x rqpkey 0x%x", + "rpqn 0x%x rqpkey 0x%x", __entry->dev_index, __entry->port_num, __entry->qp_num, __entry->agent_priv, be64_to_cpu(__entry->wrtid), __entry->retries_left, __entry->max_retries, @@ -100,7 +99,7 @@ DECLARE_EVENT_CLASS(ib_mad_send_template, be16_to_cpu(__entry->class_specific), be64_to_cpu(__entry->tid), be16_to_cpu(__entry->attr_id), be32_to_cpu(__entry->attr_mod), - be32_to_cpu(__entry->dlid), __entry->sl, __entry->pkey, + be32_to_cpu(__entry->dlid), __entry->sl, __entry->rqpn, __entry->rqkey ) ); @@ -204,7 +203,6 @@ TRACE_EVENT(ib_mad_recv_done_handler, __field(u16, wc_status) __field(u32, slid) __field(u32, dev_index) - __field(u16, pkey) ), TP_fast_assign( @@ -224,9 +222,6 @@ TRACE_EVENT(ib_mad_recv_done_handler, __entry->slid = wc->slid; __entry->src_qp = wc->src_qp; __entry->sl = wc->sl; - ib_query_pkey(qp_info->port_priv->device, - qp_info->port_priv->port_num, - wc->pkey_index, &__entry->pkey); __entry->wc_status = wc->status; ), @@ -234,7 +229,7 @@ TRACE_EVENT(ib_mad_recv_done_handler, "base_ver 0x%02x class 0x%02x class_ver 0x%02x " \ "method 0x%02x status 0x%04x class_specific 0x%04x " \ "tid 0x%016llx attr_id 0x%04x attr_mod 0x%08x " \ - "slid 0x%08x src QP%d, sl %d pkey 0x%04x", + "slid 0x%08x src QP%d, sl %d", __entry->dev_index, __entry->port_num, __entry->qp_num, __entry->wc_status, __entry->length, @@ -244,7 +239,7 @@ TRACE_EVENT(ib_mad_recv_done_handler, be16_to_cpu(__entry->class_specific), be64_to_cpu(__entry->tid), be16_to_cpu(__entry->attr_id), be32_to_cpu(__entry->attr_mod), - __entry->slid, __entry->src_qp, __entry->sl, __entry->pkey + __entry->slid, __entry->src_qp, __entry->sl ) ); -- 2.34.1

2 1

[PATCH OLK-5.10] mm: memcg: fix stale protection of reclaim target memcg
by Cai Xinchen 06 May '24

06 May '24

From: Yosry Ahmed <yosryahmed(a)google.com> mainline inclusion from mainline-v6.2-rc1 commit adb8213014b25c7f1d75d5b219becaadcd695efb category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I9MD18 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Patch series "mm: memcg: fix protection of reclaim target memcg", v3. This series fixes a bug in calculating the protection of the reclaim target memcg where we end up using stale effective protection values from the last reclaim operation, instead of completely ignoring the protection of the reclaim target as intended. More detailed explanation and examples in patch 1, which includes the fix. Patches 2 & 3 introduce a selftest case that catches the bug. This patch (of 3): When we are doing memcg reclaim, the intended behavior is that we ignore any protection (memory.min, memory.low) of the target memcg (but not its children). Ever since the patch pointed to by the "Fixes" tag, we actually read a stale value for the target memcg protection when deciding whether to skip the memcg or not because it is protected. If the stale value happens to be high enough, we don't reclaim from the target memcg. Essentially, in some cases we may falsely skip reclaiming from the target memcg of reclaim because we read a stale protection value from last time we reclaimed from it. During reclaim, mem_cgroup_calculate_protection() is used to determine the effective protection (emin and elow) values of a memcg. The protection of the reclaim target is ignored, but we cannot set their effective protection to 0 due to a limitation of the current implementation (see comment in mem_cgroup_protection()). Instead, we leave their effective protection values unchaged, and later ignore it in mem_cgroup_protection(). However, mem_cgroup_protection() is called later in shrink_lruvec()->get_scan_count(), which is after the mem_cgroup_below_{min/low}() checks in shrink_node_memcgs(). As a result, the stale effective protection values of the target memcg may lead us to skip reclaiming from the target memcg entirely, before calling shrink_lruvec(). This can be even worse with recursive protection, where the stale target memcg protection can be higher than its standalone protection. See two examples below (a similar version of example (a) is added to test_memcontrol in a later patch). (a) A simple example with proactive reclaim is as follows. Consider the following hierarchy: ROOT | A | B (memory.min = 10M) Consider the following scenario: - B has memory.current = 10M. - The system undergoes global reclaim (or memcg reclaim in A). - In shrink_node_memcgs(): - mem_cgroup_calculate_protection() calculates the effective min (emin) of B as 10M. - mem_cgroup_below_min() returns true for B, we do not reclaim from B. - Now if we want to reclaim 5M from B using proactive reclaim (memory.reclaim), we should be able to, as the protection of the target memcg should be ignored. - In shrink_node_memcgs(): - mem_cgroup_calculate_protection() immediately returns for B without doing anything, as B is the target memcg, relying on mem_cgroup_protection() to ignore B's stale effective min (still 10M). - mem_cgroup_below_min() reads the stale effective min for B and we skip it instead of ignoring its protection as intended, as we never reach mem_cgroup_protection(). (b) An more complex example with recursive protection is as follows. Consider the following hierarchy with memory_recursiveprot: ROOT | A (memory.min = 50M) | B (memory.min = 10M, memory.high = 40M) Consider the following scenario: - B has memory.current = 35M. - The system undergoes global reclaim (target memcg is NULL). - B will have an effective min of 50M (all of A's unclaimed protection). - B will not be reclaimed from. - Now allocate 10M more memory in B, pushing it above it's high limit. - The system undergoes memcg reclaim from B (target memcg is B). - Like example (a), we do nothing in mem_cgroup_calculate_protection(), then call mem_cgroup_below_min(), which will read the stale effective min for B (50M) and skip it. In this case, it's even worse because we are not just considering B's standalone protection (10M), but we are reading a much higher stale protection (50M) which will cause us to not reclaim from B at all. This is an artifact of commit 45c7f7e1ef17 ("mm, memcg: decouple e{low,min} state mutations from protection checks") which made mem_cgroup_calculate_protection() only change the state without returning any value. Before that commit, we used to return MEMCG_PROT_NONE for the target memcg, which would cause us to skip the mem_cgroup_below_{min/low}() checks. After that commit we do not return anything and we end up checking the min & low effective protections for the target memcg, which are stale. Update mem_cgroup_supports_protection() to also check if we are reclaiming from the target, and rename it to mem_cgroup_unprotected() (now returns true if we should not protect the memcg, much simpler logic). Link: https://lkml.kernel.org/r/20221202031512.1365483-1-yosryahmed@google.com Link: https://lkml.kernel.org/r/20221202031512.1365483-2-yosryahmed@google.com Fixes: 45c7f7e1ef17 ("mm, memcg: decouple e{low,min} state mutations from protection checks") Signed-off-by: Yosry Ahmed <yosryahmed(a)google.com> Reviewed-by: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: Chris Down <chris(a)chrisdown.name> Cc: David Rientjes <rientjes(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Muchun Song <songmuchun(a)bytedance.com> Cc: Shakeel Butt <shakeelb(a)google.com> Cc: Tejun Heo <tj(a)kernel.org> Cc: Vasily Averin <vasily.averin(a)linux.dev> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Yu Zhao <yuzhao(a)google.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> conflicts: mm/vmscan.c Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> --- include/linux/memcontrol.h | 31 +++++++++++++++++++++---------- mm/vmscan.c | 4 ++-- 2 files changed, 23 insertions(+), 12 deletions(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 24794b56eaaf..287c54141a90 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -769,28 +769,32 @@ static inline void mem_cgroup_protection(struct mem_cgroup *root, void mem_cgroup_calculate_protection(struct mem_cgroup *root, struct mem_cgroup *memcg); -static inline bool mem_cgroup_supports_protection(struct mem_cgroup *memcg) +static inline bool mem_cgroup_unprotected(struct mem_cgroup *target, + struct mem_cgroup *memcg) { /* * The root memcg doesn't account charges, and doesn't support - * protection. + * protection. The target memcg's protection is ignored, see + * mem_cgroup_calculate_protection() and mem_cgroup_protection() */ - return !mem_cgroup_disabled() && !mem_cgroup_is_root(memcg); - + return mem_cgroup_disabled() || mem_cgroup_is_root(memcg) || + memcg == target; } -static inline bool mem_cgroup_below_low(struct mem_cgroup *memcg) +static inline bool mem_cgroup_below_low(struct mem_cgroup *target, + struct mem_cgroup *memcg) { - if (!mem_cgroup_supports_protection(memcg)) + if (mem_cgroup_unprotected(target, memcg)) return false; return READ_ONCE(memcg->memory.elow) >= page_counter_read(&memcg->memory); } -static inline bool mem_cgroup_below_min(struct mem_cgroup *memcg) +static inline bool mem_cgroup_below_min(struct mem_cgroup *target, + struct mem_cgroup *memcg) { - if (!mem_cgroup_supports_protection(memcg)) + if (mem_cgroup_unprotected(target, memcg)) return false; return READ_ONCE(memcg->memory.emin) >= @@ -1378,12 +1382,19 @@ static inline void mem_cgroup_calculate_protection(struct mem_cgroup *root, { } -static inline bool mem_cgroup_below_low(struct mem_cgroup *memcg) +static inline bool mem_cgroup_unprotected(struct mem_cgroup *target, + struct mem_cgroup *memcg) +{ + return true; +} +static inline bool mem_cgroup_below_low(struct mem_cgroup *target, + struct mem_cgroup *memcg) { return false; } -static inline bool mem_cgroup_below_min(struct mem_cgroup *memcg) +static inline bool mem_cgroup_below_min(struct mem_cgroup *target, + struct mem_cgroup *memcg) { return false; } diff --git a/mm/vmscan.c b/mm/vmscan.c index 3d383c7126e3..044bf496885b 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2860,13 +2860,13 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc) mem_cgroup_calculate_protection(target_memcg, memcg); - if (mem_cgroup_below_min(memcg)) { + if (mem_cgroup_below_min(target_memcg, memcg)) { /* * Hard protection. * If there is no reclaimable memory, OOM. */ continue; - } else if (mem_cgroup_below_low(memcg)) { + } else if (mem_cgroup_below_low(target_memcg, memcg)) { /* * Soft protection. * Respect the protection only as long as -- 2.34.1

2 1

[PATCH OLK-6.6 RESEND 0/4] erofs: fix WARNING in ida_free
by Baokun Li 06 May '24

06 May '24

Baokun Li (2): erofs: fix lockdep false positives on initializing erofs_pseudo_mnt erofs: get rid of erofs_fs_context Christian Brauner (1): erofs: reliably distinguish block based and fscache mode Gao Xiang (1): erofs: drop experimental warning for FSDAX fs/erofs/fscache.c | 15 ++++- fs/erofs/internal.h | 8 --- fs/erofs/super.c | 155 ++++++++++++++++---------------------------- 3 files changed, 70 insertions(+), 108 deletions(-) -- 2.31.1

2 5