On Apr 4, 2025, at 17:38, Muchun Song muchun.song@linux.dev wrote:
On Apr 4, 2025, at 17:01, Christoph Hellwig hch@lst.de 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?
I believe my stance is correct. I've also reviewed another thread in [2]. Allow me to clarify and correct the viewpoints you presented. You stated: " So by HVO, it also not backed by pages, only contains folio head, each tail pfn's page struct go away. " This statement is entirely inaccurate. The tail pages do not cease to exist; rather, they are read-only. For your specific use-case, please use `vmap()` to resolve the issue at hand. If you wish to gain a comprehensive understanding of the fundamentals of HVO, I kindly suggest a thorough review of the document in [3].
[2] https://lore.kernel.org/lkml/5229b24f-1984-4225-ae03-8b952de56e3b@vivo.com/#... [3] Documentation/mm/vmemmap_dedup.rst
[1] https://lore.kernel.org/linux-mm/20250327092922.536-1-link@vivo.com/T/#m055b...
Thanks, Muchun.