October 2025 - Linux-stable-mirror

[merged mm-hotfixes-stable] mm-damon-core-use-damos_commit_quota_goal-for-new-goal-commit.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/damon/core: use damos_commit_quota_goal() for new goal commit has been removed from the -mm tree. Its filename was mm-damon-core-use-damos_commit_quota_goal-for-new-goal-commit.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: SeongJae Park <sj(a)kernel.org> Subject: mm/damon/core: use damos_commit_quota_goal() for new goal commit Date: Mon, 13 Oct 2025 17:18:44 -0700 When damos_commit_quota_goals() is called for adding new DAMOS quota goals of DAMOS_QUOTA_USER_INPUT metric, current_value fields of the new goals should be also set as requested. However, damos_commit_quota_goals() is not updating the field for the case, since it is setting only metrics and target values using damos_new_quota_goal(), and metric-optional union fields using damos_commit_quota_goal_union(). As a result, users could see the first current_value parameter that committed online with a new quota goal is ignored. Users are assumed to commit the current_value for DAMOS_QUOTA_USER_INPUT quota goals, since it is being used as a feedback. Hence the real impact would be subtle. That said, this is obviously not intended behavior. Fix the issue by using damos_commit_quota_goal() which sets all quota goal parameters, instead of damos_commit_quota_goal_union(), which sets only the union fields. Link: https://lkml.kernel.org/r/20251014001846.279282-1-sj@kernel.org Fixes: 1aef9df0ee90 ("mm/damon/core: commit damos_quota_goal->nid") Signed-off-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> [6.16+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/damon/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/damon/core.c~mm-damon-core-use-damos_commit_quota_goal-for-new-goal-commit +++ a/mm/damon/core.c @@ -835,7 +835,7 @@ int damos_commit_quota_goals(struct damo src_goal->metric, src_goal->target_value); if (!new_goal) return -ENOMEM; - damos_commit_quota_goal_union(new_goal, src_goal); + damos_commit_quota_goal(new_goal, src_goal); damos_add_quota_goal(dst, new_goal); } return 0; _ Patches currently in -mm which might be from sj(a)kernel.org are mm-zswap-remove-unnecessary-dlen-writes-for-incompressible-pages.patch mm-zswap-fix-typos-s-zwap-zswap.patch mm-zswap-s-red-black-tree-xarray.patch docs-admin-guide-mm-zswap-s-red-black-tree-xarray.patch mm-damon-document-damos_quota_goal-nid-use-case.patch mm-damon-add-damos-quota-goal-type-for-per-memcg-per-node-memory-usage.patch mm-damon-core-implement-damos_quota_node_memcg_used_bp.patch mm-damon-sysfs-schemes-implement-path-file-under-quota-goal-directory.patch mm-damon-sysfs-schemes-support-damos_quota_node_memcg_used_bp.patch mm-damon-core-add-damos-quota-gaol-metric-for-per-memcg-per-numa-free-memory.patch mm-damon-sysfs-schemes-support-damos_quota_node_memcg_free_bp.patch docs-mm-damon-design-document-damos_quota_node_memcg_usedfree_bp.patch docs-admin-guide-mm-damon-usage-document-damos-quota-goal-path-file.patch docs-abi-damon-document-damos-quota-goal-path-file.patch

1 month

1
0
0 0

[merged mm-hotfixes-stable] mm-damon-core-fix-potential-memory-leak-by-cleaning-ops_filter-in-damon_destroy_scheme.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/damon/core: fix potential memory leak by cleaning ops_filter in damon_destroy_scheme has been removed from the -mm tree. Its filename was mm-damon-core-fix-potential-memory-leak-by-cleaning-ops_filter-in-damon_destroy_scheme.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Enze Li <lienze(a)kylinos.cn> Subject: mm/damon/core: fix potential memory leak by cleaning ops_filter in damon_destroy_scheme Date: Tue, 14 Oct 2025 16:42:25 +0800 Currently, damon_destroy_scheme() only cleans up the filter list but leaves ops_filter untouched, which could lead to memory leaks when a scheme is destroyed. This patch ensures both filter and ops_filter are properly freed in damon_destroy_scheme(), preventing potential memory leaks. Link: https://lkml.kernel.org/r/20251014084225.313313-1-lienze@kylinos.cn Fixes: ab82e57981d0 ("mm/damon/core: introduce damos->ops_filters") Signed-off-by: Enze Li <lienze(a)kylinos.cn> Reviewed-by: SeongJae Park <sj(a)kernel.org> Tested-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/damon/core.c | 3 +++ 1 file changed, 3 insertions(+) --- a/mm/damon/core.c~mm-damon-core-fix-potential-memory-leak-by-cleaning-ops_filter-in-damon_destroy_scheme +++ a/mm/damon/core.c @@ -452,6 +452,9 @@ void damon_destroy_scheme(struct damos * damos_for_each_filter_safe(f, next, s) damos_destroy_filter(f); + damos_for_each_ops_filter_safe(f, next, s) + damos_destroy_filter(f); + kfree(s->migrate_dests.node_id_arr); kfree(s->migrate_dests.weight_arr); damon_del_scheme(s); _ Patches currently in -mm which might be from lienze(a)kylinos.cn are

1 month

1
0
0 0

[merged mm-hotfixes-stable] vmw_balloon-indicate-success-when-effectively-deflating-during-migration.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: vmw_balloon: indicate success when effectively deflating during migration has been removed from the -mm tree. Its filename was vmw_balloon-indicate-success-when-effectively-deflating-during-migration.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: David Hildenbrand <david(a)redhat.com> Subject: vmw_balloon: indicate success when effectively deflating during migration Date: Tue, 14 Oct 2025 14:44:55 +0200 When migrating a balloon page, we first deflate the old page to then inflate the new page. However, if inflating the new page succeeded, we effectively deflated the old page, reducing the balloon size. In that case, the migration actually worked: similar to migrating+ immediately deflating the new page. The old page will be freed back to the buddy. Right now, the core will leave the page be marked as isolated (as we returned an error). When later trying to putback that page, we will run into the WARN_ON_ONCE() in balloon_page_putback(). That handling was changed in commit 3544c4faccb8 ("mm/balloon_compaction: stop using __ClearPageMovable()"); before that change, we would have tolerated that way of handling it. To fix it, let's just return 0 in that case, making the core effectively just clear the "isolated" flag + freeing it back to the buddy as if the migration succeeded. Note that the new page will also get freed when the core puts the last reference. Note that this also makes it all be more consistent: we will no longer unisolate the page in the balloon driver while keeping it marked as being isolated in migration core. This was found by code inspection. Link: https://lkml.kernel.org/r/20251014124455.478345-1-david@redhat.com Fixes: 3544c4faccb8 ("mm/balloon_compaction: stop using __ClearPageMovable()") Signed-off-by: David Hildenbrand <david(a)redhat.com> Cc: Jerrin Shaji George <jerrin.shaji-george(a)broadcom.com> Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list(a)broadcom.com> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- drivers/misc/vmw_balloon.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) --- a/drivers/misc/vmw_balloon.c~vmw_balloon-indicate-success-when-effectively-deflating-during-migration +++ a/drivers/misc/vmw_balloon.c @@ -1737,7 +1737,7 @@ static int vmballoon_migratepage(struct { unsigned long status, flags; struct vmballoon *b; - int ret; + int ret = 0; b = container_of(b_dev_info, struct vmballoon, b_dev_info); @@ -1796,17 +1796,15 @@ static int vmballoon_migratepage(struct * A failure happened. While we can deflate the page we just * inflated, this deflation can also encounter an error. Instead * we will decrease the size of the balloon to reflect the - * change and report failure. + * change. */ atomic64_dec(&b->size); - ret = -EBUSY; } else { /* * Success. Take a reference for the page, and we will add it to * the list after acquiring the lock. */ get_page(newpage); - ret = 0; } /* Update the balloon list under the @pages_lock */ @@ -1817,7 +1815,7 @@ static int vmballoon_migratepage(struct * If we succeed just insert it to the list and update the statistics * under the lock. */ - if (!ret) { + if (status == VMW_BALLOON_SUCCESS) { balloon_page_insert(&b->b_dev_info, newpage); __count_vm_event(BALLOON_MIGRATE); } _ Patches currently in -mm which might be from david(a)redhat.com are

1 month

1
0
0 0

[merged mm-hotfixes-stable] mm-damon-core-fix-list_add_tail-call-on-damon_call.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/damon/core: fix list_add_tail() call on damon_call() has been removed from the -mm tree. Its filename was mm-damon-core-fix-list_add_tail-call-on-damon_call.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: SeongJae Park <sj(a)kernel.org> Subject: mm/damon/core: fix list_add_tail() call on damon_call() Date: Tue, 14 Oct 2025 13:59:36 -0700 Each damon_ctx maintains callback requests using a linked list (damon_ctx->call_controls). When a new callback request is received via damon_call(), the new request should be added to the list. However, the function is making a mistake at list_add_tail() invocation: putting the new item to add and the list head to add it before, in the opposite order. Because of the linked list manipulation implementation, the new request can still be reached from the context's list head. But the list items that were added before the new request are dropped from the list. As a result, the callbacks are unexpectedly not invocated. Worse yet, if the dropped callback requests were dynamically allocated, the memory is leaked. Actually DAMON sysfs interface is using a dynamically allocated repeat-mode callback request for automatic essential stats update. And because the online DAMON parameters commit is using a non-repeat-mode callback request, the issue can easily be reproduced, like below. # damo start --damos_action stat --refresh_stat 1s # damo tune --damos_action stat --refresh_stat 1s The first command dynamically allocates the repeat-mode callback request for automatic essential stat update. Users can see the essential stats are automatically updated for every second, using the sysfs interface. The second command calls damon_commit() with a new callback request that was made for the commit. As a result, the previously added repeat-mode callback request is dropped from the list. The automatic stats refresh stops working, and the memory for the repeat-mode callback request is leaked. It can be confirmed using kmemleak. Fix the mistake on the list_add_tail() call. Link: https://lkml.kernel.org/r/20251014205939.1206-1-sj@kernel.org Fixes: 004ded6bee11 ("mm/damon: accept parallel damon_call() requests") Signed-off-by: SeongJae Park <sj(a)kernel.org> Cc: <stable(a)vger.kernel.org> [6.17+] Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/damon/core.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/damon/core.c~mm-damon-core-fix-list_add_tail-call-on-damon_call +++ a/mm/damon/core.c @@ -1450,7 +1450,7 @@ int damon_call(struct damon_ctx *ctx, st INIT_LIST_HEAD(&control->list); mutex_lock(&ctx->call_controls_lock); - list_add_tail(&ctx->call_controls, &control->list); + list_add_tail(&control->list, &ctx->call_controls); mutex_unlock(&ctx->call_controls_lock); if (!damon_is_running(ctx)) return -EINVAL; _ Patches currently in -mm which might be from sj(a)kernel.org are mm-zswap-remove-unnecessary-dlen-writes-for-incompressible-pages.patch mm-zswap-fix-typos-s-zwap-zswap.patch mm-zswap-s-red-black-tree-xarray.patch docs-admin-guide-mm-zswap-s-red-black-tree-xarray.patch mm-damon-document-damos_quota_goal-nid-use-case.patch mm-damon-add-damos-quota-goal-type-for-per-memcg-per-node-memory-usage.patch mm-damon-core-implement-damos_quota_node_memcg_used_bp.patch mm-damon-sysfs-schemes-implement-path-file-under-quota-goal-directory.patch mm-damon-sysfs-schemes-support-damos_quota_node_memcg_used_bp.patch mm-damon-core-add-damos-quota-gaol-metric-for-per-memcg-per-numa-free-memory.patch mm-damon-sysfs-schemes-support-damos_quota_node_memcg_free_bp.patch docs-mm-damon-design-document-damos_quota_node_memcg_usedfree_bp.patch docs-admin-guide-mm-damon-usage-document-damos-quota-goal-path-file.patch docs-abi-damon-document-damos-quota-goal-path-file.patch

1 month

1
0
0 0

[merged mm-hotfixes-stable] mm-mremap-correctly-account-old-mapping-after-mremap_dontunmap-remap.patch removed from -mm tree

by Andrew Morton

The quilt patch titled Subject: mm/mremap: correctly account old mapping after MREMAP_DONTUNMAP remap has been removed from the -mm tree. Its filename was mm-mremap-correctly-account-old-mapping-after-mremap_dontunmap-remap.patch This patch was dropped because it was merged into the mm-hotfixes-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Subject: mm/mremap: correctly account old mapping after MREMAP_DONTUNMAP remap Date: Mon, 13 Oct 2025 17:58:36 +0100 Commit b714ccb02a76 ("mm/mremap: complete refactor of move_vma()") mistakenly introduced a new behaviour - clearing the VM_ACCOUNT flag of the old mapping when a mapping is mremap()'d with the MREMAP_DONTUNMAP flag set. While we always clear the VM_LOCKED and VM_LOCKONFAULT flags for the old mapping (the page tables have been moved, so there is no data that could possibly be locked in memory), there is no reason to touch any other VMA flags. This is because after the move the old mapping is in a state as if it were freshly mapped. This implies that the attributes of the mapping ought to remain the same, including whether or not the mapping is accounted. Link: https://lkml.kernel.org/r/20251013165836.273113-1-lorenzo.stoakes@oracle.com Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Fixes: b714ccb02a76 ("mm/mremap: complete refactor of move_vma()") Reviewed-by: Pedro Falcato <pfalcato(a)suse.de> Cc: Jann Horn <jannh(a)google.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/mremap.c | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) --- a/mm/mremap.c~mm-mremap-correctly-account-old-mapping-after-mremap_dontunmap-remap +++ a/mm/mremap.c @@ -1237,10 +1237,10 @@ static int copy_vma_and_data(struct vma_ } /* - * Perform final tasks for MADV_DONTUNMAP operation, clearing mlock() and - * account flags on remaining VMA by convention (it cannot be mlock()'d any - * longer, as pages in range are no longer mapped), and removing anon_vma_chain - * links from it (if the entire VMA was copied over). + * Perform final tasks for MADV_DONTUNMAP operation, clearing mlock() flag on + * remaining VMA by convention (it cannot be mlock()'d any longer, as pages in + * range are no longer mapped), and removing anon_vma_chain links from it if the + * entire VMA was copied over. */ static void dontunmap_complete(struct vma_remap_struct *vrm, struct vm_area_struct *new_vma) @@ -1250,11 +1250,8 @@ static void dontunmap_complete(struct vm unsigned long old_start = vrm->vma->vm_start; unsigned long old_end = vrm->vma->vm_end; - /* - * We always clear VM_LOCKED[ONFAULT] | VM_ACCOUNT on the old - * vma. - */ - vm_flags_clear(vrm->vma, VM_LOCKED_MASK | VM_ACCOUNT); + /* We always clear VM_LOCKED[ONFAULT] on the old VMA. */ + vm_flags_clear(vrm->vma, VM_LOCKED_MASK); /* * anon_vma links of the old vma is no longer needed after its page _ Patches currently in -mm which might be from lorenzo.stoakes(a)oracle.com are mm-shmem-update-shmem-to-use-mmap_prepare.patch device-dax-update-devdax-to-use-mmap_prepare.patch mm-vma-remove-unused-function-make-internal-functions-static.patch mm-add-vma_desc_size-vma_desc_pages-helpers.patch relay-update-relay-to-use-mmap_prepare.patch mm-vma-rename-__mmap_prepare-function-to-avoid-confusion.patch mm-add-remap_pfn_range_prepare-remap_pfn_range_complete.patch mm-abstract-io_remap_pfn_range-based-on-pfn.patch mm-introduce-io_remap_pfn_range_.patch mm-add-ability-to-take-further-action-in-vm_area_desc.patch doc-update-porting-vfs-documentation-for-mmap_prepare-actions.patch mm-hugetlbfs-update-hugetlbfs-to-use-mmap_prepare.patch mm-add-shmem_zero_setup_desc.patch mm-update-mem-char-driver-to-use-mmap_prepare.patch mm-update-resctl-to-use-mmap_prepare.patch

1 month

1
0
0 0

[PATCH] usb: raw-gadget: do not limit transfer length

by andrey.konovalov＠linux.dev

From: Andrey Konovalov <andreyknvl(a)gmail.com> Drop the check on the maximum transfer length in Raw Gadget for both control and non-control transfers. Limiting the transfer length causes a problem with emulating USB devices whose full configuration descriptor exceeds PAGE_SIZE in length. Overall, there does not appear to be any reason to enforce any kind of transfer length limit on the Raw Gadget side for either control or non-control transfers, so let's just drop the related check. Cc: stable(a)vger.kernel.org Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface") Signed-off-by: Andrey Konovalov <andreyknvl(a)gmail.com> --- drivers/usb/gadget/legacy/raw_gadget.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/usb/gadget/legacy/raw_gadget.c b/drivers/usb/gadget/legacy/raw_gadget.c index 20165e1582d9..b71680c58de6 100644 --- a/drivers/usb/gadget/legacy/raw_gadget.c +++ b/drivers/usb/gadget/legacy/raw_gadget.c @@ -667,8 +667,6 @@ static void *raw_alloc_io_data(struct usb_raw_ep_io *io, void __user *ptr, return ERR_PTR(-EINVAL); if (!usb_raw_io_flags_valid(io->flags)) return ERR_PTR(-EINVAL); - if (io->length > PAGE_SIZE) - return ERR_PTR(-EINVAL); if (get_from_user) data = memdup_user(ptr + sizeof(*io), io->length); else { -- 2.43.0

1 month

3
4
0 0

[PATCH RESEND] usb: raw-gadget: do not limit transfer length

by andrey.konovalov＠linux.dev

From: Andrey Konovalov <andreyknvl(a)gmail.com> Drop the check on the maximum transfer length in Raw Gadget for both control and non-control transfers. Limiting the transfer length causes a problem with emulating USB devices whose full configuration descriptor exceeds PAGE_SIZE in length. Overall, there does not appear to be any reason to enforce any kind of transfer length limit on the Raw Gadget side for either control or non-control transfers, so let's just drop the related check. Cc: stable(a)vger.kernel.org Fixes: f2c2e717642c ("usb: gadget: add raw-gadget interface") Signed-off-by: Andrey Konovalov <andreyknvl(a)gmail.com> --- drivers/usb/gadget/legacy/raw_gadget.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/usb/gadget/legacy/raw_gadget.c b/drivers/usb/gadget/legacy/raw_gadget.c index 20165e1582d9..b71680c58de6 100644 --- a/drivers/usb/gadget/legacy/raw_gadget.c +++ b/drivers/usb/gadget/legacy/raw_gadget.c @@ -667,8 +667,6 @@ static void *raw_alloc_io_data(struct usb_raw_ep_io *io, void __user *ptr, return ERR_PTR(-EINVAL); if (!usb_raw_io_flags_valid(io->flags)) return ERR_PTR(-EINVAL); - if (io->length > PAGE_SIZE) - return ERR_PTR(-EINVAL); if (get_from_user) data = memdup_user(ptr + sizeof(*io), io->length); else { -- 2.43.0

1 month

1
0
0 0

[PATCH 0/2] fuse: Fix possible memleak at startup with immediate teardown

by Bernd Schubert

Do not merge yet, the current series has not been tested yet. The race is only easily reproducible with additional patches that pin pages during FUSE_IO_URING_CMD_REGISTER - slows it down and then xfstest's generic/001 triggers it reliably. However, I need to update these pin patches for linux master. Signed-off-by: Bernd Schubert <bschubert(a)ddn.com> --- Bernd Schubert (1): fuse: Move ring queues_refs decrement Jian Huang Li (1): fs/fuse: fix potential memory leak from fuse_uring_cancel fs/fuse/dev_uring.c | 33 ++++++++++++++------------------- 1 file changed, 14 insertions(+), 19 deletions(-) --- base-commit: 6548d364a3e850326831799d7e3ea2d7bb97ba08 change-id: 20251021-io-uring-fixes-cancel-mem-leak-820642677c37 Best regards, -- Bernd Schubert <bschubert(a)ddn.com>

1 month

1
1
0 0

+ mm-shmem-fix-thp-allocation-size-check-and-fallback.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm/shmem: fix THP allocation size check and fallback has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-shmem-fix-thp-allocation-size-check-and-fallback.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 the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Kairui Song <kasong(a)tencent.com> Subject: mm/shmem: fix THP allocation size check and fallback Date: Wed, 22 Oct 2025 03:04:36 +0800 There are some problems with the code implementations of THP fallback. suitable_orders could be zero, and calling highest_order on a zero value returns an overflowed size. And the order check loop is updating the index value on every loop which may cause the index to be aligned by a larger value while the loop shrinks the order. And it forgot to try order 0 after the final loop. This is usually fine because shmem_add_to_page_cache ensures the shmem mapping is still sane, but it might cause many potential issues like allocating random folios into the random position in the map or return -ENOMEM by accident. This triggered some strange userspace errors [1], and shouldn't have happened in the first place. Link: https://lkml.kernel.org/r/20251021190436.81682-1-ryncsn@gmail.com Link: https://lore.kernel.org/linux-mm/CAMgjq7DqgAmj25nDUwwu1U2cSGSn8n4-Hqpgotted… [1] Fixes: e7a2ab7b3bb5d ("mm: shmem: add mTHP support for anonymous shmem") Signed-off-by: Kairui Song <kasong(a)tencent.com> Cc: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: Barry Song <baohua(a)kernel.org> Cc: David Hildenbrand <david(a)redhat.com> Cc: Dev Jain <dev.jain(a)arm.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Matthew Wilcox (Oracle) <willy(a)infradead.org> Cc: Nico Pache <npache(a)redhat.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Zi Yan <ziy(a)nvidia.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/shmem.c | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) --- a/mm/shmem.c~mm-shmem-fix-thp-allocation-size-check-and-fallback +++ a/mm/shmem.c @@ -1824,6 +1824,9 @@ static unsigned long shmem_suitable_orde unsigned long pages; int order; + if (!orders) + return 0; + if (vma) { orders = thp_vma_suitable_orders(vma, vmf->address, orders); if (!orders) @@ -1888,27 +1891,28 @@ static struct folio *shmem_alloc_and_add if (!IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) orders = 0; - if (orders > 0) { - suitable_orders = shmem_suitable_orders(inode, vmf, - mapping, index, orders); + suitable_orders = shmem_suitable_orders(inode, vmf, + mapping, index, orders); + if (suitable_orders) { order = highest_order(suitable_orders); - while (suitable_orders) { + do { pages = 1UL << order; - index = round_down(index, pages); - folio = shmem_alloc_folio(gfp, order, info, index); - if (folio) + folio = shmem_alloc_folio(gfp, order, info, round_down(index, pages)); + if (folio) { + index = round_down(index, pages); goto allocated; + } if (pages == HPAGE_PMD_NR) count_vm_event(THP_FILE_FALLBACK); count_mthp_stat(order, MTHP_STAT_SHMEM_FALLBACK); order = next_order(&suitable_orders, order); - } - } else { - pages = 1; - folio = shmem_alloc_folio(gfp, 0, info, index); + } while (suitable_orders); } + + pages = 1; + folio = shmem_alloc_folio(gfp, 0, info, index); if (!folio) return ERR_PTR(-ENOMEM); _ Patches currently in -mm which might be from kasong(a)tencent.com are mm-shmem-fix-thp-allocation-size-check-and-fallback.patch

1 month

1
0
0 0

[PATCH 5.10/5.15] srcu: Tighten cleanup_srcu_struct() GP checks

by Vasiliy Kovalev

From: "Paul E. McKenney" <paulmck(a)kernel.org> commit 8ed00760203d8018bee042fbfe8e076579be2c2b upstream. Currently, cleanup_srcu_struct() checks for a grace period in progress, but it does not check for a grace period that has not yet started but which might start at any time. Such a situation could result in a use-after-free bug, so this commit adds a check for a grace period that is needed but not yet started to cleanup_srcu_struct(). Fixes: da915ad5cf25 ("srcu: Parallelize callback handling") Signed-off-by: Paul E. McKenney <paulmck(a)kernel.org> [ kovalev: backport to fix CVE-2022-49651; added Fixes tag for commit da915ad5cf25 that introduced the srcu_gp_seq_needed field and the race condition between grace period requests and cleanup ] Signed-off-by: Vasiliy Kovalev <kovalev(a)altlinux.org> --- kernel/rcu/srcutree.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/kernel/rcu/srcutree.c b/kernel/rcu/srcutree.c index b8821665c435..5d89d941280f 100644 --- a/kernel/rcu/srcutree.c +++ b/kernel/rcu/srcutree.c @@ -388,9 +388,11 @@ void cleanup_srcu_struct(struct srcu_struct *ssp) return; /* Forgot srcu_barrier(), so just leak it! */ } if (WARN_ON(rcu_seq_state(READ_ONCE(ssp->srcu_gp_seq)) != SRCU_STATE_IDLE) || + WARN_ON(rcu_seq_current(&ssp->srcu_gp_seq) != ssp->srcu_gp_seq_needed) || WARN_ON(srcu_readers_active(ssp))) { - pr_info("%s: Active srcu_struct %p state: %d\n", - __func__, ssp, rcu_seq_state(READ_ONCE(ssp->srcu_gp_seq))); + pr_info("%s: Active srcu_struct %p read state: %d gp state: %lu/%lu\n", + __func__, ssp, rcu_seq_state(READ_ONCE(ssp->srcu_gp_seq)), + rcu_seq_current(&ssp->srcu_gp_seq), ssp->srcu_gp_seq_needed); return; /* Caller forgot to stop doing call_srcu()? */ } free_percpu(ssp->sda); -- 2.50.1

1 month

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2025