linux-kernel - Re: [PATCH] mm/hugetlb: Convert &folio->page to folio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <c203836f-5a3c-4143-a898-1fb2bbbfda2c@redhat.com>
Date: Wed, 23 Apr 2025 21:16:47 +0200
From: David Hildenbrand <david@...hat.com>
To: Matthew Wilcox <willy@...radead.org>, Fan Ni <nifan.cxl@...il.com>
Cc: muchun.song@...ux.dev, mcgrof@...nel.org, a.manzanares@...sung.com,
 dave@...olabs.net, akpm@...ux-foundation.org, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm/hugetlb: Convert &folio->page to folio_page(folio, 0)

On 23.04.25 20:50, Matthew Wilcox wrote:
> On Fri, Apr 18, 2025 at 03:42:45PM -0700, Fan Ni wrote:
>>>>   	result = install_pmd
>>>> -			? set_huge_pmd(vma, haddr, pmd, &folio->page)
>>>> +			? set_huge_pmd(vma, haddr, pmd, folio_page(folio, 0))
>>>>   			: SCAN_SUCCEED;
>>>
>>> I feel that set_huge_pmd() should take a folio.
>> There is a patch on the mailing list for it,
>> https://lore.kernel.org/linux-mm/20240817095122.2460977-5-wangkefeng.wang@huawei.com/
>>
>> If the above patch is needed, do_set_pmd() should be converted to use folio.
> 
> Maybe?  I think we'll eventually want to support folios larger than PMD
> size.  So I don't want to pass in a folio here unless we can calculate the
> precise PMD-size chunk we want to map from this folio given the
> information available in vmf.  I know that today the implementation
> does this:
> 
>          if (folio_order(folio) != HPAGE_PMD_ORDER)
>                  return ret;
>          page = &folio->page;
> 
> but eventually we should do better than that.  And I don't want to
> lose the information about which page in the folio we really want
> to map.  So have a think about what the right interface should be
> (passing in a page?  folio + offset-in-number-of-pages?  Something
> involving the PFN?)
> 
> The obvious hurdle is folio_add_file_rmap_pmd() which today takes both a
> folio and a page.

The interface is prepared for that use case: I decided to pass in folio 
+ page to allow for folios that span multiple PMDs. (obviously, the 
internal implementation does not allow for that)

We could later change it to folio + offset, but should do so for all 
rmap functions consistently.

-- 
Cheers,

David / dhildenb