> On Sep 8, 2026, at 17:09, Qi Zheng <[email protected]> wrote:
>
>
>
> On 9/8/26 11:03 AM, Muchun Song wrote:
>> The device DAX vmemmap population still reserves one extra tail vmemmap
>> page after the head page.
>> Drop that extra reservation and let the shared tail page cover all tail
>> vmemmap pages after the head page, so DAX follows the same reservation
>> model as HugeTLB.
>> This reduces the reserved vmemmap pages for optimized DAX mappings to
>> one and removes the now-unneeded first-tail population from the generic
>> and powerpc paths to simplify the code as well.
>> Signed-off-by: Muchun Song <[email protected]>
>> ---
>> arch/powerpc/mm/book3s64/radix_pgtable.c | 46 ++----------------------
>> include/linux/mm.h | 3 +-
>> mm/mm_init.c | 2 +-
>> mm/sparse-vmemmap.c | 13 ++-----
>> 4 files changed, 7 insertions(+), 57 deletions(-)
>
> Looks like sashiko's response [1] is a false positive.
>
> [1].
> https://sashiko.dev/#/patchset/20260908030335.96549-1-songmuchun%40bytedance.com
>
> __SetPageReserved() in vmemmap_shared_tail_page() marks the struct page
> entries stored inside the shared vmemmap backing page, i.e. the metadata
> templates that later represent DEV-DAX tail pages. It does not mark the
> struct page of the backing page itself.
>
> On hot-remove, free_vmemmap_pages() is called with pte_page(*pte), which
> is the backing page. That page is not reserved, so the teardown goes
> through __free_pages(), not free_reserved_pages().
>
> Right?
Absolutely right.
>
> If so:
>
> Acked-by: Qi Zheng <[email protected]>
Thanks.
