Re: [PATCH RFC 00/14] Remove PG_private by using page/folio->private checks instead

On Mon Aug 3, 2026 at 5:07 AM EDT, J=C3=BCrgen Gro=C3=9F wrote:
> On 01.08.26 04:13, Zi Yan wrote:
>> Hi all,
>>=20
>> This patchset removes PG_private to make space for upcoming PG_folio
>> (reserved as __PG_folio) for identifying pages from a folio (more detail=
s
>> in Note below). Instead of checking PG_private, all code is changed to
>> check page/folio->private !=3D NULL instead.
>
> I'm a little bit worried that page/folio->private is in a union, so today
> it could (in theory) be !=3D NULL while PG_private isn't set.
>
> Is it really not possible to enter a path where PG_private is tested whil=
e
> page/folio->private !=3D NULL due to the union being used otherwise (PG_p=
rivate
> not set)?

Yes, it is possible. See: #5 in the exceptional users: erofs uses
->private for reverse linked list and in-flight counters without setting
PG_private. I get rid of the first one and converted the second one to
use folio_attach/detach/get_private() to follow the general ->private
use pattern..

For non file system folios, anon swapcache puts swap_entry_t in
->private and hugetlb puts its flags in ->private. I added
folio_test_fs_private() to exclude them, but this helper is planned to
be used by core MM, since filesystem code should not encounter these
two.


--=20
Best Regards,
Yan, Zi