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? > 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
