- Kernel - mailweb.openeuler.org

[PATCH OLK-6.6] [Huawei] mm/mem_reliable: use percise count during limit check
by Wupeng Ma 18 Dec '25

18 Dec '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8USBA -------------------------------- If the fallback for memory reliable is enabled, direct reclaim will be used if the task's reliable memory limit is reached and pages need to be released. However, percpu_counter_read_positive() provides a fast but imprecise counter reading. During limit enforcement, this inaccuracy may cause the observed usage to appear significantly larger than the actual value. As a result, even repeated constrained reclaim attempts may fail to bring memory usage below the limit, eventually leading to OOM. To avoid this issue, use an accurate counter check when determining whether the reliable memory limit has been exceeded. Fixes: 200321e8a69e ("mm: mem_reliable: Add limiting the usage of reliable memory") Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- include/linux/mem_reliable.h | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/include/linux/mem_reliable.h b/include/linux/mem_reliable.h index 1e928ff69d99..9047918e1331 100644 --- a/include/linux/mem_reliable.h +++ b/include/linux/mem_reliable.h @@ -169,11 +169,15 @@ static inline void shmem_reliable_folio_add(struct folio *folio, int nr_page) percpu_counter_add(&shmem_reliable_pages, nr_page); } - static inline bool reliable_mem_limit_check(unsigned long nr_page) { - return (task_reliable_used_pages() + nr_page) <= - (task_reliable_limit >> PAGE_SHIFT); + s64 nr_task_pages; + + /* limit check need precise counter, use sum rather than read */ + nr_task_pages = percpu_counter_sum_positive(&pagecache_reliable_pages); + nr_task_pages += percpu_counter_sum_positive(&anon_reliable_pages); + + return (nr_task_pages + nr_page) <= (task_reliable_limit >> PAGE_SHIFT); } static inline bool mem_reliable_should_reclaim(void) -- 2.43.0

2 1

[PATCH OLK-6.6] mm: mem_reliable: fix task reliable counter during fork
by Wupeng Ma 18 Dec '25

18 Dec '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8USBA -------------------------------- Commit 8fc2546f8508 ("proc: mem_reliable: Count reliable memory usage of reliable tasks") introduce counting reliable memory allocated by the reliable user tasks which need to update reliable counter after rss. However during commit 1741ac635805 ("mm/memory: optimize fork() with PTE-mapped THP") which introduce PTE batching when consecutive present PTEs map consecutive pages of the same large folio and share identical bits aside from PFNs. This patch introuce rss modification without updating memory reliale's counter which lead to memory relabies's counter inbalanced during fork with thp disabled. Fix this by updating memory reliable's counter after rss updates. Fixes: 1741ac635805 ("mm/memory: optimize fork() with PTE-mapped THP") Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- mm/memory.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/mm/memory.c b/mm/memory.c index d5932b924e08..75900321740f 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -937,6 +937,7 @@ copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma folio_add_new_anon_rmap(new_folio, dst_vma, addr, RMAP_EXCLUSIVE); folio_add_lru_vma(new_folio, dst_vma); rss[MM_ANONPAGES]++; + add_reliable_folio_counter(new_folio, dst_vma->vm_mm, 1); /* All done, just insert the new page copy in the child */ pte = mk_pte(&new_folio->page, dst_vma->vm_page_prot); @@ -1021,6 +1022,7 @@ copy_present_ptes(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma folio_dup_file_rmap_ptes(folio, page, nr); rss[mm_counter_file(folio)] += nr; } + add_reliable_folio_counter(folio, dst_vma->vm_mm, nr); if (any_writable) pte = pte_mkwrite(pte, src_vma); __copy_present_ptes(dst_vma, src_vma, dst_pte, src_pte, pte, @@ -1048,8 +1050,8 @@ copy_present_ptes(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma } else { folio_dup_file_rmap_pte(folio, page); rss[mm_counter_file(folio)]++; - add_reliable_folio_counter(folio, dst_vma->vm_mm, 1); } + add_reliable_folio_counter(folio, dst_vma->vm_mm, 1); copy_pte: __copy_present_ptes(dst_vma, src_vma, dst_pte, src_pte, pte, addr, 1); -- 2.43.0

2 1

[openeuler:openEuler-1.0-LTS 1946/1946] kernel/time/hrtimer.o: warning: objtool: hrtimer_start_range_ns()+0x91b: unreachable instruction
by kernel test robot 18 Dec '25

18 Dec '25

Hi Phil, First bad commit (maybe != root cause): tree: https://gitee.com/openeuler/kernel.git openEuler-1.0-LTS head: 4e9c55920995d70b3e88b60c69753df54b03fdf4 commit: 40ecfb28732cefd0c5658f7c10543bbc4cd41cb8 [1946/1946] hrtimer: Prevent queuing of hrtimer without a function callback config: x86_64-randconfig-002-20251218 (https://download.01.org/0day-ci/archive/20251218/202512181230.mRJPKu3s-lkp@…) compiler: clang version 22.0.0git (https://github.com/llvm/llvm-project 1335a05ab8bc8339ce24be3a9da89d8c3f4e0571) reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20251218/202512181230.mRJPKu3s-lkp@…) If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags | Reported-by: kernel test robot <lkp(a)intel.com> | Closes: https://lore.kernel.org/oe-kbuild-all/202512181230.mRJPKu3s-lkp@intel.com/ All warnings (new ones prefixed by >>): In file included from <built-in>:2: In file included from include/linux/compiler_types.h:59: include/linux/compiler-clang.h:20:9: warning: '__SANITIZE_ADDRESS__' macro redefined [-Wmacro-redefined] 20 | #define __SANITIZE_ADDRESS__ | ^ <built-in>:354:9: note: previous definition is here 354 | #define __SANITIZE_ADDRESS__ 1 | ^ kernel/time/hrtimer.c:130:21: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides] 130 | [CLOCK_REALTIME] = HRTIMER_BASE_REALTIME, | ^~~~~~~~~~~~~~~~~~~~~ kernel/time/hrtimer.c:128:27: note: previous initialization is here 128 | [0 ... MAX_CLOCKS - 1] = HRTIMER_MAX_CLOCK_BASES, | ^~~~~~~~~~~~~~~~~~~~~~~ kernel/time/hrtimer.c:131:22: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides] 131 | [CLOCK_MONOTONIC] = HRTIMER_BASE_MONOTONIC, | ^~~~~~~~~~~~~~~~~~~~~~ kernel/time/hrtimer.c:128:27: note: previous initialization is here 128 | [0 ... MAX_CLOCKS - 1] = HRTIMER_MAX_CLOCK_BASES, | ^~~~~~~~~~~~~~~~~~~~~~~ kernel/time/hrtimer.c:132:21: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides] 132 | [CLOCK_BOOTTIME] = HRTIMER_BASE_BOOTTIME, | ^~~~~~~~~~~~~~~~~~~~~ kernel/time/hrtimer.c:128:27: note: previous initialization is here 128 | [0 ... MAX_CLOCKS - 1] = HRTIMER_MAX_CLOCK_BASES, | ^~~~~~~~~~~~~~~~~~~~~~~ kernel/time/hrtimer.c:133:17: warning: initializer overrides prior initialization of this subobject [-Winitializer-overrides] 133 | [CLOCK_TAI] = HRTIMER_BASE_TAI, | ^~~~~~~~~~~~~~~~ kernel/time/hrtimer.c:128:27: note: previous initialization is here 128 | [0 ... MAX_CLOCKS - 1] = HRTIMER_MAX_CLOCK_BASES, | ^~~~~~~~~~~~~~~~~~~~~~~ 5 warnings generated. >> kernel/time/hrtimer.o: warning: objtool: hrtimer_start_range_ns()+0x91b: unreachable instruction -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests/wiki

1 0

[PATCH OLK-6.6] mm: mem_reliable: fix task reliable counter during fork
by Wupeng Ma 18 Dec '25

18 Dec '25

Offering: HULK hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8USBA -------------------------------- Commit 8fc2546f8508 ("proc: mem_reliable: Count reliable memory usage of reliable tasks") introduce counting reliable memory allocated by the reliable user tasks which need to update reliable counter after rss. However during commit 1741ac635805 ("mm/memory: optimize fork() with PTE-mapped THP") which introduce PTE batching when consecutive present PTEs map consecutive pages of the same large folio and share identical bits aside from PFNs. This patch introuce rss modification without updating memory reliale's counter which lead to memory relabies's counter inbalanced during fork with thp disabled. Fix this by updating memory reliable's counter after rss updates. Fixes: 1741ac635805 ("mm/memory: optimize fork() with PTE-mapped THP") Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- mm/memory.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/mm/memory.c b/mm/memory.c index d5932b924e08..75900321740f 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -937,6 +937,7 @@ copy_present_page(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma folio_add_new_anon_rmap(new_folio, dst_vma, addr, RMAP_EXCLUSIVE); folio_add_lru_vma(new_folio, dst_vma); rss[MM_ANONPAGES]++; + add_reliable_folio_counter(new_folio, dst_vma->vm_mm, 1); /* All done, just insert the new page copy in the child */ pte = mk_pte(&new_folio->page, dst_vma->vm_page_prot); @@ -1021,6 +1022,7 @@ copy_present_ptes(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma folio_dup_file_rmap_ptes(folio, page, nr); rss[mm_counter_file(folio)] += nr; } + add_reliable_folio_counter(folio, dst_vma->vm_mm, nr); if (any_writable) pte = pte_mkwrite(pte, src_vma); __copy_present_ptes(dst_vma, src_vma, dst_pte, src_pte, pte, @@ -1048,8 +1050,8 @@ copy_present_ptes(struct vm_area_struct *dst_vma, struct vm_area_struct *src_vma } else { folio_dup_file_rmap_pte(folio, page); rss[mm_counter_file(folio)]++; - add_reliable_folio_counter(folio, dst_vma->vm_mm, 1); } + add_reliable_folio_counter(folio, dst_vma->vm_mm, 1); copy_pte: __copy_present_ptes(dst_vma, src_vma, dst_pte, src_pte, pte, addr, 1); -- 2.43.0

2 1

[PATCH OLK-5.10] mm/mem_reliable: use percise count during limit check
by Wupeng Ma 18 Dec '25

18 Dec '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8USBA -------------------------------- If the fallback for memory reliable is enabled, direct reclaim will be used if the task's reliable memory limit is reached and pages need to be released. However, percpu_counter_read_positive() provides a fast but imprecise counter reading. During limit enforcement, this inaccuracy may cause the observed usage to appear significantly larger than the actual value. As a result, even repeated constrained reclaim attempts may fail to bring memory usage below the limit, eventually leading to OOM. To avoid this issue, use an accurate counter check when determining whether the reliable memory limit has been exceeded. Fixes: 8968270eb5fb ("mm: Add reliable memory use limit for user tasks") Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- include/linux/mem_reliable.h | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/include/linux/mem_reliable.h b/include/linux/mem_reliable.h index dc1344b843b0..3b8964c1041b 100644 --- a/include/linux/mem_reliable.h +++ b/include/linux/mem_reliable.h @@ -111,8 +111,13 @@ static inline u64 task_reliable_used_pages(void) static inline bool reliable_mem_limit_check(unsigned long nr_page) { - return (task_reliable_used_pages() + nr_page) <= - (task_reliable_limit >> PAGE_SHIFT); + s64 nr_task_pages; + + /* limit check need precise counter, use sum rather than read */ + nr_task_pages = percpu_counter_sum_positive(&pagecache_reliable_pages); + nr_task_pages += percpu_counter_sum_positive(&anon_reliable_pages); + + return (nr_task_pages + nr_page) <= (task_reliable_limit >> PAGE_SHIFT); } static inline bool mem_reliable_should_reclaim(void) -- 2.43.0

2 1

[PATCH openEuler-1.0-LTS] mm/mem_reliable: use percise count during limit check
by Wupeng Ma 18 Dec '25

18 Dec '25

hulk inclusion category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/I8USBA -------------------------------- If the fallback for memory reliable is enabled, direct reclaim will be used if the task's reliable memory limit is reached and pages need to be released. However, percpu_counter_read_positive() provides a fast but imprecise counter reading. During limit enforcement, this inaccuracy may cause the observed usage to appear significantly larger than the actual value. As a result, even repeated constrained reclaim attempts may fail to bring memory usage below the limit, eventually leading to OOM. To avoid this issue, use an accurate counter check when determining whether the reliable memory limit has been exceeded. Fixes: 875ffd41499e ("mm: Do limit checking after memory allocation for memory reliable") Signed-off-by: Wupeng Ma <mawupeng1(a)huawei.com> --- include/linux/mem_reliable.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/include/linux/mem_reliable.h b/include/linux/mem_reliable.h index c0eff851bbe7..d70146a59a3e 100644 --- a/include/linux/mem_reliable.h +++ b/include/linux/mem_reliable.h @@ -84,8 +84,9 @@ static inline bool reliable_mem_limit_check(unsigned long nr_page) { s64 num; - num = percpu_counter_read_positive(&pagecache_reliable_pages); - num += percpu_counter_read_positive(&anon_reliable_pages); + /* limit check need precise counter, use sum rather than read */ + num = percpu_counter_sum_positive(&pagecache_reliable_pages); + num += percpu_counter_sum_positive(&anon_reliable_pages); return num + nr_page <= task_reliable_limit / PAGE_SIZE; } -- 2.43.0

2 1

[PATCH OLK-5.10] drm/amdgpu/atom: Check kcalloc() for WS buffer in amdgpu_atom_execute_table_locked()
by Xinyu Zheng 18 Dec '25

18 Dec '25

From: Guangshuo Li <lgs201920130244(a)gmail.com> stable inclusion from stable-v6.12.58 commit 35f3fb86bb0158a298d6834e7e110dcaf07f490c category: bugfix bugzilla: https://gitee.com/openeuler/kernel/issues/IDDEV5 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… ---------------------------------------------------------------------- [ Upstream commit cc9a8e238e42c1f43b98c097995137d644b69245 ] kcalloc() may fail. When WS is non-zero and allocation fails, ectx.ws remains NULL while ectx.ws_size is set, leading to a potential NULL pointer dereference in atom_get_src_int() when accessing WS entries. Return -ENOMEM on allocation failure to avoid the NULL dereference. Signed-off-by: Guangshuo Li <lgs201920130244(a)gmail.com> Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Conflicts: drivers/gpu/drm/amd/amdgpu/atom.c [context conflict] Signed-off-by: Xinyu Zheng <zhengxinyu6(a)huawei.com> --- drivers/gpu/drm/amd/amdgpu/atom.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/amdgpu/atom.c b/drivers/gpu/drm/amd/amdgpu/atom.c index 4cfc786699c7..11181ad13f31 100644 --- a/drivers/gpu/drm/amd/amdgpu/atom.c +++ b/drivers/gpu/drm/amd/amdgpu/atom.c @@ -1227,6 +1227,10 @@ static int amdgpu_atom_execute_table_locked(struct atom_context *ctx, int index, ectx.last_jump = 0; if (ws) ectx.ws = kcalloc(4, ws, GFP_KERNEL); + if (!ectx.ws) { + ret = -ENOMEM; + goto free; + } else ectx.ws = NULL; -- 2.34.1

2 1

[PATCH openEuler-1.0-LTS] nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing
by Li Lingfeng 18 Dec '25

18 Dec '25

From: Al Viro <viro(a)zeniv.linux.org.uk> mainline inclusion from mainline-v6.18-rc1 commit a890a2e339b929dbd843328f9a92a1625404fe63 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDEWK CVE: CVE-2025-68185 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- Theoretically it's an oopsable race, but I don't believe one can manage to hit it on real hardware; might become doable on a KVM, but it still won't be easy to attack. Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of put_unaligned_be64(), we can put that under ->d_lock and be done with that. Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Anna Schumaker <anna.schumaker(a)oracle.com> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfs/nfs4proc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index 29cb861ae449..83cb9f013fe0 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -352,7 +352,9 @@ static void nfs4_setup_readdir(u64 cookie, __be32 *verifier, struct dentry *dent *p++ = htonl(attrs); /* bitmap */ *p++ = htonl(12); /* attribute buffer length */ *p++ = htonl(NF4DIR); + spin_lock(&dentry->d_lock); p = xdr_encode_hyper(p, NFS_FILEID(d_inode(dentry->d_parent))); + spin_unlock(&dentry->d_lock); readdir->pgbase = (char *)p - (char *)start; readdir->count -= readdir->pgbase; -- 2.52.0

2 1

[PATCH OLK-6.6] nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing
by Li Lingfeng 18 Dec '25

18 Dec '25

From: Al Viro <viro(a)zeniv.linux.org.uk> stable inclusion from stable-v6.6.117 commit eacfd08b26a062f1095b18719715bc82ad35312e category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDEWK CVE: CVE-2025-68185 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a890a2e339b929dbd843328f9a92a1625404fe63 ] Theoretically it's an oopsable race, but I don't believe one can manage to hit it on real hardware; might become doable on a KVM, but it still won't be easy to attack. Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of put_unaligned_be64(), we can put that under ->d_lock and be done with that. Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Anna Schumaker <anna.schumaker(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfs/nfs4proc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index e197bea6c6a9..5be8f1aceab8 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -362,7 +362,9 @@ static void nfs4_setup_readdir(u64 cookie, __be32 *verifier, struct dentry *dent *p++ = htonl(attrs); /* bitmap */ *p++ = htonl(12); /* attribute buffer length */ *p++ = htonl(NF4DIR); + spin_lock(&dentry->d_lock); p = xdr_encode_hyper(p, NFS_FILEID(d_inode(dentry->d_parent))); + spin_unlock(&dentry->d_lock); readdir->pgbase = (char *)p - (char *)start; readdir->count -= readdir->pgbase; -- 2.52.0

2 1

[PATCH OLK-5.10] nfs4_setup_readdir(): insufficient locking for ->d_parent->d_inode dereferencing
by Li Lingfeng 18 Dec '25

18 Dec '25

From: Al Viro <viro(a)zeniv.linux.org.uk> stable inclusion from stable-v5.10.247 commit e6cafe71eb3b5579b245ba1bd528a181e77f3df1 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDEWK CVE: CVE-2025-68185 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- [ Upstream commit a890a2e339b929dbd843328f9a92a1625404fe63 ] Theoretically it's an oopsable race, but I don't believe one can manage to hit it on real hardware; might become doable on a KVM, but it still won't be easy to attack. Anyway, it's easy to deal with - since xdr_encode_hyper() is just a call of put_unaligned_be64(), we can put that under ->d_lock and be done with that. Signed-off-by: Al Viro <viro(a)zeniv.linux.org.uk> Signed-off-by: Anna Schumaker <anna.schumaker(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- fs/nfs/nfs4proc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c index 35c15d20a84e..39a337c00c5a 100644 --- a/fs/nfs/nfs4proc.c +++ b/fs/nfs/nfs4proc.c @@ -368,7 +368,9 @@ static void nfs4_setup_readdir(u64 cookie, __be32 *verifier, struct dentry *dent *p++ = htonl(attrs); /* bitmap */ *p++ = htonl(12); /* attribute buffer length */ *p++ = htonl(NF4DIR); + spin_lock(&dentry->d_lock); p = xdr_encode_hyper(p, NFS_FILEID(d_inode(dentry->d_parent))); + spin_unlock(&dentry->d_lock); readdir->pgbase = (char *)p - (char *)start; readdir->count -= readdir->pgbase; -- 2.52.0

2 1