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

Huan Yang
2025-04-07T02:00:13Z

在 2025/4/4 18:07, Muchun Song 写道:
>
>> 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

I see the document give a simple graph to point:

+-----------+ ---virt_to_page---> +-----------+   mapping to   +-----------+
|           |                                     |     0     | -------------> |     0     |
|           | +-----------+                +-----------+
|           |                                      |     1     | -------------> |     1     |
|           | +-----------+                +-----------+
|           |                                      |     2     | ----------------^ ^ ^ ^ ^ ^
|           | +-----------+                      | | | | |
|           |                                      |     3     | ------------------+ | | | |
|           | +-----------+                        | | | |
|           |                                      |     4     | --------------------+ | | |
|    PMD    | +-----------+                          | | |
|   level   |                                   |     5     | ----------------------+ | |
|  mapping  | +-----------+                             | |
|           |                                     |     6     | ------------------------+ |
|           | +-----------+                              |
|           |                                     |     7     | --------------------------+
|           |                                    +-----------+
|           |
|           |
|           |
+-----------+

If I understand correct, each 2-7 tail's page struct is freed, so if I just need map page 2-7, can we use vmap do

something correctly?

Or something I still misunderstand, please correct me.

Thanks,

Huan Yang

> 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/#t
> [3] Documentation/mm/vmemmap_dedup.rst
>
>> [1] https://lore.kernel.org/linux-mm/20250327092922.536-1-link@vivo.com/T/#m055b34978cf882fd44d2d08d929b50292d8502b4
>>
>> Thanks,
>> Muchun.
>>
>