- Kernel - mailweb.openeuler.org

[PATCH OLK-5.10] usb: storage: Fix memory leak in USB bulk transport
by Li Lingfeng 18 Dec '25

18 Dec '25

From: Desnes Nunes <desnesn(a)redhat.com> stable inclusion from stable-v5.10.247 commit 83f0241959831586d9b6d47f6bd5d3dec8f43bf0 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDF46 CVE: CVE-2025-68288 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit 41e99fe2005182139b1058db71f0d241f8f0078c upstream. A kernel memory leak was identified by the 'ioctl_sg01' test from Linux Test Project (LTP). The following bytes were mainly observed: 0x53425355. When USB storage devices incorrectly skip the data phase with status data, the code extracts/validates the CSW from the sg buffer, but fails to clear it afterwards. This leaves status protocol data in srb's transfer buffer, such as the US_BULK_CS_SIGN 'USBS' signature observed here. Thus, this can lead to USB protocols leaks to user space through SCSI generic (/dev/sg*) interfaces, such as the one seen here when the LTP test requested 512 KiB. Fix the leak by zeroing the CSW data in srb's transfer buffer immediately after the validation of devices that skip data phase. Note: Differently from CVE-2018-1000204, which fixed a big leak by zero- ing pages at allocation time, this leak occurs after allocation, when USB protocol data is written to already-allocated sg pages. Fixes: a45b599ad808 ("scsi: sg: allocate with __GFP_ZERO in sg_build_indirect()") Cc: stable <stable(a)kernel.org> Signed-off-by: Desnes Nunes <desnesn(a)redhat.com> Reviewed-by: Alan Stern <stern(a)rowland.harvard.edu> Link: https://patch.msgid.link/20251031043436.55929-1-desnesn@redhat.com Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/usb/storage/transport.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c index 7cc8813f5d8c..9e24d51c3297 100644 --- a/drivers/usb/storage/transport.c +++ b/drivers/usb/storage/transport.c @@ -1199,7 +1199,23 @@ int usb_stor_Bulk_transport(struct scsi_cmnd *srb, struct us_data *us) US_BULK_CS_WRAP_LEN && bcs->Signature == cpu_to_le32(US_BULK_CS_SIGN)) { + unsigned char buf[US_BULK_CS_WRAP_LEN]; + usb_stor_dbg(us, "Device skipped data phase\n"); + + /* + * Devices skipping data phase might leave CSW data in srb's + * transfer buffer. Zero it to prevent USB protocol leakage. + */ + sg = NULL; + offset = 0; + memset(buf, 0, sizeof(buf)); + if (usb_stor_access_xfer_buf(buf, + US_BULK_CS_WRAP_LEN, srb, &sg, + &offset, TO_XFER_BUF) != + US_BULK_CS_WRAP_LEN) + usb_stor_dbg(us, "Failed to clear CSW data\n"); + scsi_set_resid(srb, transfer_length); goto skipped_data_phase; } -- 2.52.0

2 1

[PATCH openEuler-1.0-LTS] scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()
by Li Lingfeng 18 Dec '25

18 Dec '25

From: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> mainline inclusion from mainline-v6.18-rc7 commit e6965188f84a7883e6a0d3448e86b0cf29b24dfc category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDEZL CVE: CVE-2025-68229 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… -------------------------------- If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: <TASK> configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ... Cc: stable(a)vger.kernel.org Fixes: 2628b352c3d4 ("tcm_loop: Show address of tpg in configfs") Signed-off-by: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> Reviewed-by: Chaitanya Kulkarni <kch(a)nvidia.com> Reviewed-by: Allen Pais <apais(a)linux.microsoft.com> Link: https://patch.msgid.link/1762370746-6304-1-git-send-email-hamzamahfooz@linu… Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Li Lingfeng <lilingfeng3(a)huawei.com> --- drivers/target/loopback/tcm_loop.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/target/loopback/tcm_loop.c b/drivers/target/loopback/tcm_loop.c index bc8918f382e4..f7c611a1a530 100644 --- a/drivers/target/loopback/tcm_loop.c +++ b/drivers/target/loopback/tcm_loop.c @@ -963,6 +963,9 @@ static ssize_t tcm_loop_tpg_address_show(struct config_item *item, struct tcm_loop_tpg, tl_se_tpg); struct tcm_loop_hba *tl_hba = tl_tpg->tl_hba; + if (!tl_hba->sh) + return -ENODEV; + return snprintf(page, PAGE_SIZE, "%d:0:%d\n", tl_hba->sh->host_no, tl_tpg->tl_tpgt); } -- 2.52.0

2 1

[PATCH OLK-6.6] scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()
by Li Lingfeng 18 Dec '25

18 Dec '25

From: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> stable inclusion from stable-v6.6.118 commit a6ef60898ddaf1414592ce3e5b0d94276d631663 category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDEZL CVE: CVE-2025-68229 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit e6965188f84a7883e6a0d3448e86b0cf29b24dfc upstream. If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: <TASK> configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ... Cc: stable(a)vger.kernel.org Fixes: 2628b352c3d4 ("tcm_loop: Show address of tpg in configfs") Signed-off-by: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> Reviewed-by: Chaitanya Kulkarni <kch(a)nvidia.com> Reviewed-by: Allen Pais <apais(a)linux.microsoft.com> Link: https://patch.msgid.link/1762370746-6304-1-git-send-email-hamzamahfooz@linu… 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/target/loopback/tcm_loop.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/target/loopback/tcm_loop.c b/drivers/target/loopback/tcm_loop.c index 4ec99a55ac30..db13c6a379d8 100644 --- a/drivers/target/loopback/tcm_loop.c +++ b/drivers/target/loopback/tcm_loop.c @@ -893,6 +893,9 @@ static ssize_t tcm_loop_tpg_address_show(struct config_item *item, struct tcm_loop_tpg, tl_se_tpg); struct tcm_loop_hba *tl_hba = tl_tpg->tl_hba; + if (!tl_hba->sh) + return -ENODEV; + return snprintf(page, PAGE_SIZE, "%d:0:%d\n", tl_hba->sh->host_no, tl_tpg->tl_tpgt); } -- 2.52.0

2 1

[PATCH OLK-5.10] scsi: target: tcm_loop: Fix segfault in tcm_loop_tpg_address_show()
by Li Lingfeng 18 Dec '25

18 Dec '25

From: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> stable inclusion from stable-v5.10.247 commit 3d8c517f6eb27e47b1a198e05f8023038329b40b category: bugfix bugzilla: https://gitee.com/src-openeuler/kernel/issues/IDDEZL CVE: CVE-2025-68229 Reference: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id… -------------------------------- commit e6965188f84a7883e6a0d3448e86b0cf29b24dfc upstream. If the allocation of tl_hba->sh fails in tcm_loop_driver_probe() and we attempt to dereference it in tcm_loop_tpg_address_show() we will get a segfault, see below for an example. So, check tl_hba->sh before dereferencing it. Unable to allocate struct scsi_host BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcm_loop_tpg_address_show+0x2e/0x50 [tcm_loop] ... Call Trace: <TASK> configfs_read_iter+0x12d/0x1d0 [configfs] vfs_read+0x1b5/0x300 ksys_read+0x6f/0xf0 ... Cc: stable(a)vger.kernel.org Fixes: 2628b352c3d4 ("tcm_loop: Show address of tpg in configfs") Signed-off-by: Hamza Mahfooz <hamzamahfooz(a)linux.microsoft.com> Reviewed-by: Chaitanya Kulkarni <kch(a)nvidia.com> Reviewed-by: Allen Pais <apais(a)linux.microsoft.com> Link: https://patch.msgid.link/1762370746-6304-1-git-send-email-hamzamahfooz@linu… 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/target/loopback/tcm_loop.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/target/loopback/tcm_loop.c b/drivers/target/loopback/tcm_loop.c index 5ae5d94c5b93..9360148e1f4e 100644 --- a/drivers/target/loopback/tcm_loop.c +++ b/drivers/target/loopback/tcm_loop.c @@ -933,6 +933,9 @@ static ssize_t tcm_loop_tpg_address_show(struct config_item *item, struct tcm_loop_tpg, tl_se_tpg); struct tcm_loop_hba *tl_hba = tl_tpg->tl_hba; + if (!tl_hba->sh) + return -ENODEV; + return snprintf(page, PAGE_SIZE, "%d:0:%d\n", tl_hba->sh->host_no, tl_tpg->tl_tpgt); } -- 2.52.0

2 1

[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