Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider: - [High] Removal of PG_private safety check causes leaked filesystem private data to go undetected. --
commit 9b27f18c6460a8f0a47a836096a558c0ddbb879d Author: Zi Yan <[email protected]> Subject: mm/page-flags: remove PG_private This patch removes the PG_private flag and repurposes its space as __PG_folio. It replaces the flag checks with checking if folio->private != NULL to determine if a folio carries private data. It also updates relevant documentation to reflect these changes. > diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h > index ae2ebaed6d4d9..02e67307ffff4 100644 > --- a/include/linux/page-flags.h > +++ b/include/linux/page-flags.h [ ... ] > @@ -1169,7 +1170,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 | \ > 1UL << PG_writeback | 1UL << PG_reserved | \ > 1UL << PG_active | \ > 1UL << PG_unevictable | __PG_MLOCKED | LRU_GEN_MASK) [Severity: High] Does removing PG_private from this mask cause leaked filesystem private data to go undetected? By removing the PG_private check without adding a replacement check for folio->private != NULL on the head page, the memory allocator's validation routines no longer catch this leak. Instead, when a buggy filesystem or subsystem frees a page with a non-NULL private field, free_pages_prepare() in mm/page_alloc.c will unconditionally zero it without warning: mm/page_alloc.c:free_pages_prepare() { ... page->flags.f &= ~PAGE_FLAGS_CHECK_AT_PREP; page->private = 0; ... } Could this silently erase the leaked private data (such as buffer heads) and mask the underlying memory leak? -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=14
