On Apr 7, 2025, at 16:59, Christoph Hellwig hch@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.