Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

285 participants
124115 discussions

[PATCH] media: i2c/tw9906: Fix potential memory leak in tw9906_probe()

by Abdun Nihaal

In one of the error paths in tw9906_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path. Cc: stable(a)vger.kernel.org Fixes: a000e9a02b58 ("[media] tw9906: add Techwell tw9906 video decoder") Signed-off-by: Abdun Nihaal <nihaal(a)cse.iitm.ac.in> --- Compile tested only. Issue found using static analysis. drivers/media/i2c/tw9906.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/i2c/tw9906.c b/drivers/media/i2c/tw9906.c index 6220f4fddbab..0ab43fe42d7f 100644 --- a/drivers/media/i2c/tw9906.c +++ b/drivers/media/i2c/tw9906.c @@ -196,6 +196,7 @@ static int tw9906_probe(struct i2c_client *client) if (write_regs(sd, initial_registers) < 0) { v4l2_err(client, "error initializing TW9906\n"); + v4l2_ctrl_handler_free(hdl); return -EINVAL; } -- 2.43.0

2 weeks, 3 days

[PATCH] media: i2c/tw9903: Fix potential memory leak in tw9903_probe()

by Abdun Nihaal

In one of the error paths in tw9903_probe(), the memory allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std() is not freed. Fix that by calling v4l2_ctrl_handler_free() on the handler in that error path. Cc: stable(a)vger.kernel.org Fixes: 0890ec19c65d ("[media] tw9903: add new tw9903 video decoder") Signed-off-by: Abdun Nihaal <nihaal(a)cse.iitm.ac.in> --- Compile tested only. Issue found using static analysis. drivers/media/i2c/tw9903.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/media/i2c/tw9903.c b/drivers/media/i2c/tw9903.c index b996a05e56f2..c3eafd5d5dc8 100644 --- a/drivers/media/i2c/tw9903.c +++ b/drivers/media/i2c/tw9903.c @@ -228,6 +228,7 @@ static int tw9903_probe(struct i2c_client *client) if (write_regs(sd, initial_registers) < 0) { v4l2_err(client, "error initializing TW9903\n"); + v4l2_ctrl_handler_free(hdl); return -EINVAL; } -- 2.43.0

2 weeks, 3 days

+ mm-memory-failure-teach-kill_accessing_process-to-accept-hugetlb-tail-page-pfn.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/memory-failure: teach kill_accessing_process to accept hugetlb tail page pfn has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-memory-failure-teach-kill_accessing_process-to-accept-hugetlb-tail-page-pfn.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: Jane Chu <jane.chu(a)oracle.com> Subject: mm/memory-failure: teach kill_accessing_process to accept hugetlb tail page pfn Date: Mon, 22 Dec 2025 18:21:12 -0700 When a hugetlb folio is being poisoned again, try_memory_failure_hugetlb() passed head pfn to kill_accessing_process(), that is not right. The precise pfn of the poisoned page should be used in order to determine the precise vaddr as the SIGBUS payload. This issue has already been taken care of in the normal path, that is, hwpoison_user_mappings(), see [1][2]. Furthermore, for [3] to work correctly in the hugetlb repoisoning case, it's essential to inform VM the precise poisoned page, not the head page. Link: https://lkml.kernel.org/r/20251223012113.370674-2-jane.chu@oracle.com Link: https://lkml.kernel.org/r/20231218135837.3310403-1-willy@infradead.org [1] Link: https://lkml.kernel.org/r/20250224211445.2663312-1-jane.chu@oracle.com [2] Link: https://lore.kernel.org/lkml/20251116013223.1557158-1-jiaqiyan@google.com/ [3] Signed-off-by: Jane Chu <jane.chu(a)oracle.com> Reviewed-by: Liam R. Howlett <Liam.Howlett(a)oracle.com> Cc: "David Hildenbrand (Red Hat)" <david(a)kernel.org> Cc: David Rientjes <rientjes(a)google.com> Cc: Jiaqi Yan <jiaqiyan(a)google.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Miaohe Lin <linmiaohe(a)huawei.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: William Roche <william.roche(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory-failure.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) --- a/mm/memory-failure.c~mm-memory-failure-teach-kill_accessing_process-to-accept-hugetlb-tail-page-pfn +++ a/mm/memory-failure.c @@ -692,6 +692,8 @@ static int check_hwpoisoned_entry(pte_t unsigned long poisoned_pfn, struct to_kill *tk) { unsigned long pfn = 0; + unsigned long hwpoison_vaddr; + unsigned long mask; if (pte_present(pte)) { pfn = pte_pfn(pte); @@ -702,10 +704,12 @@ static int check_hwpoisoned_entry(pte_t pfn = softleaf_to_pfn(entry); } - if (!pfn || pfn != poisoned_pfn) + mask = ~((1UL << (shift - PAGE_SHIFT)) - 1); + if (!pfn || ((pfn & mask) != (poisoned_pfn & mask))) return 0; - set_to_kill(tk, addr, shift); + hwpoison_vaddr = addr + ((poisoned_pfn - pfn) << PAGE_SHIFT); + set_to_kill(tk, hwpoison_vaddr, shift); return 1; } @@ -2038,10 +2042,8 @@ retry: return 0; case MF_HUGETLB_ALREADY_POISONED: case MF_HUGETLB_ACC_EXISTING_POISON: - if (flags & MF_ACTION_REQUIRED) { - folio = page_folio(p); - res = kill_accessing_process(current, folio_pfn(folio), flags); - } + if (flags & MF_ACTION_REQUIRED) + res = kill_accessing_process(current, pfn, flags); if (res == MF_HUGETLB_ALREADY_POISONED) action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED); else _ Patches currently in -mm which might be from jane.chu(a)oracle.com are mm-memory-failure-fix-missing-mf_stats-count-in-hugetlb-poison.patch mm-memory-failure-teach-kill_accessing_process-to-accept-hugetlb-tail-page-pfn.patch

2 weeks, 3 days

+ mm-memory-failure-fix-missing-mf_stats-count-in-hugetlb-poison.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/memory-failure: fix missing ->mf_stats count in hugetlb poison has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-memory-failure-fix-missing-mf_stats-count-in-hugetlb-poison.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: Jane Chu <jane.chu(a)oracle.com> Subject: mm/memory-failure: fix missing ->mf_stats count in hugetlb poison Date: Mon, 22 Dec 2025 18:21:11 -0700 When a newly poisoned subpage ends up in an already poisoned hugetlb folio, 'num_poisoned_pages' is incremented, but the per node ->mf_stats is not. Fix the inconsistency by designating action_result() to update them both. While at it, define __get_huge_page_for_hwpoison() return values in terms of symbol names for better readibility. Also rename folio_set_hugetlb_hwpoison() to hugetlb_update_hwpoison() since the function does more than the conventional bit setting and the fact three possible return values are expected. Link: https://lkml.kernel.org/r/20251223012113.370674-1-jane.chu@oracle.com Fixes: 18f41fa616ee ("mm: memory-failure: bump memory failure stats to pglist_data") Signed-off-by: Jane Chu <jane.chu(a)oracle.com> Cc: "David Hildenbrand (Red Hat)" <david(a)kernel.org> Cc: David Rientjes <rientjes(a)google.com> Cc: Jiaqi Yan <jiaqiyan(a)google.com> Cc: Liam R. Howlett <Liam.Howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Miaohe Lin <linmiaohe(a)huawei.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Muchun Song <muchun.song(a)linux.dev> Cc: Oscar Salvador <osalvador(a)suse.de> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: William Roche <william.roche(a)oracle.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/memory-failure.c | 56 ++++++++++++++++++++++++------------------ 1 file changed, 33 insertions(+), 23 deletions(-) --- a/mm/memory-failure.c~mm-memory-failure-fix-missing-mf_stats-count-in-hugetlb-poison +++ a/mm/memory-failure.c @@ -1883,12 +1883,18 @@ static unsigned long __folio_free_raw_hw return count; } -static int folio_set_hugetlb_hwpoison(struct folio *folio, struct page *page) +#define MF_HUGETLB_ALREADY_POISONED 3 /* already poisoned */ +#define MF_HUGETLB_ACC_EXISTING_POISON 4 /* accessed existing poisoned page */ +/* + * Set hugetlb folio as hwpoisoned, update folio private raw hwpoison list + * to keep track of the poisoned pages. + */ +static int hugetlb_update_hwpoison(struct folio *folio, struct page *page) { struct llist_head *head; struct raw_hwp_page *raw_hwp; struct raw_hwp_page *p; - int ret = folio_test_set_hwpoison(folio) ? -EHWPOISON : 0; + int ret = folio_test_set_hwpoison(folio) ? MF_HUGETLB_ALREADY_POISONED : 0; /* * Once the hwpoison hugepage has lost reliable raw error info, @@ -1896,20 +1902,18 @@ static int folio_set_hugetlb_hwpoison(st * so skip to add additional raw error info. */ if (folio_test_hugetlb_raw_hwp_unreliable(folio)) - return -EHWPOISON; + return MF_HUGETLB_ALREADY_POISONED; + head = raw_hwp_list_head(folio); llist_for_each_entry(p, head->first, node) { if (p->page == page) - return -EHWPOISON; + return MF_HUGETLB_ACC_EXISTING_POISON; } raw_hwp = kmalloc(sizeof(struct raw_hwp_page), GFP_ATOMIC); if (raw_hwp) { raw_hwp->page = page; llist_add(&raw_hwp->node, head); - /* the first error event will be counted in action_result(). */ - if (ret) - num_poisoned_pages_inc(page_to_pfn(page)); } else { /* * Failed to save raw error info. We no longer trace all @@ -1955,32 +1959,30 @@ void folio_clear_hugetlb_hwpoison(struct folio_free_raw_hwp(folio, true); } +#define MF_HUGETLB_FREED 0 /* freed hugepage */ +#define MF_HUGETLB_IN_USED 1 /* in-use hugepage */ +#define MF_NOT_HUGETLB 2 /* not a hugepage */ + /* * Called from hugetlb code with hugetlb_lock held. - * - * Return values: - * 0 - free hugepage - * 1 - in-use hugepage - * 2 - not a hugepage - * -EBUSY - the hugepage is busy (try to retry) - * -EHWPOISON - the hugepage is already hwpoisoned */ int __get_huge_page_for_hwpoison(unsigned long pfn, int flags, bool *migratable_cleared) { struct page *page = pfn_to_page(pfn); struct folio *folio = page_folio(page); - int ret = 2; /* fallback to normal page handling */ + int ret = MF_NOT_HUGETLB; bool count_increased = false; + int rc; if (!folio_test_hugetlb(folio)) goto out; if (flags & MF_COUNT_INCREASED) { - ret = 1; + ret = MF_HUGETLB_IN_USED; count_increased = true; } else if (folio_test_hugetlb_freed(folio)) { - ret = 0; + ret = MF_HUGETLB_FREED; } else if (folio_test_hugetlb_migratable(folio)) { ret = folio_try_get(folio); if (ret) @@ -1991,8 +1993,9 @@ int __get_huge_page_for_hwpoison(unsigne goto out; } - if (folio_set_hugetlb_hwpoison(folio, page)) { - ret = -EHWPOISON; + rc = hugetlb_update_hwpoison(folio, page); + if (rc >= MF_HUGETLB_ALREADY_POISONED) { + ret = rc; goto out; } @@ -2029,22 +2032,29 @@ static int try_memory_failure_hugetlb(un *hugetlb = 1; retry: res = get_huge_page_for_hwpoison(pfn, flags, &migratable_cleared); - if (res == 2) { /* fallback to normal page handling */ + switch (res) { + case MF_NOT_HUGETLB: /* fallback to normal page handling */ *hugetlb = 0; return 0; - } else if (res == -EHWPOISON) { + case MF_HUGETLB_ALREADY_POISONED: + case MF_HUGETLB_ACC_EXISTING_POISON: if (flags & MF_ACTION_REQUIRED) { folio = page_folio(p); res = kill_accessing_process(current, folio_pfn(folio), flags); } - action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED); + if (res == MF_HUGETLB_ALREADY_POISONED) + action_result(pfn, MF_MSG_ALREADY_POISONED, MF_FAILED); + else + action_result(pfn, MF_MSG_HUGE, MF_FAILED); return res; - } else if (res == -EBUSY) { + case -EBUSY: if (!(flags & MF_NO_RETRY)) { flags |= MF_NO_RETRY; goto retry; } return action_result(pfn, MF_MSG_GET_HWPOISON, MF_IGNORED); + default: + break; } folio = page_folio(p); _ Patches currently in -mm which might be from jane.chu(a)oracle.com are mm-memory-failure-fix-missing-mf_stats-count-in-hugetlb-poison.patch mm-memory-failure-teach-kill_accessing_process-to-accept-hugetlb-tail-page-pfn.patch

2 weeks, 3 days

+ mm-take-into-account-mm_cid-size-for-mm_struct-static-definitions.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: mm: take into account mm_cid size for mm_struct static definitions has been added to the -mm mm-new branch. Its filename is mm-take-into-account-mm_cid-size-for-mm_struct-static-definitions.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. The mm-new branch of mm.git is not included in linux-next Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Subject: mm: take into account mm_cid size for mm_struct static definitions Date: Sun, 21 Dec 2025 18:29:24 -0500 Both init_mm and efi_mm static definitions need to make room for the 2 mm_cid cpumasks. This fixes possible out-of-bounds accesses to init_mm and efi_mm. Link: https://lkml.kernel.org/r/20251221232926.450602-4-mathieu.desnoyers@efficio… Fixes: af7f588d8f73 ("sched: Introduce per-memory-map concurrency ID") Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Mark Brown <broonie(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/mm_types.h | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) --- a/include/linux/mm_types.h~mm-take-into-account-mm_cid-size-for-mm_struct-static-definitions +++ a/include/linux/mm_types.h @@ -1368,7 +1368,7 @@ extern struct mm_struct init_mm; #define MM_STRUCT_FLEXIBLE_ARRAY_INIT \ { \ - [0 ... sizeof(cpumask_t)-1] = 0 \ + [0 ... sizeof(cpumask_t) + MM_CID_STATIC_SIZE - 1] = 0 \ } /* Pointer magic because the dynamic array size confuses some compilers. */ @@ -1500,7 +1500,7 @@ static inline int mm_alloc_cid_noprof(st mm_init_cid(mm, p); return 0; } -#define mm_alloc_cid(...) alloc_hooks(mm_alloc_cid_noprof(__VA_ARGS__)) +# define mm_alloc_cid(...) alloc_hooks(mm_alloc_cid_noprof(__VA_ARGS__)) static inline void mm_destroy_cid(struct mm_struct *mm) { @@ -1514,6 +1514,8 @@ static inline unsigned int mm_cid_size(v return cpumask_size() + bitmap_size(num_possible_cpus()); } +/* Use NR_CPUS as worse case for static allocation. */ +# define MM_CID_STATIC_SIZE (2 * sizeof(cpumask_t)) #else /* CONFIG_SCHED_MM_CID */ static inline void mm_init_cid(struct mm_struct *mm, struct task_struct *p) { } static inline int mm_alloc_cid(struct mm_struct *mm, struct task_struct *p) { return 0; } @@ -1522,6 +1524,7 @@ static inline unsigned int mm_cid_size(v { return 0; } +# define MM_CID_STATIC_SIZE 0 #endif /* CONFIG_SCHED_MM_CID */ struct mmu_gather; _ Patches currently in -mm which might be from mathieu.desnoyers(a)efficios.com are lib-introduce-hierarchical-per-cpu-counters.patch mm-fix-oom-killer-inaccuracy-on-large-many-core-systems.patch mm-implement-precise-oom-killer-task-selection.patch mm-add-missing-static-initializer-for-init_mm-mm_cidlock.patch mm-rename-cpu_bitmap-field-to-flexible_array.patch mm-take-into-account-mm_cid-size-for-mm_struct-static-definitions.patch mm-take-into-account-hierarchical-percpu-tree-items-for-static-mm_struct-definitions.patch tsacct-skip-all-kernel-threads.patch

2 weeks, 3 days

+ mm-add-missing-static-initializer-for-init_mm-mm_cidlock.patch added to mm-new branch

by Andrew Morton

The patch titled Subject: mm: add missing static initializer for init_mm::mm_cid.lock has been added to the -mm mm-new branch. Its filename is mm-add-missing-static-initializer-for-init_mm-mm_cidlock.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-new branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Note, mm-new is a provisional staging ground for work-in-progress patches, and acceptance into mm-new is a notification for others take notice and to finish up reviews. Please do not hesitate to respond to review feedback and post updated versions to replace or incrementally fixup patches in mm-new. The mm-new branch of mm.git is not included in linux-next Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Subject: mm: add missing static initializer for init_mm::mm_cid.lock Date: Sun, 21 Dec 2025 18:29:22 -0500 Patch series "MM_CID and HPCC mm_struct static init fixes". Mark Brown reported a regression [1] on linux next due to the hierarchical percpu counters (HPCC). You mentioned they were only in mm-new (and therefore not pulled into -next) [2], but it looks like they got more exposure that we expected. :) This bug hunting got me to fix static initialization issues in both MM_CID (for upstream) and HPCC (mm-new). Mark tested my series and confirmed that it fixes his issues. This patch (of 5): Initialize the mm_cid.lock struct member of init_mm. Link: https://lkml.kernel.org/r/20251221232926.450602-2-mathieu.desnoyers@efficio… Fixes: 8cea569ca785 ("sched/mmcid: Use proper data structures") Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers(a)efficios.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Mark Brown <broonie(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/init-mm.c | 3 +++ 1 file changed, 3 insertions(+) --- a/mm/init-mm.c~mm-add-missing-static-initializer-for-init_mm-mm_cidlock +++ a/mm/init-mm.c @@ -44,6 +44,9 @@ struct mm_struct init_mm = { .mm_lock_seq = SEQCNT_ZERO(init_mm.mm_lock_seq), #endif .user_ns = &init_user_ns, +#ifdef CONFIG_SCHED_MM_CID + .mm_cid.lock = __RAW_SPIN_LOCK_UNLOCKED(init_mm.mm_cid.lock), +#endif .cpu_bitmap = CPU_BITS_NONE, INIT_MM_CONTEXT(init_mm) }; _ Patches currently in -mm which might be from mathieu.desnoyers(a)efficios.com are lib-introduce-hierarchical-per-cpu-counters.patch mm-fix-oom-killer-inaccuracy-on-large-many-core-systems.patch mm-implement-precise-oom-killer-task-selection.patch mm-add-missing-static-initializer-for-init_mm-mm_cidlock.patch mm-rename-cpu_bitmap-field-to-flexible_array.patch mm-take-into-account-mm_cid-size-for-mm_struct-static-definitions.patch mm-take-into-account-hierarchical-percpu-tree-items-for-static-mm_struct-definitions.patch tsacct-skip-all-kernel-threads.patch

2 weeks, 3 days

+ lib-buildid-use-__kernel_read-for-sleepable-context.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: lib/buildid: use __kernel_read() for sleepable context has been added to the -mm mm-hotfixes-unstable branch. Its filename is lib-buildid-use-__kernel_read-for-sleepable-context.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: Shakeel Butt <shakeel.butt(a)linux.dev> Subject: lib/buildid: use __kernel_read() for sleepable context Date: Mon, 22 Dec 2025 12:58:59 -0800 Prevent a "BUG: unable to handle kernel NULL pointer dereference in filemap_read_folio". For the sleepable context, convert freader to use __kernel_read() instead of direct page cache access via read_cache_folio(). This simplifies the faultable code path by using the standard kernel file reading interface which handles all the complexity of reading file data. At the moment we are not changing the code for non-sleepable context which uses filemap_get_folio() and only succeeds if the target folios are already in memory and up-to-date. The reason is to keep the patch simple and easier to backport to stable kernels. Syzbot repro does not crash the kernel anymore and the selftests run successfully. In the follow up we will make __kernel_read() with IOCB_NOWAIT work for non-sleepable contexts. In addition, I would like to replace the secretmem check with a more generic approach and will add fstest for the buildid code. Link: https://lkml.kernel.org/r/20251222205859.3968077-1-shakeel.butt@linux.dev Fixes: ad41251c290d ("lib/buildid: implement sleepable build_id_parse() API") Reported-by: syzbot+09b7d050e4806540153d(a)syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=09b7d050e4806540153d Signed-off-by: Shakeel Butt <shakeel.butt(a)linux.dev> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Cc: Alexei Starovoitov <ast(a)kernel.org> Cc: Andrii Nakryiko <andrii(a)kernel.org> Cc: Daniel Borkman <daniel(a)iogearbox.net> Cc: "Darrick J. Wong" <djwong(a)kernel.org> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- lib/buildid.c | 32 ++++++++++++++++++++------------ 1 file changed, 20 insertions(+), 12 deletions(-) --- a/lib/buildid.c~lib-buildid-use-__kernel_read-for-sleepable-context +++ a/lib/buildid.c @@ -5,6 +5,7 @@ #include <linux/elf.h> #include <linux/kernel.h> #include <linux/pagemap.h> +#include <linux/fs.h> #include <linux/secretmem.h> #define BUILD_ID 3 @@ -46,20 +47,9 @@ static int freader_get_folio(struct frea freader_put_folio(r); - /* reject secretmem folios created with memfd_secret() */ - if (secretmem_mapping(r->file->f_mapping)) - return -EFAULT; - + /* only use page cache lookup - fail if not already cached */ r->folio = filemap_get_folio(r->file->f_mapping, file_off >> PAGE_SHIFT); - /* if sleeping is allowed, wait for the page, if necessary */ - if (r->may_fault && (IS_ERR(r->folio) || !folio_test_uptodate(r->folio))) { - filemap_invalidate_lock_shared(r->file->f_mapping); - r->folio = read_cache_folio(r->file->f_mapping, file_off >> PAGE_SHIFT, - NULL, r->file); - filemap_invalidate_unlock_shared(r->file->f_mapping); - } - if (IS_ERR(r->folio) || !folio_test_uptodate(r->folio)) { if (!IS_ERR(r->folio)) folio_put(r->folio); @@ -97,6 +87,24 @@ const void *freader_fetch(struct freader return r->data + file_off; } + /* reject secretmem folios created with memfd_secret() */ + if (secretmem_mapping(r->file->f_mapping)) { + r->err = -EFAULT; + return NULL; + } + + /* use __kernel_read() for sleepable context */ + if (r->may_fault) { + ssize_t ret; + + ret = __kernel_read(r->file, r->buf, sz, &file_off); + if (ret != sz) { + r->err = (ret < 0) ? ret : -EIO; + return NULL; + } + return r->buf; + } + /* fetch or reuse folio for given file offset */ r->err = freader_get_folio(r, file_off); if (r->err) _ Patches currently in -mm which might be from shakeel.butt(a)linux.dev are mm-memcg-fix-unit-conversion-for-k-macro-in-oom-log.patch lib-buildid-use-__kernel_read-for-sleepable-context.patch

2 weeks, 4 days

[PATCH] rapidio: fix a resource leak when rio_add_device() fails

by Haoxiang Li

If rio_add_device() fails, call rio_free_net() to unregister the net device registered by rio_add_net(). Fixes: e8de370188d0 ("rapidio: add mport char device driver") Cc: stable(a)vger.kernel.org Signed-off-by: Haoxiang Li <lihaoxiang(a)isrc.iscas.ac.cn> --- drivers/rapidio/devices/rio_mport_cdev.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/rapidio/devices/rio_mport_cdev.c b/drivers/rapidio/devices/rio_mport_cdev.c index 995cfeca972b..4a804b4ad6f7 100644 --- a/drivers/rapidio/devices/rio_mport_cdev.c +++ b/drivers/rapidio/devices/rio_mport_cdev.c @@ -1789,6 +1789,7 @@ static int rio_mport_add_riodev(struct mport_cdev_priv *priv, err = rio_add_device(rdev); if (err) { put_device(&rdev->dev); + rio_free_net(net); return err; } -- 2.25.1

2 weeks, 4 days

[PATCH net v2] virtio-net: enable all napis before scheduling refill work

by Bui Quang Minh

Calling napi_disable() on an already disabled napi can cause the deadlock. In commit 4bc12818b363 ("virtio-net: disable delayed refill when pausing rx"), to avoid the deadlock, when pausing the RX in virtnet_rx_pause[_all](), we disable and cancel the delayed refill work. However, in the virtnet_rx_resume_all(), we enable the delayed refill work too early before enabling all the receive queue napis. The deadlock can be reproduced by running selftests/drivers/net/hw/xsk_reconfig.py with multiqueue virtio-net device and inserting a cond_resched() inside the for loop in virtnet_rx_resume_all() to increase the success rate. Because the worker processing the delayed refilled work runs on the same CPU as virtnet_rx_resume_all(), a reschedule is needed to cause the deadlock. In real scenario, the contention on netdev_lock can cause the reschedule. This fixes the deadlock by ensuring all receive queue's napis are enabled before we enable the delayed refill work in virtnet_rx_resume_all() and virtnet_open(). Fixes: 4bc12818b363 ("virtio-net: disable delayed refill when pausing rx") Reported-by: Paolo Abeni <pabeni(a)redhat.com> Closes: https://netdev-ctrl.bots.linux.dev/logs/vmksft/drv-hw-dbg/results/400961/3-… Cc: stable(a)vger.kernel.org Signed-off-by: Bui Quang Minh <minhquangbui99(a)gmail.com> --- Changes in v2: - Move try_fill_recv() before rx napi_enable() - Link to v1: https://lore.kernel.org/netdev/20251208153419.18196-1-minhquangbui99@gmail.… --- drivers/net/virtio_net.c | 71 +++++++++++++++++++++++++--------------- 1 file changed, 45 insertions(+), 26 deletions(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 8e04adb57f52..4e08880a9467 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -3214,21 +3214,31 @@ static void virtnet_update_settings(struct virtnet_info *vi) static int virtnet_open(struct net_device *dev) { struct virtnet_info *vi = netdev_priv(dev); + bool schedule_refill = false; int i, err; - enable_delayed_refill(vi); - + /* - We must call try_fill_recv before enabling napi of the same receive + * queue so that it doesn't race with the call in virtnet_receive. + * - We must enable and schedule delayed refill work only when we have + * enabled all the receive queue's napi. Otherwise, in refill_work, we + * have a deadlock when calling napi_disable on an already disabled + * napi. + */ for (i = 0; i < vi->max_queue_pairs; i++) { if (i < vi->curr_queue_pairs) /* Make sure we have some buffers: if oom use wq. */ if (!try_fill_recv(vi, &vi->rq[i], GFP_KERNEL)) - schedule_delayed_work(&vi->refill, 0); + schedule_refill = true; err = virtnet_enable_queue_pair(vi, i); if (err < 0) goto err_enable_qp; } + enable_delayed_refill(vi); + if (schedule_refill) + schedule_delayed_work(&vi->refill, 0); + if (virtio_has_feature(vi->vdev, VIRTIO_NET_F_STATUS)) { if (vi->status & VIRTIO_NET_S_LINK_UP) netif_carrier_on(vi->dev); @@ -3463,39 +3473,48 @@ static void virtnet_rx_pause(struct virtnet_info *vi, struct receive_queue *rq) __virtnet_rx_pause(vi, rq); } -static void __virtnet_rx_resume(struct virtnet_info *vi, - struct receive_queue *rq, - bool refill) +static void virtnet_rx_resume_all(struct virtnet_info *vi) { - bool running = netif_running(vi->dev); bool schedule_refill = false; + int i; - if (refill && !try_fill_recv(vi, rq, GFP_KERNEL)) - schedule_refill = true; - if (running) - virtnet_napi_enable(rq); - - if (schedule_refill) - schedule_delayed_work(&vi->refill, 0); -} + if (netif_running(vi->dev)) { + /* See the comment in virtnet_open for the ordering rule + * of try_fill_recv, receive queue napi_enable and delayed + * refill enable/schedule. + */ + for (i = 0; i < vi->max_queue_pairs; i++) { + if (i < vi->curr_queue_pairs) + if (!try_fill_recv(vi, &vi->rq[i], GFP_KERNEL)) + schedule_refill = true; -static void virtnet_rx_resume_all(struct virtnet_info *vi) -{ - int i; + virtnet_napi_enable(&vi->rq[i]); + } - enable_delayed_refill(vi); - for (i = 0; i < vi->max_queue_pairs; i++) { - if (i < vi->curr_queue_pairs) - __virtnet_rx_resume(vi, &vi->rq[i], true); - else - __virtnet_rx_resume(vi, &vi->rq[i], false); + enable_delayed_refill(vi); + if (schedule_refill) + schedule_delayed_work(&vi->refill, 0); } } static void virtnet_rx_resume(struct virtnet_info *vi, struct receive_queue *rq) { - enable_delayed_refill(vi); - __virtnet_rx_resume(vi, rq, true); + bool schedule_refill = false; + + if (netif_running(vi->dev)) { + /* See the comment in virtnet_open for the ordering rule + * of try_fill_recv, receive queue napi_enable and delayed + * refill enable/schedule. + */ + if (!try_fill_recv(vi, rq, GFP_KERNEL)) + schedule_refill = true; + + virtnet_napi_enable(rq); + + enable_delayed_refill(vi); + if (schedule_refill) + schedule_delayed_work(&vi->refill, 0); + } } static int virtnet_rx_resize(struct virtnet_info *vi, -- 2.43.0

2 weeks, 4 days

[PATCH v2 0/2] fix demotion targets checks in reclaim/demotion

by Bing Jiao

This patch series addresses two issues in demote_folio_list() and can_demote() in reclaim/demotion. Commit 7d709f49babc ("vmscan,cgroup: apply mems_effective to reclaim") introduces the cpuset.mems_effective check and applies it to can_demote(). However: 1. It does not apply this check in demote_folio_list(), which leads to situations where pages are demoted to nodes that are explicitly excluded from the task's cpuset.mems. 2. It checks only the nodes in the immediate next demotion hierarchy and does not check all allowed demotion targets in can_demote(). This can cause pages to never be demoted if the nodes in the next demotion hierarchy are not set in mems_effective. To address these bugs, implement a new function mem_cgroup_filter_mems_allowed() to filter out nodes that are not set in mems_effective, and update demote_folio_list() and can_demote() accordingly. Reproduct Bug 1: Assume a system with 4 nodes, where nodes 0-1 are top-tier and nodes 2-3 are far-tier memory. All nodes have equal capacity. Test script to reproduct: echo 1 > /sys/kernel/mm/numa/demotion_enabled mkdir /sys/fs/cgroup/test echo +cpuset > /sys/fs/cgroup/cgroup.subtree_control echo "0-2" > /sys/fs/cgroup/test/cpuset.mems echo $$ > /sys/fs/cgroup/test/cgroup.procs swapoff -a # Expectation: Should respect node 0-2 limit. # Observation: Node 3 shows significant allocation (MemFree drops) stress-ng --oomable --vm 1 --vm-bytes 150% --mbind 0,1 Reproduct Bug 2: Assume a system with 6 nodes, where nodes 0-2 are top-tier, node 3 is far-tier node, and nodes 4-5 are the farthest-tier nodes. All nodes have equal capacity. Test script: echo 1 > /sys/kernel/mm/numa/demotion_enabled mkdir /sys/fs/cgroup/test echo +cpuset > /sys/fs/cgroup/cgroup.subtree_control echo "0-2,4-5" > /sys/fs/cgroup/test/cpuset.mems echo $$ > /sys/fs/cgroup/test/cgroup.procs swapoff -a # Expectation: Pages are demoted to Nodes 4-5 # Observation: No pages are demoted before oom. stress-ng --oomable --vm 1 --vm-bytes 150% --mbind 0,1,2 Bing Jiao (2): mm/vmscan: respect mems_effective in demote_folio_list() mm/vmscan: check all allowed targets in can_demote() include/linux/cpuset.h | 6 +++--- include/linux/memcontrol.h | 6 +++--- kernel/cgroup/cpuset.c | 12 +++++------- mm/memcontrol.c | 5 +++-- mm/vmscan.c | 27 ++++++++++++++++++--------- 5 files changed, 32 insertions(+), 24 deletions(-) -- 2.52.0.351.gbe84eed79e-goog

2 weeks, 4 days

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror