Received-SPF: pass (google.com: domain of linux-kernel+bounces-26397-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Mon, 15 Jan 2024 14:37:48 -0400
From: Jason Gunthorpe <jgg@nvidia.com>
To: peterx@redhat.com
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	James Houghton <jthoughton@google.com>,
	David Hildenbrand <david@redhat.com>,
	"Kirill A . Shutemov" <kirill@shutemov.name>,
	Yang Shi <shy828301@gmail.com>, linux-riscv@lists.infradead.org,
	Andrew Morton <akpm@linux-foundation.org>,
	"Aneesh Kumar K . V" <aneesh.kumar@kernel.org>,
	Rik van Riel <riel@surriel.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Mike Rapoport <rppt@kernel.org>, John Hubbard <jhubbard@nvidia.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Christophe Leroy <christophe.leroy@csgroup.eu>,
	Andrew Jones <andrew.jones@linux.dev>,
	linuxppc-dev@lists.ozlabs.org,
	Mike Kravetz <mike.kravetz@oracle.com>,
	Muchun Song <muchun.song@linux.dev>,
	linux-arm-kernel@lists.infradead.org,
	Christoph Hellwig <hch@infradead.org>,
	Lorenzo Stoakes <lstoakes@gmail.com>,
	Matthew Wilcox <willy@infradead.org>
Subject: Re: [PATCH v2 06/13] mm/gup: Drop folio_fast_pin_allowed() in hugepd
 processing
Message-ID: <20240115183748.GR734935@nvidia.com>
References: <20240103091423.400294-1-peterx@redhat.com>
 <20240103091423.400294-7-peterx@redhat.com>
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240103091423.400294-7-peterx@redhat.com>
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0:
	=?us-ascii?Q?m5QXqIddeL91NXMRxH4Uhbm4kQnyOX6HVsDIEbKpqiG+4PGO8IiaDLf0K5tR?=
 =?us-ascii?Q?IGSqxvFVSSmNerD1UaysnGHjSNoRWCr8Kv7B7FFmra2vUdsE4soiIkTbLc9Q?=
 =?us-ascii?Q?gpmkxGHY7Lp9xhviDJxGG0xJSl1uPWgdYW/MnAMRtJgNqj2yENxk2uhfHVZ2?=
 =?us-ascii?Q?CbIzE8JkfvR2WUKAVuzkV7cqJqtnAxNbM3CGr/PCspOoSot5EZ+iHeKJmhQp?=
 =?us-ascii?Q?ORg8dPKRLBh2dIxxU/VkuSAqarek5MOAyZk4oTK47FJ5KnY8TM9rzERNj699?=
 =?us-ascii?Q?+XMNN5KDe2JiKsvynSKqm1YGZUnJGsBF6T0wcDF/By2SRTT+/1K5n7qLiGN+?=
 =?us-ascii?Q?28XTLxtLlyr9EW7usdUJa8PMHiAyVRrin8H0tMx/AlZQiYwxK4DixfueEwI5?=
 =?us-ascii?Q?pTmIJbJhRsOZoVwd4KLVyh7Rufkw27UHjCMrBE6hnj+ZulPW/jxBdK/Prazv?=
 =?us-ascii?Q?+5TU/xGoyE6SYmC5tTOCisWC5ngKR/ThJUTwtS7eFpuiIJC5roJf+ObVY7N7?=
 =?us-ascii?Q?6kiROaIh1D/YanrIw2nlqhOFkU6gvPmszbYnIKiXKwSESobd+FZtz8nV4VGX?=
 =?us-ascii?Q?PseeE3ILoZktSbxFbhR/oJz+9jpnjsOK/P7dZH7eswCBJih9aAtIx1KX7dx8?=
 =?us-ascii?Q?AaBIjbA+T5TYBnAE9x/4xG+JgRnPUIux37/suInYHfd80+uwwxFRm6LE7LgF?=
 =?us-ascii?Q?usiCdtFDO5d7ZYSxTPbudO4zJqYCTXXnj8BEKTx5BxuPKe8SDTnghpCs25N0?=
 =?us-ascii?Q?20QdD6GvjvyEu1xDotg8iJcCMy3uMQ1nYXA1mOIeBUvmHhPiaYs9PV1czWV9?=
 =?us-ascii?Q?uQ1vZyg4X7217CaRyStcdLN82C+y/AkR1cXpW3Jz7g6PANvx2Pgbmz9avujV?=
 =?us-ascii?Q?TIm5guhgLjFGT3lwDgQtDvymt93hBmPqufpF9S0PtlHMmD0LGW81gk6PFC8s?=
 =?us-ascii?Q?35gBRMhVBWcEne4POgnI4Ajqk0vUULd67qo5ibzdXSvklH8IDlkLl4dwuFZh?=
 =?us-ascii?Q?ymsxdV64jY3+Fnd7pTZOkNbeGS60lIP0nldZrprp3qhBVjTypSWAAINSscVV?=
 =?us-ascii?Q?uHJBjHPIZRTnt5qEedcn2inFFcgWCWJvsd776ZTxQl81QX8x+NV2wiFnAXJn?=
 =?us-ascii?Q?ya0Eq8WmTQ908Kg1LZZcOKpJvTDxpTDWYreS6wAhVNJ6UjzQz4eKDt1fwEdH?=
 =?us-ascii?Q?5JfyJFM241llTZYVgZGXvj/AS3eoqoyhWKJB7V0CtlxwTUINydjb9fbNHmyk?=
 =?us-ascii?Q?i+f//7NADvkDzCfmBl/WIpGB8umB3kyLO04JuS7LBozcTKnK8BbxUwWulWaI?=
 =?us-ascii?Q?uydUWJ0tva2r8sppmC/Wzm5bF/iO/q6EiUK8Snbe1dKpBEbBZkU15CSQVsvj?=
 =?us-ascii?Q?JwHPIxypoCueN6GAUE7V6vnIyKjeVOMLLUCqwXsyKE71JuWWEcqZkD2+3erj?=
 =?us-ascii?Q?v/ejxhfI2a44inKW3Bb3aeOFmhCTXA8Bq7xoVBZjS0EA9UCUtAxNABFD7uKY?=
 =?us-ascii?Q?ZSNTWl0J6Kn3d+dNOTv8o6GXKP3KUFEm02/du27wp5bALPBkuWBCQX/uKtuW?=
 =?us-ascii?Q?ykvnDEHgC+YuIA8xnirfEUX8tD9vuVpsszImLq3H?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 06ebd5d6-34bd-4179-4b7c-08dc15f9133a
X-MS-Exchange-CrossTenant-AuthSource: LV2PR12MB5869.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2024 18:37:49.4941
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: XQurqgZ/9Llavqp3HGEPNNUnZ+2dzwegzvxUdWvdyZgW8AYv2hfdhumQnB9vock/
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7792

On Wed, Jan 03, 2024 at 05:14:16PM +0800, peterx@redhat.com wrote:
> From: Peter Xu <peterx@redhat.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.

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?

> 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