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

[Muchun Song <muchun.song@linux.dev>]

> On Apr 7, 2025, at 09:59, Huan Yang <link@vivo.com> wrote:
> 
> 
> 在 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?

The answer is you can. It is essential to distinguish between virtual
address (VA) and physical address (PA). The VAs of tail struct pages
aren't freed but remapped to the physical page mapped by the VA of the
head struct page (since contents of those tail physical pages are the
same). Thus, the freed pages are the physical pages mapped by original
tail struct pages, not their virtual addresses. Moreover, while it
is possible to read the virtual addresses of these tail struct pages,
any write operations are prohibited since it is within the realm of
acceptability that the kernel is expected to perform write operations
solely on the head struct page of a compound head and conduct read
operations only on the tail struct pages. BTW, folio infrastructure
is also based on this assumption.

Thanks,
Muchun.

> 
> 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.
>>> 
>>