Re: [PATCH v5 17/17] mm/page-flags: remove PG_private

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mm: silent memory leak masking due to PG_private removal
--

commit aee12ed3446e69cb6eee57384ca09e768dab36dd
Author: Zi Yan <ziy@xxxxxxxxxx>

mm/page-flags: remove PG_private

This commit removes the PG_private page flag and replaces its usage with
checking if folio->private != NULL. The space left by PG_private is
reserved as PG_folio for future use.

> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index 7080a6a1a79e7..b0ddc652e76cc 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
[ ... ]
> @@ -1169,7 +1175,7 @@ static __always_inline void __ClearPageAnonExclusive(struct page *page)
>   */
>  #define PAGE_FLAGS_CHECK_AT_FREE				\
>  	(1UL << PG_lru		| 1UL << PG_locked	|	\
> -	 1UL << PG_private	| 1UL << PG_private_2	|	\
> +	 1UL << PG_private_2	|				\

[Severity: Medium]
Since PG_private is removed from PAGE_FLAGS_CHECK_AT_FREE, does this bypass
the safety check that ensures a page doesn't have uncleared private data?

Looking at __free_pages_prepare() in mm/page_alloc.c:

	page_cpupid_reset_last(page);
	page->flags.f &= ~PAGE_FLAGS_CHECK_AT_PREP;
	page->private = 0;
	reset_page_owner(page, order);

The head page's private field is silently zeroed here without any prior
verification that it was NULL. Previously, free_page_is_bad() would catch
and report leaked data via a bad_page() warning using
PAGE_FLAGS_CHECK_AT_FREE.

Now, if a buggy filesystem fails to detach and free folio->private data
before freeing the page, will this result in silent memory leaks?

>  	 1UL << PG_writeback	| 1UL << PG_reserved	|	\
>  	 1UL << PG_active 	|				\
>  	 1UL << PG_unevictable	| __PG_MLOCKED | LRU_GEN_MASK)

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260920-remove-pg_private-v5-0-bb68b6a21869@xxxxxxxxxx?part=17