linux-kernel - Re: [PATCH v4 13/13] mm/gup: Handle hugetlb in the generic follow_page

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <98d4ef76-93e4-4e76-be60-9f0076389dc5@redhat.com>
Date: Tue, 2 Apr 2024 18:40:03 +0200
From: David Hildenbrand <david@...hat.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Ryan Roberts <ryan.roberts@....com>, peterx@...hat.com,
 linux-mm@...ck.org, linux-kernel@...r.kernel.org,
 Yang Shi <shy828301@...il.com>, "Kirill A . Shutemov"
 <kirill@...temov.name>, Mike Kravetz <mike.kravetz@...cle.com>,
 John Hubbard <jhubbard@...dia.com>, Michael Ellerman <mpe@...erman.id.au>,
 Andrew Jones <andrew.jones@...ux.dev>, Muchun Song <muchun.song@...ux.dev>,
 linux-riscv@...ts.infradead.org, linuxppc-dev@...ts.ozlabs.org,
 Christophe Leroy <christophe.leroy@...roup.eu>,
 Andrew Morton <akpm@...ux-foundation.org>,
 Christoph Hellwig <hch@...radead.org>, Lorenzo Stoakes <lstoakes@...il.com>,
 Rik van Riel <riel@...riel.com>, linux-arm-kernel@...ts.infradead.org,
 Andrea Arcangeli <aarcange@...hat.com>,
 "Aneesh Kumar K . V" <aneesh.kumar@...nel.org>,
 Vlastimil Babka <vbabka@...e.cz>, James Houghton <jthoughton@...gle.com>,
 Jason Gunthorpe <jgg@...dia.com>, Mike Rapoport <rppt@...nel.org>,
 Axel Rasmussen <axelrasmussen@...gle.com>
Subject: Re: [PATCH v4 13/13] mm/gup: Handle hugetlb in the generic
 follow_page_mask code

On 02.04.24 18:00, Matthew Wilcox wrote:
> On Tue, Apr 02, 2024 at 05:26:28PM +0200, David Hildenbrand wrote:
>>> The oops trigger is at mm/gup.c:778:
>>> VM_BUG_ON_PAGE(!PageHead(page) && !is_zone_device_page(page), page);
>>>
>>> So 2M passed ok, and its failing for 32M, which is cont-pmd. I'm guessing you're trying to iterate 2M into a cont-pmd folio and ending up with an unexpected tail page?
>>
>> I assume we find the expected tail page, it's just that the check
>>
>> VM_BUG_ON_PAGE(!PageHead(page) && !is_zone_device_page(page), page);
>>
>> Doesn't make sense with hugetlb folios. We might have a tail page mapped in
>> a cont-pmd entry. As soon as we call follow_huge_pmd() on "not the first
>> cont-pmd entry", we trigger this check.
>>
>> Likely this sanity check must also allow for hugetlb folios. Or we should
>> just remove it completely.
>>
>> In the past, we wanted to make sure that we never get tail pages of THP from
>> PMD entries, because something would currently be broken (we don't support
>> THP > PMD).
> 
> That was a practical limitation on my part.  We have various parts of
> the MM which assume that pmd_page() returns a head page and until we
> get all of those fixed, adding support for folios larger than PMD_SIZE
> was only going to cause trouble for no significant wins.
> 
> I agree with you we should get rid of this assertion entirely.  We should
> fix all the places which assume that pmd_page() returns a head page,
> but that may take some time.
> 
> As an example, filemap_map_pmd() has:
> 
>         if (pmd_none(*vmf->pmd) && folio_test_pmd_mappable(folio)) {
>                  struct page *page = folio_file_page(folio, start);
>                  vm_fault_t ret = do_set_pmd(vmf, page);
> 
> and then do_set_pmd() has:
> 
>          if (page != &folio->page || folio_order(folio) != HPAGE_PMD_ORDER)
>                  return ret;
> 
> so we'd simply refuse to use a PMD to map a folio larger than PMD_SIZE.
> There's a lot of work to be done to make this work generally (not to
> mention figuring out how to handle mapcount for such folios ;-).

Yes :)

-- 
Cheers,

David / dhildenb