- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] ksmbd: fix use-after-free in ksmbd_tree_connect_put under concurrency
by Li Lingfeng 23 Jan '26

23 Jan '26

From: Namjae Jeon <linkinjeon(a)kernel.org> stable inclusion from stable-v6.6.120 commit d64977495e44855f2b28d8ce56107c963a7a50e4 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13369 CVE: CVE-2025-68817 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit b39a1833cc4a2755b02603eec3a71a85e9dff926 ] Under high concurrency, A tree-connection object (tcon) is freed on a disconnect path while another path still holds a reference and later executes *_put()/write on it. Reported-by: Qianchang Zhao <pioooooooooip(a)gmail.com> Reported-by: Zhitong Liu <liuzhitong1993(a)gmail.com> Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/smb/server/mgmt/tree_connect.c | 18 ++++-------------- fs/smb/server/mgmt/tree_connect.h | 1 - fs/smb/server/smb2pdu.c | 3 --- 3 files changed, 4 insertions(+), 18 deletions(-) diff --git a/fs/smb/server/mgmt/tree_connect.c b/fs/smb/server/mgmt/tree_connect.c index 94a52a75014a..9bde1b58f9c4 100644 --- a/fs/smb/server/mgmt/tree_connect.c +++ b/fs/smb/server/mgmt/tree_connect.c @@ -77,7 +77,6 @@ ksmbd_tree_conn_connect(struct ksmbd_work *work, const char *share_name) tree_conn->t_state = TREE_NEW; status.tree_conn = tree_conn; atomic_set(&tree_conn->refcount, 1); - init_waitqueue_head(&tree_conn->refcount_q); ret = xa_err(xa_store(&sess->tree_conns, tree_conn->id, tree_conn, GFP_KERNEL)); @@ -99,14 +98,8 @@ ksmbd_tree_conn_connect(struct ksmbd_work *work, const char *share_name) void ksmbd_tree_connect_put(struct ksmbd_tree_connect *tcon) { - /* - * Checking waitqueue to releasing tree connect on - * tree disconnect. waitqueue_active is safe because it - * uses atomic operation for condition. - */ - if (!atomic_dec_return(&tcon->refcount) && - waitqueue_active(&tcon->refcount_q)) - wake_up(&tcon->refcount_q); + if (atomic_dec_and_test(&tcon->refcount)) + kfree(tcon); } int ksmbd_tree_conn_disconnect(struct ksmbd_session *sess, @@ -118,14 +111,11 @@ int ksmbd_tree_conn_disconnect(struct ksmbd_session *sess, xa_erase(&sess->tree_conns, tree_conn->id); write_unlock(&sess->tree_conns_lock); - if (!atomic_dec_and_test(&tree_conn->refcount)) - wait_event(tree_conn->refcount_q, - atomic_read(&tree_conn->refcount) == 0); - ret = ksmbd_ipc_tree_disconnect_request(sess->id, tree_conn->id); ksmbd_release_tree_conn_id(sess, tree_conn->id); ksmbd_share_config_put(tree_conn->share_conf); - kfree(tree_conn); + if (atomic_dec_and_test(&tree_conn->refcount)) + kfree(tree_conn); return ret; } diff --git a/fs/smb/server/mgmt/tree_connect.h b/fs/smb/server/mgmt/tree_connect.h index a42cdd051041..f0023d86716f 100644 --- a/fs/smb/server/mgmt/tree_connect.h +++ b/fs/smb/server/mgmt/tree_connect.h @@ -33,7 +33,6 @@ struct ksmbd_tree_connect { int maximal_access; bool posix_extensions; atomic_t refcount; - wait_queue_head_t refcount_q; unsigned int t_state; }; diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index bb1c7a399a18..5daa77c3652b 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -2166,7 +2166,6 @@ int smb2_tree_disconnect(struct ksmbd_work *work) goto err_out; } - WARN_ON_ONCE(atomic_dec_and_test(&tcon->refcount)); tcon->t_state = TREE_DISCONNECTED; write_unlock(&sess->tree_conns_lock); @@ -2176,8 +2175,6 @@ int smb2_tree_disconnect(struct ksmbd_work *work) goto err_out; } - work->tcon = NULL; - rsp->StructureSize = cpu_to_le16(4); err = ksmbd_iov_pin_rsp(work, rsp, sizeof(struct smb2_tree_disconnect_rsp)); -- 2.52.0

2 1

[PATCH OLK-5.10] ntfs: set dummy blocksize to read boot_block when mounting
by Li Lingfeng 23 Jan '26

23 Jan '26

From: Pedro Demarchi Gomes <pedrodemargomes(a)gmail.com> mainline inclusion from mainline-v6.19-rc1 commit d1693a7d5a38acf6424235a6070bcf5b186a360d category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13378 CVE: CVE-2025-71067 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- When mounting, sb->s_blocksize is used to read the boot_block without being defined or validated. Set a dummy blocksize before attempting to read the boot_block. The issue can be triggered with the following syz reproducer: mkdirat(0xffffffffffffff9c, &(0x7f0000000080)='./file1\x00', 0x0) r4 = openat$nullb(0xffffffffffffff9c, &(0x7f0000000040), 0x121403, 0x0) ioctl$FS_IOC_SETFLAGS(r4, 0x40081271, &(0x7f0000000980)=0x4000) mount(&(0x7f0000000140)=@nullb, &(0x7f0000000040)='./cgroup\x00', &(0x7f0000000000)='ntfs3\x00', 0x2208004, 0x0) syz_clone(0x88200200, 0x0, 0x0, 0x0, 0x0, 0x0) Here, the ioctl sets the bdev block size to 16384. During mount, get_tree_bdev_flags() calls sb_set_blocksize(sb, block_size(bdev)), but since block_size(bdev) > PAGE_SIZE, sb_set_blocksize() leaves sb->s_blocksize at zero. Later, ntfs_init_from_boot() attempts to read the boot_block while sb->s_blocksize is still zero, which triggers the bug. Reported-by: syzbot+f4f84b57a01d6b8364ad(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=f4f84b57a01d6b8364ad Signed-off-by: Pedro Demarchi Gomes <pedrodemargomes(a)gmail.com> [almaz.alexandrovich(a)paragon-software.com: changed comment style, added return value handling] Signed-off-by: Konstantin Komarov <almaz.alexandrovich(a)paragon-software.com> Conflicts: fs/ntfs3/super.c [Commit 6c3684e70383 ("ntfs: set dummy blocksize to read boot_block when mounting") add tag of read_boot in ntfs_init_from_boot().] Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/ntfs3/super.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/fs/ntfs3/super.c b/fs/ntfs3/super.c index 1d6b45b70538..cbeb8156ff30 100644 --- a/fs/ntfs3/super.c +++ b/fs/ntfs3/super.c @@ -693,6 +693,11 @@ static int ntfs_init_from_boot(struct super_block *sb, u32 sector_size, sbi->volume.blocks = dev_size >> PAGE_SHIFT; + /* Set dummy blocksize to read boot_block. */ + if (!sb_min_blocksize(sb, PAGE_SIZE)) { + return -EINVAL; + } + bh = ntfs_bread(sb, 0); if (!bh) return -EIO; -- 2.52.0

2 1

[PATCH OLK-6.6] sched/fair: Track idle balance interval with idle_stamp in balance_fair
by Chen Jinghuang 23 Jan '26

23 Jan '26

hulk inclusion category: bugfix bugzilla: https://atomgit.com/openeuler/kernel/issues/8425 -------------------------------- Fix commit 70769fe636ef ("sched/fair: Hoist idle_stamp up from idle_balance")forgot to add the complete idle_stamp start/end tracking interval around sched_balance_newidle() in balance_fair. Fixes: 70769fe636ef ("sched/fair: Hoist idle_stamp up from idle_balance") Signed-off-by: Chen Jinghuang <chenjinghuang2(a)huawei.com> --- kernel/sched/fair.c | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index b21c1ba1ded1..e60f19cb0fee 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -9467,10 +9467,19 @@ static void task_dead_fair(struct task_struct *p) static int balance_fair(struct rq *rq, struct task_struct *prev, struct rq_flags *rf) { + int new_tasks; + if (rq->nr_running) return 1; - return newidle_balance(rq, rf) != 0; + rq_idle_stamp_update(rq); + + new_tasks = newidle_balance(rq, rf); + + if (new_tasks) + rq_idle_stamp_clear(rq); + + return new_tasks != 0; } #endif /* CONFIG_SMP */ -- 2.34.1

2 1

[PATCH OLK-5.10] ice: fix memory leak in aRFS after reset
by Lin Ruifeng 23 Jan '26

23 Jan '26

From: Grzegorz Nitka <grzegorz.nitka(a)intel.com> mainline inclusion from mainline-v6.14-rc7 commit 23d97f18901ef5e4e264e3b1777fe65c760186b5 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/12664 CVE: CVE-2025-21981 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- Fix aRFS (accelerated Receive Flow Steering) structures memory leak by adding a checker to verify if aRFS memory is already allocated while configuring VSI. aRFS objects are allocated in two cases: - as part of VSI initialization (at probe), and - as part of reset handling However, VSI reconfiguration executed during reset involves memory allocation one more time, without prior releasing already allocated resources. This led to the memory leak with the following signature: [root@os-delivery ~]# cat /sys/kernel/debug/kmemleak unreferenced object 0xff3c1ca7252e6000 (size 8192): comm "kworker/0:0", pid 8, jiffies 4296833052 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [<ffffffff991ec485>] __kmalloc_cache_noprof+0x275/0x340 [<ffffffffc0a6e06a>] ice_init_arfs+0x3a/0xe0 [ice] [<ffffffffc09f1027>] ice_vsi_cfg_def+0x607/0x850 [ice] [<ffffffffc09f244b>] ice_vsi_setup+0x5b/0x130 [ice] [<ffffffffc09c2131>] ice_init+0x1c1/0x460 [ice] [<ffffffffc09c64af>] ice_probe+0x2af/0x520 [ice] [<ffffffff994fbcd3>] local_pci_probe+0x43/0xa0 [<ffffffff98f07103>] work_for_cpu_fn+0x13/0x20 [<ffffffff98f0b6d9>] process_one_work+0x179/0x390 [<ffffffff98f0c1e9>] worker_thread+0x239/0x340 [<ffffffff98f14abc>] kthread+0xcc/0x100 [<ffffffff98e45a6d>] ret_from_fork+0x2d/0x50 [<ffffffff98e083ba>] ret_from_fork_asm+0x1a/0x30 ... Fixes: 28bf26724fdb ("ice: Implement aRFS") Reviewed-by: Michal Swiatkowski <michal.swiatkowski(a)linux.intel.com> Signed-off-by: Grzegorz Nitka <grzegorz.nitka(a)intel.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Tested-by: Rinitha S <sx.rinitha(a)intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Conflicts: drivers/net/ethernet/intel/ice/ice_arfs.c [context conflict] Signed-off-by: Tirui Yin <yintirui(a)huawei.com> Reviewed-by: Weilong Chen <chenweilong(a)huawei.com> --- drivers/net/ethernet/intel/ice/ice_arfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ice/ice_arfs.c b/drivers/net/ethernet/intel/ice/ice_arfs.c index cca0e753f38f..d7e0116f6773 100644 --- a/drivers/net/ethernet/intel/ice/ice_arfs.c +++ b/drivers/net/ethernet/intel/ice/ice_arfs.c @@ -510,7 +510,7 @@ void ice_init_arfs(struct ice_vsi *vsi) struct hlist_head *arfs_fltr_list; unsigned int i; - if (!vsi || vsi->type != ICE_VSI_PF) + if (!vsi || vsi->type != ICE_VSI_PF || ice_is_arfs_active(vsi)) return; arfs_fltr_list = kzalloc(sizeof(*arfs_fltr_list) * ICE_MAX_ARFS_LIST, -- 2.43.0

2 1

[PATCH] arm64: kexec: Add support for crashkernel CMA reservation
by Jinjie Ruan 23 Jan '26

23 Jan '26

Extend crashkernel CMA reservation support to arm64. The following changes are made to enable CMA reservation on powerpc: - Parse and obtain the CMA reservation size along with other crashkernel parameters. - Call reserve_crashkernel_cma() to allocate the CMA region for kdump. - Include the CMA-reserved ranges for kdump kernel to use. - Exclude the CMA-reserved ranges from the crash kernel memory to prevent them from being exported through /proc/vmcore. Update kernel-parameters.txt to document CMA support for crashkernel on arm64 architecture. Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- Documentation/admin-guide/kernel-parameters.txt | 2 +- arch/arm64/kernel/machine_kexec_file.c | 15 ++++++++++++++- arch/arm64/mm/init.c | 5 +++-- 3 files changed, 18 insertions(+), 4 deletions(-) diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 1058f2a6d6a8..36bb642a7edd 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -1119,7 +1119,7 @@ Kernel parameters It will be ignored when crashkernel=X,high is not used or memory reserved is below 4G. crashkernel=size[KMG],cma - [KNL, X86, ppc] Reserve additional crash kernel memory from + [KNL, X86, ARM64, ppc] Reserve additional crash kernel memory from CMA. This reservation is usable by the first system's userspace memory and kernel movable allocations (memory balloon, zswap). Pages allocated from this memory range diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c index 410060ebd86d..0ee679167664 100644 --- a/arch/arm64/kernel/machine_kexec_file.c +++ b/arch/arm64/kernel/machine_kexec_file.c @@ -48,7 +48,7 @@ static int prepare_elf_headers(void **addr, unsigned long *sz) u64 i; phys_addr_t start, end; - nr_ranges = 2; /* for exclusion of crashkernel region */ + nr_ranges = 2 + crashk_cma_cnt; /* for exclusion of crashkernel region */ for_each_mem_range(i, &start, &end) nr_ranges++; @@ -64,6 +64,12 @@ static int prepare_elf_headers(void **addr, unsigned long *sz) cmem->nr_ranges++; } + for (i = 0; i < crashk_cma_cnt; i++) { + cmem->ranges[cmem->nr_ranges].start = crashk_cma_ranges[i].start; + cmem->ranges[cmem->nr_ranges].end = crashk_cma_ranges[i].end; + cmem->nr_ranges++; + } + /* Exclude crashkernel region */ ret = crash_exclude_mem_range(cmem, crashk_res.start, crashk_res.end); if (ret) @@ -75,6 +81,13 @@ static int prepare_elf_headers(void **addr, unsigned long *sz) goto out; } + for (i = 0; i < crashk_cma_cnt; ++i) { + ret = crash_exclude_mem_range(cmem, crashk_cma_ranges[i].start, + crashk_cma_ranges[i].end); + if (ret) + return ret; + } + ret = crash_prepare_elf64_headers(cmem, true, addr, sz); out: diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c index 524d34a0e921..28165d94af08 100644 --- a/arch/arm64/mm/init.c +++ b/arch/arm64/mm/init.c @@ -96,8 +96,8 @@ phys_addr_t __ro_after_init arm64_dma_phys_limit; static void __init arch_reserve_crashkernel(void) { + unsigned long long crash_base, crash_size, cma_size = 0; unsigned long long low_size = 0; - unsigned long long crash_base, crash_size; bool high = false; int ret; @@ -106,11 +106,12 @@ static void __init arch_reserve_crashkernel(void) ret = parse_crashkernel(boot_command_line, memblock_phys_mem_size(), &crash_size, &crash_base, - &low_size, NULL, &high); + &low_size, &cma_size, &high); if (ret) return; reserve_crashkernel_generic(crash_size, crash_base, low_size, high); + reserve_crashkernel_cma(cma_size); } static phys_addr_t __init max_zone_phys(phys_addr_t zone_limit) -- 2.34.1

1 0

[PATCH OLK-5.10] ice: fix memory leak in aRFS after reset
by Yin Tirui 23 Jan '26

23 Jan '26

From: Grzegorz Nitka <grzegorz.nitka(a)intel.com> mainline inclusion from mainline-v6.14-rc7 commit 23d97f18901ef5e4e264e3b1777fe65c760186b5 category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/12664 CVE: CVE-2025-21981 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- Fix aRFS (accelerated Receive Flow Steering) structures memory leak by adding a checker to verify if aRFS memory is already allocated while configuring VSI. aRFS objects are allocated in two cases: - as part of VSI initialization (at probe), and - as part of reset handling However, VSI reconfiguration executed during reset involves memory allocation one more time, without prior releasing already allocated resources. This led to the memory leak with the following signature: [root@os-delivery ~]# cat /sys/kernel/debug/kmemleak unreferenced object 0xff3c1ca7252e6000 (size 8192): comm "kworker/0:0", pid 8, jiffies 4296833052 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 0): [<ffffffff991ec485>] __kmalloc_cache_noprof+0x275/0x340 [<ffffffffc0a6e06a>] ice_init_arfs+0x3a/0xe0 [ice] [<ffffffffc09f1027>] ice_vsi_cfg_def+0x607/0x850 [ice] [<ffffffffc09f244b>] ice_vsi_setup+0x5b/0x130 [ice] [<ffffffffc09c2131>] ice_init+0x1c1/0x460 [ice] [<ffffffffc09c64af>] ice_probe+0x2af/0x520 [ice] [<ffffffff994fbcd3>] local_pci_probe+0x43/0xa0 [<ffffffff98f07103>] work_for_cpu_fn+0x13/0x20 [<ffffffff98f0b6d9>] process_one_work+0x179/0x390 [<ffffffff98f0c1e9>] worker_thread+0x239/0x340 [<ffffffff98f14abc>] kthread+0xcc/0x100 [<ffffffff98e45a6d>] ret_from_fork+0x2d/0x50 [<ffffffff98e083ba>] ret_from_fork_asm+0x1a/0x30 ... Fixes: 28bf26724fdb ("ice: Implement aRFS") Reviewed-by: Michal Swiatkowski <michal.swiatkowski(a)linux.intel.com> Signed-off-by: Grzegorz Nitka <grzegorz.nitka(a)intel.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Tested-by: Rinitha S <sx.rinitha(a)intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen(a)intel.com> Conflicts: drivers/net/ethernet/intel/ice/ice_arfs.c [context conflict] Signed-off-by: Tirui Yin <yintirui(a)huawei.com> Reviewed-by: Weilong Chen <chenweilong(a)huawei.com> --- drivers/net/ethernet/intel/ice/ice_arfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/ice/ice_arfs.c b/drivers/net/ethernet/intel/ice/ice_arfs.c index cca0e753f38f..d7e0116f6773 100644 --- a/drivers/net/ethernet/intel/ice/ice_arfs.c +++ b/drivers/net/ethernet/intel/ice/ice_arfs.c @@ -510,7 +510,7 @@ void ice_init_arfs(struct ice_vsi *vsi) struct hlist_head *arfs_fltr_list; unsigned int i; - if (!vsi || vsi->type != ICE_VSI_PF) + if (!vsi || vsi->type != ICE_VSI_PF || ice_is_arfs_active(vsi)) return; arfs_fltr_list = kzalloc(sizeof(*arfs_fltr_list) * ICE_MAX_ARFS_LIST, -- 2.43.0

2 1

[PATCH OLK-5.10] ocfs2: fix kernel BUG in ocfs2_find_victim_chain
by Li Lingfeng 23 Jan '26

23 Jan '26

From: Prithvi Tambewagh <activprithvi(a)gmail.com> mainline inclusion from mainline-v6.19-rc1 commit 039bef30e320827bac8990c9f29d2a68cd8adb5f category: bugfix bugzilla: https://atomgit.com/src-openeuler/kernel/issues/13326 CVE: CVE-2025-68771 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- syzbot reported a kernel BUG in ocfs2_find_victim_chain() because the `cl_next_free_rec` field of the allocation chain list (next free slot in the chain list) is 0, triggring the BUG_ON(!cl->cl_next_free_rec) condition in ocfs2_find_victim_chain() and panicking the kernel. To fix this, an if condition is introduced in ocfs2_claim_suballoc_bits(), just before calling ocfs2_find_victim_chain(), the code block in it being executed when either of the following conditions is true: 1. `cl_next_free_rec` is equal to 0, indicating that there are no free chains in the allocation chain list 2. `cl_next_free_rec` is greater than `cl_count` (the total number of chains in the allocation chain list) Either of them being true is indicative of the fact that there are no chains left for usage. This is addressed using ocfs2_error(), which prints the error log for debugging purposes, rather than panicking the kernel. Link: https://lkml.kernel.org/r/20251201130711.143900-1-activprithvi@gmail.com Signed-off-by: Prithvi Tambewagh <activprithvi(a)gmail.com> Reported-by: syzbot+96d38c6e1655c1420a72(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=96d38c6e1655c1420a72 Tested-by: syzbot+96d38c6e1655c1420a72(a)syzkaller.appspotmail.com Reviewed-by: Joseph Qi <joseph.qi(a)linux.alibaba.com> Cc: Mark Fasheh <mark(a)fasheh.com> Cc: Joel Becker <jlbec(a)evilplan.org> Cc: Junxiao Bi <junxiao.bi(a)oracle.com> Cc: Changwei Ge <gechangwei(a)live.cn> Cc: Jun Piao <piaojun(a)huawei.com> Cc: Heming Zhao <heming.zhao(a)suse.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/ocfs2/suballoc.c | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/fs/ocfs2/suballoc.c b/fs/ocfs2/suballoc.c index 4f48003e4327..984bf3d24c23 100644 --- a/fs/ocfs2/suballoc.c +++ b/fs/ocfs2/suballoc.c @@ -1925,6 +1925,16 @@ static int ocfs2_claim_suballoc_bits(struct ocfs2_alloc_context *ac, } cl = (struct ocfs2_chain_list *) &fe->id2.i_chain; + if (!le16_to_cpu(cl->cl_next_free_rec) || + le16_to_cpu(cl->cl_next_free_rec) > le16_to_cpu(cl->cl_count)) { + status = ocfs2_error(ac->ac_inode->i_sb, + "Chain allocator dinode %llu has invalid next " + "free chain record %u, but only %u total\n", + (unsigned long long)le64_to_cpu(fe->i_blkno), + le16_to_cpu(cl->cl_next_free_rec), + le16_to_cpu(cl->cl_count)); + goto bail; + } victim = ocfs2_find_victim_chain(cl); ac->ac_chain = victim; -- 2.52.0

2 1

[PATCH v4 openEuler-25.03 0/1] NUMA ro-data replication for userspace applications
by Nikita Panov 22 Jan '26

22 Jan '26

This patchset implements support of userspace translation tables and private read-only data replication for AArch64 and is going to improve latency and memory bandwidth by reducing cross-NUMA memory accesses. openEuler 25.03 is used as a baseline. Current implementation supports next functionality: 1. Per-NUMA node replication of userspace translation tables and private read-only data. We replicate only __private read-only__ data to avoid dealing with replicas coherence and consistency support. Translation tables, in turn, are able to be replicated for any kind of underlying data. 2. Ability to enable userspace replication for a certain process via procfs or for a group of processes via memory cgroup. 3. 4K and 64K pages are supported. 4. Replicated data pages can't be a ksm, migration or swap/reclaim candidates by design. But for other pages these work as well with replicated translation tables support. Once the user replication was enabled for a process via either procfs or memory cgroup, all it's existing private read-only data will be immediately replicated with translation tables for them. Later, as the process running, __any__ page fault occured will cause replicating of translation tables related to the faulted address. Also there is a mechanism implemented on the top of numa-balancer that will replicate private read-only pages on NUMA faults, as the process running (numa balancer should be enabled for the mechanism to work). Known problems: 1. Current implementation doesn't support huge pages, so you have to build the kernel with huge pages disabled for user replication to work. Huge pages support will be added in the nearest future. 2. mremap syscall doesn't work with replicated memory yet. 3. page_idle, uprobes and userfaultfd support replicated translation tables, but not replicated data. Be responsible using these features with userspace replication enabled. 4. When replicating translation tables during page faults, there should be enough space on __each__ NUMA node for table allocations. Otherwise it will cause OOM-killer. Despite the problems above, they are mostly not related to workloads assumed to benefit from user replication feature, and such workloads will work properly with the feature enabled. Nikita Panov (1): mm: Support NUMA-aware replication of read-only data and translation tables of user space applications arch/arm64/include/asm/numa_replication.h | 3 + arch/arm64/mm/init.c | 2 +- arch/arm64/mm/pgd.c | 13 +- fs/exec.c | 18 + fs/proc/base.c | 76 + fs/proc/task_mmu.c | 112 +- include/asm-generic/pgalloc.h | 19 +- include/asm-generic/tlb.h | 22 + include/linux/cgroup.h | 1 + include/linux/gfp_types.h | 12 +- include/linux/memcontrol.h | 4 + include/linux/mm.h | 77 +- include/linux/mm_inline.h | 5 + include/linux/mm_types.h | 52 +- include/linux/numa_kernel_replication.h | 232 ++- include/linux/numa_user_replication.h | 760 ++++++++++ include/linux/page-flags.h | 18 +- include/trace/events/mmflags.h | 10 +- include/uapi/asm-generic/mman-common.h | 3 + kernel/cgroup/cgroup.c | 2 +- kernel/events/uprobes.c | 5 +- kernel/fork.c | 39 + kernel/sched/fair.c | 8 +- mm/Kconfig | 13 + mm/Makefile | 1 + mm/gup.c | 3 +- mm/ksm.c | 15 +- mm/madvise.c | 19 +- mm/memcontrol.c | 137 +- mm/memory.c | 548 +++++-- mm/mempolicy.c | 5 + mm/migrate.c | 11 +- mm/migrate_device.c | 17 +- mm/mlock.c | 32 + mm/mmap.c | 32 + mm/mmu_gather.c | 55 +- mm/mprotect.c | 411 +++--- mm/mremap.c | 97 +- mm/numa_kernel_replication.c | 5 +- mm/numa_user_replication.c | 1603 +++++++++++++++++++++ mm/page_alloc.c | 8 +- mm/page_idle.c | 3 +- mm/page_vma_mapped.c | 3 +- mm/rmap.c | 41 +- mm/swap.c | 7 +- mm/swapfile.c | 3 +- mm/userfaultfd.c | 7 +- mm/userswap.c | 11 +- 48 files changed, 4145 insertions(+), 435 deletions(-) create mode 100644 include/linux/numa_user_replication.h create mode 100644 mm/numa_user_replication.c -- 2.34.1

2 2

[PATCH v3 openEuler-25.03 0/1] NUMA ro-data replication for userspace applications
by Nikita Panov 22 Jan '26

22 Jan '26

This patchset implements support of userspace translation tables and private read-only data replication for AArch64 and is going to improve latency and memory bandwidth by reducing cross-NUMA memory accesses. openEuler 25.03 is used as a baseline. Current implementation supports next functionality: 1. Per-NUMA node replication of userspace translation tables and private read-only data. We replicate only __private read-only__ data to avoid dealing with replicas coherence and consistency support. Translation tables, in turn, are able to be replicated for any kind of underlying data. 2. Ability to enable userspace replication for a certain process via procfs or for a group of processes via memory cgroup. 3. 4K and 64K pages are supported. 4. Replicated data pages can't be a ksm, migration or swap/reclaim candidates by design. But for other pages these work as well with replicated translation tables support. Once the user replication was enabled for a process via either procfs or memory cgroup, all it's existing private read-only data will be immediately replicated with translation tables for them. Later, as the process running, __any__ page fault occured will cause replicating of translation tables related to the faulted address. Also there is a mechanism implemented on the top of numa-balancer that will replicate private read-only pages on NUMA faults, as the process running (numa balancer should be enabled for the mechanism to work). Known problems: 1. Current implementation doesn't support huge pages, so you have to build the kernel with huge pages disabled for user replication to work. Huge pages support will be added in the nearest future. 2. mremap syscall doesn't work with replicated memory yet. 3. page_idle, uprobes and userfaultfd support replicated translation tables, but not replicated data. Be responsible using these features with userspace replication enabled. 4. When replicating translation tables during page faults, there should be enough space on __each__ NUMA node for table allocations. Otherwise it will cause OOM-killer. Despite the problems above, they are mostly not related to workloads assumed to benefit from user replication feature, and such workloads will work properly with the feature enabled. Nikita Panov (1): mm: Support NUMA-aware replication of read-only data and translation tables of user space applications arch/arm64/include/asm/numa_replication.h | 3 + arch/arm64/mm/init.c | 2 +- arch/arm64/mm/pgd.c | 13 +- fs/exec.c | 18 + fs/proc/base.c | 76 + fs/proc/task_mmu.c | 112 +- include/asm-generic/pgalloc.h | 19 +- include/asm-generic/tlb.h | 22 + include/linux/cgroup.h | 1 + include/linux/gfp_types.h | 12 +- include/linux/memcontrol.h | 4 + include/linux/mm.h | 77 +- include/linux/mm_inline.h | 5 + include/linux/mm_types.h | 52 +- include/linux/numa_kernel_replication.h | 232 ++- include/linux/numa_user_replication.h | 760 ++++++++++ include/linux/page-flags.h | 18 +- include/trace/events/mmflags.h | 10 +- include/uapi/asm-generic/mman-common.h | 3 + kernel/cgroup/cgroup.c | 2 +- kernel/events/uprobes.c | 5 +- kernel/fork.c | 39 + kernel/sched/fair.c | 8 +- mm/Kconfig | 13 + mm/Makefile | 1 + mm/gup.c | 3 +- mm/ksm.c | 15 +- mm/madvise.c | 19 +- mm/memcontrol.c | 137 +- mm/memory.c | 548 +++++-- mm/mempolicy.c | 5 + mm/migrate.c | 11 +- mm/migrate_device.c | 17 +- mm/mlock.c | 32 + mm/mmap.c | 32 + mm/mmu_gather.c | 55 +- mm/mprotect.c | 411 +++--- mm/mremap.c | 97 +- mm/numa_kernel_replication.c | 5 +- mm/numa_user_replication.c | 1603 +++++++++++++++++++++ mm/page_alloc.c | 8 +- mm/page_idle.c | 3 +- mm/page_vma_mapped.c | 3 +- mm/rmap.c | 41 +- mm/swap.c | 7 +- mm/swapfile.c | 3 +- mm/userfaultfd.c | 7 +- mm/userswap.c | 11 +- 48 files changed, 4145 insertions(+), 435 deletions(-) create mode 100644 include/linux/numa_user_replication.h create mode 100644 mm/numa_user_replication.c -- 2.34.1

2 2

[PATCH] timers: Remove get_timer_this_cpu_base()
by Jinjie Ruan 22 Jan '26

22 Jan '26

get_timer_this_cpu_base() and get_timer_cpu_base() have almost identical implementations, so replace the former with the latter. Signed-off-by: Jinjie Ruan <ruanjinjie(a)huawei.com> --- kernel/time/timer.c | 17 ++--------------- 1 file changed, 2 insertions(+), 15 deletions(-) diff --git a/kernel/time/timer.c b/kernel/time/timer.c index 1f2364126894..da1295646d39 100644 --- a/kernel/time/timer.c +++ b/kernel/time/timer.c @@ -925,20 +925,6 @@ static inline struct timer_base *get_timer_cpu_base(u32 tflags, u32 cpu) return per_cpu_ptr(&timer_bases[index], cpu); } -static inline struct timer_base *get_timer_this_cpu_base(u32 tflags) -{ - int index = tflags & TIMER_PINNED ? BASE_LOCAL : BASE_GLOBAL; - - /* - * If the timer is deferrable and NO_HZ_COMMON is set then we need - * to use the deferrable base. - */ - if (IS_ENABLED(CONFIG_NO_HZ_COMMON) && (tflags & TIMER_DEFERRABLE)) - index = BASE_DEF; - - return this_cpu_ptr(&timer_bases[index]); -} - static inline struct timer_base *get_timer_base(u32 tflags) { return get_timer_cpu_base(tflags, tflags & TIMER_CPUMASK); @@ -1019,6 +1005,7 @@ __mod_timer(struct timer_list *timer, unsigned long expires, unsigned int option { unsigned long clk = 0, flags, bucket_expiry; struct timer_base *base, *new_base; + int cpu = smp_processor_id(); unsigned int idx = UINT_MAX; int ret = 0; @@ -1098,7 +1085,7 @@ __mod_timer(struct timer_list *timer, unsigned long expires, unsigned int option if (!ret && (options & MOD_TIMER_PENDING_ONLY)) goto out_unlock; - new_base = get_timer_this_cpu_base(timer->flags); + new_base = get_timer_cpu_base(timer->flags, cpu); if (base != new_base) { /* -- 2.34.1

1 0