CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP is broken, was Re: [RFC PATCH 0/6] Deep talk about folio vmap

[Muchun Song]

> On Apr 7, 2025, at 16:59, Christoph Hellwig <hch at lst.de> wrote:
> 
> On Mon, Apr 07, 2025 at 02:43:20PM +0800, Muchun Song wrote:
>> By the way, in case you truly struggle to comprehend the fundamental
>> aspects of HVO, I would like to summarize for you the user-visible
>> behaviors in comparison to the situation where HVO is disabled.
>> 
>> HVO Status Tail Page Structures Head Page Structures
>> Enabled Read-Only (RO) Read-Write (RW)
>> Disabled Read-Write (RW) Read-Write (RW)
>> 
>> The sole distinction between the two scenarios lies in whether the
>> tail page structures are allowed to be written or not. Please refrain
>> from getting bogged down in the details of the implementation of HVO.
> 
> This feels extremely fragile to me.  I doubt many people know what
> operations needs read vs write access to tail pages.  Or for higher
> level operations if needs access to tail pages at all.
> 

A compound page should modify its head page structure (e.g., refcount),
which is why `compound_head()` is widely used. Modifying its tail page
structures is incorrect. Users needn't worry about whether to modify
tail page structures. They should use `compound_head(tail)` to get the
head page structure and update it. All users must follow this rule (I
think folio-infrastructure also requires this). If a user tries to write
to a HugeTLB page's tail page, an exception will be raised as these tail
pages are read-only mapped to catch invalid operations.