Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
References: <20221022111403.531902164@infradead.org>
 <20221022114424.515572025@infradead.org>
 <2c800ed1-d17a-def4-39e1-09281ee78d05@nvidia.com>
 <Y1ZGNwUEdm15W6Xz@hirez.programming.kicks-ass.net>
 <CAG48ez3fG=WnvbiE5mJaD66_gJj_hohnV8CqBG9eNdjd7pJW3A@mail.gmail.com>
 <CAHk-=wjoGnHVVp5pcb69C6HtnJ_avqQo_b5NK-X9bgoDDw_XbA@mail.gmail.com>
 <CAG48ez3KMuM2aLpc8SvGiqZvv1KFc7E2DBZ4CLzxQeFhrMN_-w@mail.gmail.com>
 <Y1dWQ+YQyiz3V9Sp@casper.infradead.org>
User-agent: mu4e 1.8.10; emacs 28.2
From:   Alistair Popple <apopple@nvidia.com>
To:     Matthew Wilcox <willy@infradead.org>
Cc:     Jann Horn <jannh@google.com>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Peter Zijlstra <peterz@infradead.org>,
        John Hubbard <jhubbard@nvidia.com>, x86@kernel.org,
        akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
        linux-mm@kvack.org, aarcange@redhat.com,
        kirill.shutemov@linux.intel.com, jroedel@suse.de, ubizjak@gmail.com
Subject: Re: [PATCH 01/13] mm: Update ptep_get_lockless()s comment
Date:   Tue, 25 Oct 2022 18:54:10 +1100
In-reply-to: <Y1dWQ+YQyiz3V9Sp@casper.infradead.org>
Message-ID: <87fsfcuxu6.fsf@nvidia.com>
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?O3IiGLMfexRed2OSAcCX2QNKjuesm5SDK4bVJ0qJEJ4Fyqa2d1S0NSZ3AS1w?=
 =?us-ascii?Q?/LRN8PtcIh7VTj2pmtJBWqrZJ3NUQ/Ud9U377QA34jhZ2+40ak6frwXIzFaN?=
 =?us-ascii?Q?uopmqWkjWB72461/qho6N7BAy2pB+vWfsivqIOMdSZIVU+BcBQzb4WPRkaHr?=
 =?us-ascii?Q?LlSHuf7Axr7g+j1jtdLdnfAwMTPBS7Koh2nmUxAk9OMs4qpPcA6ZqdIZ64vN?=
 =?us-ascii?Q?oSN5ULZiPupjeMyZ8v+0YZ+2MvVdQEsBU/oI2cgOKj4DJb/jaPF5LIFwyie3?=
 =?us-ascii?Q?ae+/LNX18bkD/yNrSFV4aivzJCgq8Iwa27RuuSjy10cfXC7nV2sgxrRXmxHk?=
 =?us-ascii?Q?eSf+oMv6cwWOFMAJAXcgi88Pf5axUtQg62zMbN9JWMHDu1lAWHMMUYME0zAg?=
 =?us-ascii?Q?Y2OvYYX+ysizzENhcCc4lZrDa9nuS/bRlHr17lA0y63igt4TpTKBYt5iCKqa?=
 =?us-ascii?Q?OhoBd5E2iHiVQiEQl7VMh1+eNHfuE1XMjsk43j2/GxNeBlStps49adnkmvC9?=
 =?us-ascii?Q?6KmfIB9FSyz/IghkIqkpR3iJzNxu7/P49dbyegdmEILGqUP8kURgHof3Ntt9?=
 =?us-ascii?Q?B3YtM8w6e1ZfcrdnGOGQXQIT4pBbMKVw2jyS4Gu5uHjUmnT1jX4rrZFkNIfl?=
 =?us-ascii?Q?tLPTDxK0akco4yMWVDPwQXVsUBHf1jqNohtv9d5ip95BYoMuhirtqxQhEGa/?=
 =?us-ascii?Q?KxrhOgA0ZcMQZXtmHQV/i9fXdYioeqMNfJv/UjDhMTQ3j1161QaLbCDTbpvB?=
 =?us-ascii?Q?Bl53WiQ3ySABfdEdHz0cI4NWyA3nwCPoaFYGK0QhC6P4002NdzuEbOQk6CnG?=
 =?us-ascii?Q?bnQdBhbsf44WFvHn0fdAoKb2PSPORos71djYyV//E1t/RltHFQ4ATnaBi5bR?=
 =?us-ascii?Q?Tk4F4EaAce441WRI+7CD4r/r2p9YngpjQ9GcNpMmSTnKEZzZuduCjqxyGqRv?=
 =?us-ascii?Q?EmNoGSp36ncWH+7ihmMurVEZ+CXWrYym8hBWj99iB2rLUR+6BhNOynfCtA8X?=
 =?us-ascii?Q?gi4olbDR+xTo7ArmvtJAos6JZbujGpX/veGxKg6FJ/8d2LB9bcg/TKLDVtjl?=
 =?us-ascii?Q?OstvFr/zxo8bnbLqnSVizh2Mzf0m0+PFSTVwZxNvuUDhZsg1mR6vqpB7cfwp?=
 =?us-ascii?Q?qa2/R0I8BQshUUUkh+Oe5p4K6xXF+orN1jQg6ZFCT+/3hqeLZIxhW+UsCA9b?=
 =?us-ascii?Q?bzkhisePWQaHjC99M0a019KMeVlmYXrpqy8jOFwfdYK9iSkscsfm8W/bnBHm?=
 =?us-ascii?Q?WsurXLE5L5clWLuIwlrLcGzacvWs9r1AVULZNJN2A955IGXoVFdOhpznqL95?=
 =?us-ascii?Q?xxmK30YtLgZ+7Is07cQIyApcEnADFrIAn8ZN7leKBAce3dJCvhlfXXXTDqwS?=
 =?us-ascii?Q?38UTN2fY+0sH+owbkqsZ8WRlpJ19TPO0dHF+Jz2RSqW9PTlBLQyFFMkdLToJ?=
 =?us-ascii?Q?1bRsSqzrO72LEX4WzsvkLYalyZbWbcQuDdpncHbqrHFLcvmNKW0DHM2hVVuc?=
 =?us-ascii?Q?vCXHHQ12nV4XhK+2EZG8EnMIFip1ysJobSiT78lyrYD2Is4yIkxhEVDdBLW+?=
 =?us-ascii?Q?PWVFQsdDCmC+fse9rfUcG+z4ANBtcwEtj2LXDSFA?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7e878204-243e-4d72-70ea-08dab6608e40
X-MS-Exchange-CrossTenant-AuthSource: BYAPR12MB3176.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Oct 2022 08:11:44.9331
 (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: fiHup5dWlb4f7QXtKIMd2Y7eM5oqEhTmf5hFjU7iSD4kEbgbAVCoweDDiJ6X789K8dMe1wweP7RcOOEwih8qEQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4141
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FORGED_SPF_HELO,
        RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_NONE,
        URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


Matthew Wilcox <willy@infradead.org> writes:

> On Mon, Oct 24, 2022 at 10:23:51PM +0200, Jann Horn wrote:
>> """
>> This guarantees that the page tables that are being walked
>> aren't freed concurrently, but at the end of the walk, we
>> have to grab a stable reference to the referenced page.
>> For this we use the grab-reference-and-revalidate trick
>> from above again:
>> First we (locklessly) load the page
>> table entry, then we grab a reference to the page that it
>> points to (which can fail if the refcount is zero, in that
>> case we bail), then we recheck that the page table entry
>> is still the same, and if it changed in between, we drop the
>> page reference and bail.
>> This can, again, grab a reference to a page after it has
>> already been freed and reallocated. The reason why this is
>> fine is that the metadata structure that holds this refcount,
>> `struct folio` (or `struct page`, depending on which kernel
>> version you're looking at; in current kernels it's `folio`
>> but `struct page` and `struct folio` are actually aliases for
>> the same memory, basically, though that is supposed to maybe
>> change at some point) is never freed; even when a page is
>> freed and reallocated, the corresponding `struct folio`
>> stays. This does have the fun consequence that whenever a
>> page/folio has a non-zero refcount, the refcount can
>> spuriously go up and then back down for a little bit.
>> (Also it's technically not as simple as I just described it,
>> because the `struct page` that the PTE points to might be
>> a "tail page" of a `struct folio`.
>> So actually we first read the PTE, the PTE gives us the
>> `page*`, then from that we go to the `folio*`, then we
>> try to grab a reference to the `folio`, then if that worked
>> we check that the `page` still points to the same `folio`,
>> and then we recheck that the PTE is still the same.)
>> """
>
> Nngh.  In trying to make this description fit all kernels (with
> both pages and folios), you've complicated it maximally.  Let's
> try a more simple explanation:
>
> First we (locklessly) load the page table entry, then we grab a
> reference to the folio that contains it (which can fail if the
> refcount is zero, in that case we bail), then we recheck that the
> page table entry is still the same, and if it changed in between,
> we drop the folio reference and bail.
> This can, again, grab a reference to a folio after it has
> already been freed and reallocated. The reason why this is
> fine is that the metadata structure that holds this refcount,
> `struct folio` is never freed; even when a folio is
> freed and reallocated, the corresponding `struct folio`
> stays.

I'm probably missing something obvious but how is that synchronised
against memory hotplug? AFAICT if it isn't couldn't the pages be freed
and memory removed? In that case the above would no longer hold because
(I think) the metadata structure could have been freed.

> This does have the fun consequence that whenever a
> folio has a non-zero refcount, the refcount can
> spuriously go up and then back down for a little bit.
> (Also it's slightly more complex than I just described,
> because the PTE that we just loaded might be in the middle of
> being reallocated into a different folio.
> So actually we first read the PTE, translate the PTE into the
> `page*`, then from that we go to the `folio*`, then we
> try to grab a reference to the `folio`, then if that worked
> we check that the `page` is still in the same `folio`,
> and then we recheck that the PTE is still the same.  Older kernels
> did not make a clear distinction between pages and folios, so
> it was even more confusing.)
>
>
> Better?