On 20 Sep 2026, at 22:55, [email protected] wrote:

> 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 <[email protected]>
>
> 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?

Answer copied from RFC:

After the conversion, folio/page should have an elevated refcount whenever
->private is set. That would help detect leaked private data. I tried to
enforce ->private needs to be NULL at page free time[1], but that might
cause trouble for certain use cases.

[1] https://lore.kernel.org/all/[email protected]/


>
>>       1UL << PG_writeback    | 1UL << PG_reserved    |       \
>>       1UL << PG_active       |                               \
>>       1UL << PG_unevictable  | __PG_MLOCKED | LRU_GEN_MASK)
>
> -- 
> Sashiko AI review ยท 
> https://sashiko.dev/#/patchset/[email protected]?part=17


Best Regards,
Yan, Zi

Reply via email to