From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id EC17EC83F1D for ; Sun, 13 Jul 2025 17:56:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C3936B0089; Sun, 13 Jul 2025 13:56:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 64D676B008C; Sun, 13 Jul 2025 13:56:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 53B836B0092; Sun, 13 Jul 2025 13:56:28 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3AD206B0089 for ; Sun, 13 Jul 2025 13:56:28 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D93A51603CE for ; Sun, 13 Jul 2025 17:56:27 +0000 (UTC) X-FDA: 83659996014.26.5E0EDF0 Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf08.hostedemail.com (Postfix) with ESMTP id 37DE9160009 for ; Sun, 13 Jul 2025 17:56:26 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aRL5197n; spf=pass (imf08.hostedemail.com: domain of rppt@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752429386; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=MeSCEhIf1FRB6EClK4z4L3Ptbv6JgDa2rxrLg1iYp8Q=; b=mtadzqclI18Fha01x8bAYeFr2e0jaZmikpBTCkBkSvk6ZGYsjiUG0sScMVPw0u3OLSGtNK 5PdVu5WD3D7Q4P81MMEcHDYF4vImn2Buia6D0eiEen0i4xxminCTN9u/LTUnrn004EZn7H q6ntPAIYDMy5NO06qZXRNXoOkZgUIEw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752429386; a=rsa-sha256; cv=none; b=4cDSvxMwsg4Hn/oF40YS7Fgj0Nrn6W96iF/NCXG6JlxQlsGS+nNMxeNLAf48F3jiSFzvV9 7kx8cPtTOmSYs89BC5rXqgQemqrTrHzJNOk0VDBFloWTngwLoXjz/+78saRKfh+jtZ9Zq0 V21Vc9cbM8TH+6N6uLSsnm5TG9IunYs= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=aRL5197n; spf=pass (imf08.hostedemail.com: domain of rppt@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 135E16112D; Sun, 13 Jul 2025 17:56:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 63C3AC4CEE3; Sun, 13 Jul 2025 17:56:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1752429384; bh=P+ZGpMquPfCHNe224IKptMJLR+y5tQ5d/vbWwHQvmck=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=aRL5197nqMjr05xGN5g0zw/NpBK9l35yCYREJWMyObTAyxvoeKkdbRkguviRQyWru qvE1QRGmzQ1VaF8essjumL49HXZ7Jd3v8OF7zwINCkQ0AgrJc92KRSxrY1o9bOCdLL VkLp9+/x/hMoTGF6Xcj6jz2F6PJI7OgL1JNmnF0LPTBCwnsqgNAoNNRulmzs7a2JMo L7jw0iwn/wt5L0JQLgnojswEXOudNgPt+3uOhusGR+3FkW1by9lkMz0SRd9MNYAhli G/gcpZCx+VIYKjHzKwbrv4cM0UBdtktAmhnQPB8FX/GQ6gE2tIKfgSrJy6SmVJJu0v /JXT21VQ3POhw== Date: Sun, 13 Jul 2025 20:56:10 +0300 From: Mike Rapoport To: Harry Yoo Cc: David Hildenbrand , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Andrey Ryabinin , Arnd Bergmann , Andrew Morton , Dennis Zhou , Tejun Heo , Christoph Lameter , "H . Peter Anvin" , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , Juergen Gross , Kevin Brodsky , Muchun Song , Oscar Salvador , Joao Martins , Lorenzo Stoakes , Jane Chu , Alistair Popple , Gwan-gyeong Mun , "Aneesh Kumar K . V" , x86@kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org Subject: Re: [RFC V1 PATCH mm-hotfixes 1/3] mm: introduce and use {pgd,p4d}_populate_kernel() Message-ID: References: <20250709131657.5660-1-harry.yoo@oracle.com> <20250709131657.5660-2-harry.yoo@oracle.com> <02146c79-a4de-430f-8357-0608e796fa60@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 37DE9160009 X-Stat-Signature: 3qgashnq433hwa9oncdmcc6yeqrb1ac8 X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1752429386-111986 X-HE-Meta: U2FsdGVkX1+n8+dsytG+YIM4hZv7kwo6UFs2vQ/ysB+p6sLZLTkuJQtUTMYLpLGfaiqvQwP4A3vB/UUjaLW15/CdBDNCCHq+un3I6/XZnXANrK8Ea+oTadC8uU0AMhirtLj1XNqFf0R0QoCeoQzIVMmSyk4v1/NcnWyq6ubIuCmKsPDKwgPcU+I3KpAY7L9rm1B2+4mEDZ3bilhuFL5AoP+kGQLy/a7+MN6OeIUInymihc1P0KQgvF55Ij2MEFthdM83K4NII0i0h4HOmTDeEVO9Iclk8B+B/8v86GcXcna92TDOgmC12O/UNJa/QNRSLnwfCTtoGrJxlBh4Ax8rarV1+RH95/z0pGBdyhC+tzApwx3m5XDx6OijcwZGXNREMjXlEseF2UYUvlgbvlDqRN0LvzrSDlQMKfjfkj45d65wFzhzJNyjExWt+E/nYUvG4awP2pNBOKZcjBcHyQwVBnQ7Mv8PNlAP2GPlEjkV/Us/QXK0AJIp2YTSjiW+NI0k8fbc0szQmElKKrQ1GIQV10duhGqW74X1zKwXWbsasPiW5alRoAj6WQyt1cp+9eKOhTeWejLBVeYoeHPPoHVfBDS2Ht8IzKTiSISv+8Cn5lpig8YblDW9pAtIWZgZlG8POxJhhIQdBi5heDMqniCFB9nHlOl72ZH7ifNzlYrkWAPC9IfhLDCLqiaW54qjFmEqOG0+Z9bF3m1EWxfkGZCWKEhpfYXvAODOksIKPtH2NCTtMfxbJG/W5btul9R6aueRPSszHgVPQomVyWTMyYYu36SNoN5c/3YKtFOD89a+/65lqHllUz3BbM0lX950FY1R7fGfboVg8qUZ8VKlAHX7Sr1A4ehz0WLzgDYoPHcvtqVM8D1Ccoqvi2Yz2V0rm1NM5whN48PjypHCSe2MRbJvKcmzID7Gm+1CFqHlAt25pW7nPEsol9eRc/KIKwg7MUdp472W6/CnLOT09WWuOOd Rf7I2sas oTJ88ZFd2yEOewm+j6EDU4Ij+RxjrhRFUhuDm2cAOEtTNsj1qovTloryM/NyBgNzYBF/tz7Wbqe9QtH68Ghfz8ychiVb+2cmW+xDe6kd0iMbphT+tt3a7J2n3qOHA+1dlqysWp7uHws5p1nEPbsQUQE69PBooMYamrOGvB1FPQpsTtvgFLAT9XAsfuKvQw4petHfJkTUNttMUStS3BKVeGNhOWgTOiHs1r+7ceG8HJwN2ZRczZmThRMvICvdi3To3ixA8n7b828McRrRRBAsiN2A+60y+TSpzF7abkFGwUgc1R1A6O4843cGLdSjIzrdpbo6GwxUs/2kl8XRJyr3Zu2HfcJ6n1sPBNdkR756PA3Wpy9TvJ6HXh4ociw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Sun, Jul 13, 2025 at 08:39:53PM +0900, Harry Yoo wrote: > On Fri, Jul 11, 2025 at 06:18:44PM +0200, David Hildenbrand wrote: > > On 09.07.25 15:16, Harry Yoo wrote: > > > Intrdocue and use {pgd,p4d}_pouplate_kernel() in core MM code when > > > populating PGD and P4D entries corresponding to the kernel address > > > space. The main purpose of these helpers is to ensure synchronization of > > > the kernel portion of the top-level page tables whenever such an entry > > > is populated. > > > > > > Until now, the kernel has relied on each architecture to handle > > > synchronization of top-level page tables in an ad-hoc manner. > > > For example, see commit 9b861528a801 ("x86-64, mem: Update all PGDs for > > > direct mapping and vmemmap mapping changes"). > > > > > > However, this approach has proven fragile, as it's easy to forget to > > > perform the necessary synchronization when introducing new changes. > > > > > > To address this, introduce _kernel() varients of the page table > > > > s/varients/variants/ > > Will fix. Thanks. > > > > population helpers that invoke architecture-specific hooks to properly > > > synchronize the page tables. > > > > I was expecting to see the sync be done in common code -- such that it > > cannot be missed :) > > You mean something like an arch-independent implementation of > sync_global_pgds()? > > That would be a "much more robust" approach ;) > > To do that, the kernel would need to maintain a list of page tables that > have kernel portion mapped and perform the sync in the common code. > > But determining which page tables to add to the list would be highly > architecture-specific. For example, I think some architectures use separate > page tables for kernel space, unlike x86 (e.g., arm64 TTBR1, SPARC) and > user page tables should not be affected. sync_global_pgds() can be still implemented per architecture, but it can be called from the common code. We already have something like that for vmalloc that calls arch_sync_kernel_mappings(). It's implemented only by x86-32 and arm, other architectures do not define it. > While doing the sync in common code might be a more robust option > in the long term, I'm afraid that making it work correctly across > all architectures would be challenging, due to differences in how each > architecture manages the kernel address space. > > > But it's really just rerouting to the arch code where the sync can be done, > > correct? > > Yes, that's correct. > > Thanks for taking a look! > > -- > Cheers, > Harry / Hyeonggon -- Sincerely yours, Mike.