linux-kernel - Re: [PATCH v2 06/13] mm/gup: Drop folio_fast_pin

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]

Date: Tue, 16 Jan 2024 06:30:39 +0000
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: Jason Gunthorpe <jgg@...dia.com>, "peterx@...hat.com" <peterx@...hat.com>
CC: "linux-mm@...ck.org" <linux-mm@...ck.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, James Houghton <jthoughton@...gle.com>, David
 Hildenbrand <david@...hat.com>, "Kirill A . Shutemov" <kirill@...temov.name>,
	Yang Shi <shy828301@...il.com>, "linux-riscv@...ts.infradead.org"
	<linux-riscv@...ts.infradead.org>, Andrew Morton <akpm@...ux-foundation.org>,
	"Aneesh Kumar K . V" <aneesh.kumar@...nel.org>, Rik van Riel
	<riel@...riel.com>, Andrea Arcangeli <aarcange@...hat.com>, Axel Rasmussen
	<axelrasmussen@...gle.com>, Mike Rapoport <rppt@...nel.org>, John Hubbard
	<jhubbard@...dia.com>, Vlastimil Babka <vbabka@...e.cz>, Michael Ellerman
	<mpe@...erman.id.au>, Andrew Jones <andrew.jones@...ux.dev>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>, Mike Kravetz
	<mike.kravetz@...cle.com>, Muchun Song <muchun.song@...ux.dev>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, Christoph Hellwig
	<hch@...radead.org>, Lorenzo Stoakes <lstoakes@...il.com>, Matthew Wilcox
	<willy@...radead.org>
Subject: Re: [PATCH v2 06/13] mm/gup: Drop folio_fast_pin_allowed() in hugepd
 processing



Le 15/01/2024 à 19:37, Jason Gunthorpe a écrit :
> On Wed, Jan 03, 2024 at 05:14:16PM +0800, peterx@...hat.com wrote:
>> From: Peter Xu <peterx@...hat.com>
>>
>> Hugepd format for GUP is only used in PowerPC with hugetlbfs.  There are
>> some kernel usage of hugepd (can refer to hugepd_populate_kernel() for
>> PPC_8XX), however those pages are not candidates for GUP.
>>
>> Commit a6e79df92e4a ("mm/gup: disallow FOLL_LONGTERM GUP-fast writing to
>> file-backed mappings") added a check to fail gup-fast if there's potential
>> risk of violating GUP over writeback file systems.  That should never apply
>> to hugepd.  Considering that hugepd is an old format (and even
>> software-only), there's no plan to extend hugepd into other file typed
>> memories that is prone to the same issue.
> 
> I didn't dig into the ppc stuff too deeply, but this looks to me like
> it is the same thing as ARM's contig bits?
> 
> ie a chunk of PMD/etc entries are all managed together as though they
> are a virtual larger entry and we use the hugepte_addr_end() stuff to
> iterate over each sub entry.

As far as I understand ARM's contig stuff, hugepd on powerpc is 
something different.

hugepd is a page directory dedicated to huge pages, where you have huge 
pages listed instead of regular pages. For instance, on powerpc 32 with 
each PGD entries covering 4Mbytes, a regular page table has 1024 PTEs. A 
hugepd for 512k is a page table with 8 entries.

And for 8Mbytes entries, the hugepd is a page table with only one entry. 
And 2 consecutive PGS entries will point to the same hugepd to cover the 
entire 8Mbytes.

> 
> But WHY is GUP doing this or caring about this? GUP should have no
> problem handling the super-size entry (eg 8M on nohash) as a single
> thing. It seems we only lack an API to get this out of the arch code?
> 
> It seems to me we should see ARM and PPC agree on what the API is for
> this and then get rid of hugepd by making both use the same page table
> walker API. Is that too hopeful?

Can't see the similarity between ARM contig PTE and PPC huge page 
directories.

> 
>> Drop that check, not only because it'll never be true for hugepd per any
>> known plan, but also it paves way for reusing the function outside
>> fast-gup.
> 
> I didn't see any other caller of this function in this series? When
> does this re-use happen??
> 
> Jason


Christophe