On 9 Sep 2026, at 10:50, David Hildenbrand (Arm) wrote: > On 9/9/26 16:48, Zi Yan wrote: >> On 9 Sep 2026, at 10:31, David Hildenbrand (Arm) wrote: >> >>> On 9/8/26 04:56, Zi Yan 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. >>>> >>>> __DEF_PAGEFLAG_NAME() is added to show __PG_folio. >>>> >>>> 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 | 3 ++- >>>> kernel/vmcore_info.c | 1 - >>>> 5 files changed, 8 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. >>> >>> This reads like it would belong into patch #13? >>> >>>> >>>> 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 >>> >>> Same here? >>> >>> Likely this could have been restructured to cause less head scratches. I'd >>> expect any documentation that refers to PG_private to get removed before >>> finally >>> removing the bit. >>> >>> Not the end of the world, just a bit confusing while reviewing. >> >> Yeah, I will fold the document changes into the corresponding code change >> patches. >> >>> >>>> 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 ce7fccd90367b..7b7783c0a5216 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 */ >>> >>> Do we really have to annotate it with __PG_folio ? I'd just keep it simple >>> and >>> have the comment. That also avoids __DEF_PAGEFLAG_NAME just for this use >>> case. >>> >>> (sorry if this was discussed in previous review rounds) >> >> No one complained about this yet. :) >> >> I do this because I do not want to change PG_* values after PG_private after >> PG_private is removed. And they will be changed back to their original values >> when I add PG_folio. That PG_* value churn might be a headache for kdump? >> If I add PG_folio the last page flag, it can be a one-time change though. > > Sorry, I meant that you just use > > PG_folio, /* Do not use: reserved for folio identification */ > > Without any further churn. Or is there a problem with this?
Probably not. Let me do that. Best Regards, Yan, Zi
