On 2 Sep 2026, at 13:09, Usama Arif wrote:

> On Mon, 31 Aug 2026 15:25:37 -0400 Zi Yan <[email protected]> wrote:
>
>> folio->private != NULL indicates a folio carries private data, replacing
>> PG_private. All PG_private users are converted. Remove PG_private and
>> reserve the space as __PG_folio for future use.
>>
>> Also update files in Documentation. hugetlbfs_reserv.rst is outdated and
>> left unchanged. It should be rewritten.
>>
>> Assisted-by: Claude:claude-opus-4-8
>> Assisted-by: Codex:gpt-5
>> Signed-off-by: Zi Yan <[email protected]>
>> To: Andrew Morton <[email protected]>
>> To: Baoquan He <[email protected]>
>> To: Mike Rapoport <[email protected]>
>> To: Pasha Tatashin <[email protected]>
>> To: Pratyush Yadav <[email protected]>
>> To: Jonathan Corbet <[email protected]>
>> To: "Matthew Wilcox (Oracle)" <[email protected]>
>> To: Jan Kara <[email protected]>
>> To: David Hildenbrand <[email protected]>
>> To: Steven Rostedt <[email protected]>
>> To: Masami Hiramatsu <[email protected]>
>> Cc: Dave Young <[email protected]>
>> Cc: Shuah Khan <[email protected]>
>> Cc: Lorenzo Stoakes <[email protected]>
>> Cc: "Liam R. Howlett" <[email protected]>
>> Cc: Vlastimil Babka <[email protected]>
>> Cc: Suren Baghdasaryan <[email protected]>
>> Cc: Michal Hocko <[email protected]>
>> Cc: Mathieu Desnoyers <[email protected]>
>> Cc: [email protected]
>> Cc: [email protected]
>> Cc: [email protected]
>> Cc: [email protected]
>> Cc: [email protected]
>> Cc: [email protected]
>> ---
>>  Documentation/admin-guide/kdump/vmcoreinfo.rst |  2 +-
>>  Documentation/filesystems/vfs.rst              |  6 +++---
>>  include/linux/page-flags.h                     | 19 ++-----------------
>>  include/trace/events/mmflags.h                 |  2 +-
>>  kernel/vmcore_info.c                           |  1 -
>>  5 files changed, 7 insertions(+), 23 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst 
>> b/Documentation/admin-guide/kdump/vmcoreinfo.rst
>> index 7663c610fe901..5f1df6d080508 100644
>> --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
>> +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
>> @@ -325,7 +325,7 @@ NR_FREE_PAGES
>>  On linux-2.6.21 or later, the number of free pages is in
>>  vm_stat[NR_FREE_PAGES]. Used to get the number of free pages.
>>
>> -PG_lru|PG_private|PG_swapcache|PG_swapbacked|PG_hwpoison|PG_head_mask
>> +PG_lru|PG_swapcache|PG_swapbacked|PG_hwpoison|PG_head_mask
>>  --------------------------------------------------------------------------
>>
>>  Page attributes. These flags are used to filter various unnecessary for
>> diff --git a/Documentation/filesystems/vfs.rst 
>> b/Documentation/filesystems/vfs.rst
>> index d3a93eec3945f..dec7816303c6a 100644
>> --- a/Documentation/filesystems/vfs.rst
>> +++ b/Documentation/filesystems/vfs.rst
>> @@ -649,8 +649,8 @@ Writeback.
>>
>>  The first can be used independently to the others.  The VM can try to
>>  release clean pages in order to reuse them.  To do this it can call
>> -->release_folio on clean folios with the private
>> -flag set.  Clean pages without PagePrivate and with no external references
>> +->release_folio on clean folios with folio->private set. Clean pages
>> +without folio->private set and with no external references
>>  will be released without notice being given to the address_space.
>>
>>  To achieve this functionality, pages need to be placed on an LRU with
>> @@ -674,7 +674,7 @@ filemap_fdatawait_range, to wait for all writeback to 
>> complete.
>>
>>  An address_space handler may attach extra information to a page,
>>  typically using the 'private' field in the 'struct page'.  If such
>> -information is attached, the PG_Private flag should be set.  This will
>> +information is attached, non-NULL 'private' field will
>>  cause various VM routines to make extra calls into the address_space
>>  handler to deal with that data.
>>
>> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
>> index 9b585e68127a2..eb2961ed61018 100644
>> --- a/include/linux/page-flags.h
>> +++ b/include/linux/page-flags.h
>> @@ -44,10 +44,6 @@
>>   * Consequently, PG_reserved for a page mapped into user space can indicate
>>   * the zero page, the vDSO, MMIO pages or device memory.
>>   *
>> - * The PG_private bitflag is set on pagecache pages if they contain 
>> filesystem
>> - * specific data (which is normally at page->private). It can be used by
>> - * private allocations for its own usage.
>> - *
>>   * During initiation of disk I/O, PG_locked is set. This bit is set before 
>> I/O
>>   * and cleared when writeback _starts_ or when read _completes_. 
>> PG_writeback
>>   * is set before writeback starts and cleared when it finishes.
>> @@ -105,7 +101,7 @@ enum pageflags {
>>      PG_owner_2,             /* Owner use. If pagecache, fs may use */
>>      PG_arch_1,
>>      PG_reserved,
>> -    PG_private,             /* If pagecache, has fs-private data */
>> +    __PG_folio,             /* Do not use: reserved for folio 
>> identification */
>>      PG_private_2,           /* If pagecache, has fs aux data */
>>      PG_reclaim,             /* To be reclaimed asap */
>>      PG_swapbacked,          /* Page is backed by RAM/swap */
>> @@ -576,7 +572,7 @@ FOLIO_FLAG(swapbacked, FOLIO_HEAD_PAGE)
>>  /*
>>   * Private page markings that may be used by the filesystem that owns the 
>> page
>>   * for its own purposes.
>> - * - PG_private and PG_private_2 cause release_folio() and co to be invoked
>> + * - folio->private and PG_private_2 cause release_folio() and co to be 
>> invoked
>>   */
>>
>>  static __always_inline bool folio_test_private(const struct folio *folio)
>> @@ -584,17 +580,6 @@ static __always_inline bool folio_test_private(const 
>> struct folio *folio)
>>      return folio->private;
>>  }
>>
>> -static __always_inline int PagePrivate(const struct page *page)
>> -{
>> -    return !!page->private;
>> -}
>> -
>> -/* no-ops during transition */
>> -static __always_inline void folio_set_private(struct folio *folio) { }
>> -static __always_inline void folio_clear_private(struct folio *folio) { }
>> -static __always_inline void SetPagePrivate(struct page *page) { }
>> -static __always_inline void ClearPagePrivate(struct page *page) { }
>> -
>>  FOLIO_FLAG(private_2, FOLIO_HEAD_PAGE)
>>
>>  /* owner_2 can be set on tail pages for anon memory */
>> diff --git a/include/trace/events/mmflags.h b/include/trace/events/mmflags.h
>> index 935893e5ea53b..caf090cd6f85e 100644
>> --- a/include/trace/events/mmflags.h
>> +++ b/include/trace/events/mmflags.h
>> @@ -144,7 +144,7 @@ TRACE_DEFINE_ENUM(___GFP_LAST_BIT);
>>      DEF_PAGEFLAG_NAME(owner_2),                                     \
>>      DEF_PAGEFLAG_NAME(arch_1),                                      \
>>      DEF_PAGEFLAG_NAME(reserved),                                    \
>> -    DEF_PAGEFLAG_NAME(private),                                     \
>> +    { 1UL << __PG_folio, "folio" },                                 \
>>      DEF_PAGEFLAG_NAME(private_2),                                   \
>>      DEF_PAGEFLAG_NAME(writeback),                                   \
>>      DEF_PAGEFLAG_NAME(head),                                        \
>> diff --git a/kernel/vmcore_info.c b/kernel/vmcore_info.c
>> index 8614430ca212a..5a417f8a922ab 100644
>> --- a/kernel/vmcore_info.c
>> +++ b/kernel/vmcore_info.c
>> @@ -216,7 +216,6 @@ static int __init crash_save_vmcoreinfo_init(void)
>>      VMCOREINFO_LENGTH(free_area.free_list, MIGRATE_TYPES);
>>      VMCOREINFO_NUMBER(NR_FREE_PAGES);
>>      VMCOREINFO_NUMBER(PG_lru);
>> -    VMCOREINFO_NUMBER(PG_private);
>>      VMCOREINFO_NUMBER(PG_swapcache);
>>      VMCOREINFO_NUMBER(PG_swapbacked);
>>  #define PAGE_SLAB_MAPCOUNT_VALUE    (PGTY_slab << 24)
>
> + kdump maintainers and reviewers.

Thanks.

>
> I believe makedumpfile reads VMCOREINFO. Removing it here, might cause issues
> for older makedumpfile versions at crashdump?

The expectation is that kdump userspace tools will adapt to this change.
Later, PG_folio will be added to identify folios and has the same value
of PG_private, so preserving PG_private will not work then.
>
> Hopefully kdump folks will be able to comment better.



Best Regards,
Yan, Zi

Reply via email to