public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: "Garg, Shivank" <shivankg@amd.com>, Zi Yan <ziy@nvidia.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	willy@infradead.org, Matthew Brost <matthew.brost@intel.com>,
	Joshua Hahn <joshua.hahnjy@gmail.com>,
	Rakie Kim <rakie.kim@sk.com>, Byungchul Park <byungchul@sk.com>,
	Gregory Price <gourry@gourry.net>,
	Ying Huang <ying.huang@linux.alibaba.com>,
	Alistair Popple <apopple@nvidia.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm/migrate: rename PAGE_ migration flags to FOLIO_
Date: Wed, 25 Mar 2026 10:25:36 +0100	[thread overview]
Message-ID: <cb383f3f-b74c-41a8-a77d-d00e93b7fe94@kernel.org> (raw)
In-Reply-To: <41cd005e-3702-4c67-8d32-0c09274194e9@amd.com>

On 3/25/26 10:21, Garg, Shivank wrote:
> 
>>>
>>>  static void __migrate_folio_record(struct folio *dst,
>>> -				   int old_page_state,
>>> +				   int old_folio_state,
>>>  				   struct anon_vma *anon_vma)
>>>  {
>>> -	dst->private = (void *)anon_vma + old_page_state;
>>> +	dst->private = (void *)anon_vma + old_folio_state;
>>>  }
>>>
>>>  static void __migrate_folio_extract(struct folio *dst,
>>> -				   int *old_page_state,
>>> +				   int *old_folio_state,
>>>  				   struct anon_vma **anon_vmap)
>>>  {
>>>  	unsigned long private = (unsigned long)dst->private;
>>>
>>> -	*anon_vmap = (struct anon_vma *)(private & ~PAGE_OLD_STATES);
>>> -	*old_page_state = private & PAGE_OLD_STATES;
>>> +	*anon_vmap = (struct anon_vma *)(private & ~FOLIO_OLD_STATES);
>>> +	*old_folio_state = private & FOLIO_OLD_STATES;
>>>  	dst->private = NULL;
>>>  }
>>
>> Just an observation on folio->private, it is void*, but page->private
>> is unsigned long. It confused me a bit. There are folio_get_private()
>> and folio_change_private(), I wonder if we want to use them here
>> instead of direct ->private accesses. Feel free to ignore this,
>> since it is irrelevant to this patch.
> 
> Would something like this as a follow-up patch work?
> 
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 6d4a85f903d8..55d1af6c9759 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -1143,17 +1143,17 @@ enum {
>  static void __migrate_folio_record(struct folio *dst,
>  		int old_folio_state, struct anon_vma *anon_vma)
>  {
> -	dst->private = (void *)anon_vma + old_folio_state;
> +	folio_change_private(dst, (void *)anon_vma + old_folio_state);
>  }
>  
>  static void __migrate_folio_extract(struct folio *dst,
>  		int *old_folio_state, struct anon_vma **anon_vmap)
>  {
> -	unsigned long private = (unsigned long)dst->private;
> +	unsigned long private = (unsigned long)folio_get_private(dst);
>  
>  	*anon_vmap = (struct anon_vma *)(private & ~FOLIO_OLD_STATES);
>  	*old_folio_state = private & FOLIO_OLD_STATES;
> -	dst->private = NULL;
> +	folio_change_private(dst, NULL);
>  }


Isn't folio_change_private() part of the
folio_attach_private()/folio_detach_private() interface that has
completely different semantics?

"The page must previously have had data attached and the data must be
detached before the folio will be freed."

(btw, that comment should refer to pages)

So I would not use folio_change_private(). An accidental
folio_attach_private() / folio_detach_private() would be rather undesired.

-- 
Cheers,

David


  reply	other threads:[~2026-03-25  9:25 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-24 11:47 [PATCH v2] mm/migrate: rename PAGE_ migration flags to FOLIO_ Shivank Garg
2026-03-24 12:31 ` David Hildenbrand (Arm)
2026-03-24 18:59   ` Garg, Shivank
2026-03-24 13:38 ` Zi Yan
2026-03-24 19:03   ` Garg, Shivank
2026-03-25  9:21   ` Garg, Shivank
2026-03-25  9:25     ` David Hildenbrand (Arm) [this message]
2026-03-25 11:04       ` Garg, Shivank
2026-03-25 14:21         ` Zi Yan
2026-03-25 14:53           ` David Hildenbrand (Arm)
2026-03-25 15:00             ` Zi Yan
2026-03-25 15:04               ` David Hildenbrand (Arm)
2026-03-25 15:05                 ` Zi Yan
2026-03-25 15:28                   ` Matthew Wilcox

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=cb383f3f-b74c-41a8-a77d-d00e93b7fe94@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=byungchul@sk.com \
    --cc=gourry@gourry.net \
    --cc=joshua.hahnjy@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matthew.brost@intel.com \
    --cc=rakie.kim@sk.com \
    --cc=shivankg@amd.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox