All of lore.kernel.org
 help / color / mirror / Atom feed
From: Usama Arif <usama.arif@linux.dev>
To: Zi Yan <ziy@nvidia.com>, "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	npache@redhat.com, willy@infradead.org, linux-mm@kvack.org,
	matthew.brost@intel.com, joshua.hahnjy@gmail.com,
	hannes@cmpxchg.org, rakie.kim@sk.com, byungchul@sk.com,
	gourry@gourry.net, ying.huang@linux.alibaba.com,
	apopple@nvidia.com, linux-kernel@vger.kernel.org,
	kernel-team@meta.com
Subject: Re: [PATCH] mm: migrate: transfer large_rmappable flag in folio_migrate_flags()
Date: Wed, 11 Mar 2026 17:28:41 +0300	[thread overview]
Message-ID: <3048ea54-1691-4098-90ff-ffb78dbc5cea@linux.dev> (raw)
In-Reply-To: <eb83276f-60f0-47f4-b164-998a2f11e817@linux.dev>



On 11/03/2026 17:24, Usama Arif wrote:
> 
> 
> On 11/03/2026 16:38, Zi Yan wrote:
>> On 11 Mar 2026, at 9:33, David Hildenbrand (Arm) wrote:
>>
>>> On 3/11/26 14:23, Usama Arif wrote:
>>>> folio_migrate_flags() transfers folio state from source to destination
>>>> during migration, but does not transfer the large_rmappable flag.
>>>>
>>>> Migration allocators like alloc_migration_target() and
>>>> alloc_misplaced_dst_folio() use __folio_alloc() directly without
>>>> wrapping the result in page_rmappable_folio(), so the destination folio
>>>> never gets large_rmappable set.
>>>>
>>>> This becomes a problem when a folio on the deferred split queue is
>>>> migrated: the destination folio can be added to the deferred split queue
>>>> via deferred_split_folio() (which does not check large_rmappable), but
>>>> when the folio is later freed, folio_unqueue_deferred_split() bails out
>>>> early because large_rmappable is not set:
>>>>
>>>>   if (folio_order(folio) <= 1 || !folio_test_large_rmappable(folio))
>>>>       return false;
>>>>
>>>> This leaves a stale entry on the deferred split queue, leading to
>>>> use-after-free when the shrinker walks the list.
>>>>
>>>> Fix this by transferring large_rmappable in folio_migrate_flags(),
>>>> consistent with how all other folio flags are handled.
>>>>
>>>> Fixes: dafff3f4c850 ("mm: split underused THPs")
>>>> Signed-off-by: Usama Arif <usama.arif@linux.dev>
>>>> ---
>>>>  mm/migrate.c | 3 +++
>>>>  1 file changed, 3 insertions(+)
>>>>
>>>> diff --git a/mm/migrate.c b/mm/migrate.c
>>>> index 3380021fd3db..ee1c7bc851dd 100644
>>>> --- a/mm/migrate.c
>>>> +++ b/mm/migrate.c
>>>> @@ -846,6 +846,9 @@ void folio_migrate_flags(struct folio *newfolio, struct folio *folio)
>>>>  	folio_copy_owner(newfolio, folio);
>>>>  	pgalloc_tag_swap(newfolio, folio);
>>>>
>>>> +	if (folio_test_large_rmappable(folio))
>>>> +		folio_set_large_rmappable(newfolio);
>>>> +
>>>>  	mem_cgroup_migrate(folio, newfolio);
>>>>  }
>>>>  EXPORT_SYMBOL(folio_migrate_flags);
>>>
>>> compaction_alloc_noprof() does the page_rmappable_folio() at the end.
>>>
>>> I'd assume that all migration allocation functions must take care of that.
>>>
>>> It's a responsibility of the folio allocation code, not folio migration
>>> code.
>>
>> I agree. The migration allocation function needs to give a folio or other
>> types of page matching the original one. Do we want to turn this into
>> a WARN to make sure newfolio matches folio's large_rmappable state?
>>
> 
> hmm its done in compaction_alloc() and alloc_migration_target_by_mpol() but I
> dont see this being done in alloc_migration_target() and alloc_misplaced_dst_folio().
> I think alloc_misplaced_dst_folio() is used by NUMA balancing and alloc_migration_target()
> by hotplug and memory failure?
> 
> I am not very familiar with migration code, so maybe I am missing where its being done
> in these paths?

ah no ignore me :) __folio_alloc_noprof should set it. Thanks and sorry for the noise!




  reply	other threads:[~2026-03-11 14:28 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-11 13:23 [PATCH] mm: migrate: transfer large_rmappable flag in folio_migrate_flags() Usama Arif
2026-03-11 13:33 ` David Hildenbrand (Arm)
2026-03-11 13:38   ` Zi Yan
2026-03-11 13:57     ` David Hildenbrand (Arm)
2026-03-11 14:24     ` Usama Arif
2026-03-11 14:28       ` Usama Arif [this message]
2026-03-11 14:34       ` David Hildenbrand (Arm)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3048ea54-1691-4098-90ff-ffb78dbc5cea@linux.dev \
    --to=usama.arif@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=byungchul@sk.com \
    --cc=david@kernel.org \
    --cc=gourry@gourry.net \
    --cc=hannes@cmpxchg.org \
    --cc=joshua.hahnjy@gmail.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matthew.brost@intel.com \
    --cc=npache@redhat.com \
    --cc=rakie.kim@sk.com \
    --cc=willy@infradead.org \
    --cc=ying.huang@linux.alibaba.com \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.