Re: [PATCH v5 0/9] mm/page_owner: misc cleanups

[Ye Liu]

在 2026/7/2 08:11, Andrew Morton 写道:
> On Wed,  1 Jul 2026 14:10:43 +0800 Ye Liu <ye.liu@xxxxxxxxx> wrote:
> 
>> This series collects a few cleanups for mm/page_owner.c that have been
>> accumulated while reading through the file.  There is no functional
>> change -- the goal is to make the code easier to read and maintain.
> 
> Thanks, updated.
> 
> And...  this series is wearing out my keyboard.  Please leave it a
> week, gather up any additional feedback and only then send v6, if
> needed?
> 
Sorry Andrew, I had more time last week and updated more frequently.
I will wait and communicate fully for each version.

> btw, it's conventional to place the what-changed-since-last-time info
> below the ^---$ separator rather than at top-of-changelog.  That's where
> we place info which isn't appropriate for the mainline tree.
> 
I also have a question about this. Is the changelog placed in [PATCH 0/N] 
or in the patch [PATCH M/N] that needs to be modified? 
I've looked at some content on the mailing list, 
and it seems there are both options.
> AI review flagged another possible pre-existing issue.  A second
> occurrence of the race your "mm/page_owner: fix TOCTOU races in
> lockless page state reading" series addresses:
> 
> 	https://sashiko.dev/#/patchset/20260701061101.344679-1-ye.liu@xxxxxxxxx
> 
I will fix this warning in [PATCH 9/9] of V6.
>> v5:
>>  - Place the two patches corresponding to the Close connection, patch8 
>>    and patch9, together in this part.
>>  - Close: https://lore.kernel.org/all/20260625014708.87386-1-ye.liu@xxxxxxxxx/
>>  - Link: https://lore.kernel.org/all/20260701012239.315262-1-ye.liu@xxxxxxxxx/
> 
> Below is how v9 altered mm.git.  This is the addition of your
> "mm/page_owner: fix TOCTOU races in lockless page state reading"
> series, 
> 
I've added this part to this patch series. 
And how to close https://lore.kernel.org/all/20260625014708.87386-1-ye.liu@xxxxxxxxx/ ?
> 
> 
>  mm/page_owner.c |   16 +++++++++++++---
>  1 file changed, 13 insertions(+), 3 deletions(-)
> 
> --- a/mm/page_owner.c~b
> +++ a/mm/page_owner.c
> @@ -428,6 +428,12 @@ void __folio_copy_owner(struct folio *ne
>   * to skip less than the full buddy block, but that is acceptable for page owner
>   * iteration purposes.
>   *
> + * The lockless read of buddy_order_unsafe() can also return a garbage order if
> + * the page is concurrently allocated and PageBuddy is cleared between the check
> + * and the read. Clamp the advance at the next MAX_ORDER_NR_PAGES boundary so
> + * that a bogus order cannot carry @pfn into an unvalidated memory section,
> + * which would break callers that rely on boundary-aligned pfn_valid() checks.
> + *
>   * Return: true if the page was skipped (caller should continue its loop),
>   *         false if the page is not a buddy page and should be processed normally.
>   */
> @@ -439,8 +445,12 @@ static inline bool skip_buddy_pages(unsi
>  		return false;
>  
>  	order = buddy_order_unsafe(page);
> -	if (order <= MAX_PAGE_ORDER)
> -		*pfn += (1UL << order) - 1;
> +	if (order <= MAX_PAGE_ORDER) {
> +		unsigned long new_pfn = *pfn + (1UL << order);
> +		unsigned long boundary = ALIGN(*pfn + 1, MAX_ORDER_NR_PAGES);
> +
> +		*pfn = min(new_pfn, boundary) - 1;
> +	}
>  
>  	return true;
>  }
> @@ -551,7 +561,7 @@ static inline int print_page_owner_memcg
>  	cgroup_name(memcg->css.cgroup, name, sizeof(name));
>  	ret += scnprintf(kbuf + ret, count - ret,
>  			"Charged %sto %smemcg %s\n",
> -			PageMemcgKmem(page) ? "(via objcg) " : "",
> +			(memcg_data & MEMCG_DATA_KMEM) ? "(via objcg) " : "",
>  			online ? "" : "offline ",
>  			name);
>  out_unlock:
> _
> 

-- 
Thanks,
Ye Liu