> On Sep 5, 2026, at 16:35, Qi Zheng <[email protected]> wrote:
>
>
>
> On 8/31/26 3:53 PM, Muchun Song wrote:
>> HugeTLB vmemmap optimization now uses per-zone shared tail vmemmap pages.
>> Device DAX has not been switched to that mechanism yet.
>> Switch device DAX to vmemmap_shared_tail_page() as well. This aligns DAX
>> with HugeTLB by using the common per-zone shared tail vmemmap page.
>> Since the shared tail page can now back ZONE_DEVICE vmemmap mappings,
>
> Could you explain this in more detail?
>
> As sashiko pointed out [1], it looks like this assumption is
> problematic: dax_folio_reset_order() may end up modifying all shared
> tail pages?
I believe Sashiko's report is a false positive, because the issue Sashiko
raised is based on assumptions from code analysis for FS-DAX. Unfortunately,
the current implementation that supports HVO is DEV-DAX, and DEV-DAX does
not modify tail struct pages. Moreover, this patch itself is intended to
migrate DEV-DAX to section-based vmemmap optimization, so there is no issue
at all.
BTW, the current logic for determining whether DEV-DAX applies HVO is based
on pgmap->vmemmap_shift, and pgmap->vmemmap_shift is only assigned during the
initialization of DEV-DAX devices.
Muchun,
Thanks.
>
> [1].
> https://sashiko.dev/#/patchset/20260831075342.57563-1-songmuchun%40bytedance.com
>
>> initialize its entries with PG_reserved for device zones. Also skip
>> poisoning vmemmap-optimizable sections while their struct pages may be
>> shared.
