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

[Muchun Song]

> On Apr 4, 2025, at 17:01, Christoph Hellwig <hch@xxxxxx> wrote:
> 
> After the btrfs compressed bio discussion I think the hugetlb changes that
> skip the tail pages are fundamentally unsafe in the current kernel.
> 
> That is because the bio_vec representation assumes tail pages do exist, so
> as soon as you are doing direct I/O that generates a bvec starting beyond
> the present head page things will blow up.  Other users of bio_vecs might
> do the same, but the way the block bio_vecs are generated are very suspect
> to that.  So we'll first need to sort that out and a few other things
> before we can even think of enabling such a feature.
> 

I would like to express my gratitude to Christoph for including me in the
thread. I have carefully read the cover letter in [1], which indicates
that an issue has arisen due to the improper use of `vmap_pfn()`. I'm
wondering if we could consider using `vmap()` instead. In the HVO scenario,
the tail struct pages do **exist**, but they are read-only. I've examined
the code of `vmap()`, and it appears that it only reads the struct page.
Therefore, it seems feasible for us to use `vmap()` (I am not a expert in
udmabuf.). Right?

[1] https://lore.kernel.org/linux-mm/20250327092922.536-1-link@xxxxxxxx/T/#m055b34978cf882fd44d2d08d929b50292d8502b4

Thanks,
Muchun.