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 E82D3CF395D for ; Thu, 19 Sep 2024 17:06:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5FEFC6B008A; Thu, 19 Sep 2024 13:06:42 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5AF236B008C; Thu, 19 Sep 2024 13:06:42 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 44FCF6B0092; Thu, 19 Sep 2024 13:06:42 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 2A38B6B008A for ; Thu, 19 Sep 2024 13:06:42 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id A0A261405FE for ; Thu, 19 Sep 2024 17:06:41 +0000 (UTC) X-FDA: 82582117002.15.7AB5736 Received: from pandora.armlinux.org.uk (pandora.armlinux.org.uk [78.32.30.218]) by imf30.hostedemail.com (Postfix) with ESMTP id 7F4768002C for ; Thu, 19 Sep 2024 17:06:38 +0000 (UTC) Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=an6X8ydO; spf=none (imf30.hostedemail.com: domain of "linux+linux-mm=kvack.org@armlinux.org.uk" has no SPF policy when checking 78.32.30.218) smtp.mailfrom="linux+linux-mm=kvack.org@armlinux.org.uk"; dmarc=pass (policy=none) header.from=armlinux.org.uk ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1726765566; h=from:from:sender: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=6mai/1zkLhhmEUxeaWpVi/QzAXrwkM3agGKBk9/iEkI=; b=WiapCMRwbZp9TTJpnUtWcmC/HvfK6esSVuSE3CEZAfeFLLhyO5Equ1yrjwJjmo5DjdV8mc z3NYsomwWUv4GMfVDaaLa+qCaiVCKofTE3OzXJ0+4BfFji7syWvOsVMDyKN0R+S0afDh0a 8Gh7w1+0eVED8YqqQEsBtH0Jpn7Klv0= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=armlinux.org.uk header.s=pandora-2019 header.b=an6X8ydO; spf=none (imf30.hostedemail.com: domain of "linux+linux-mm=kvack.org@armlinux.org.uk" has no SPF policy when checking 78.32.30.218) smtp.mailfrom="linux+linux-mm=kvack.org@armlinux.org.uk"; dmarc=pass (policy=none) header.from=armlinux.org.uk ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726765566; a=rsa-sha256; cv=none; b=7L5LidJ4vKW+/e1+5+8OX6tjN1pNYBWcnhbrx1K1rigMHHK50WDe2mLjrbk4OU2Bm213zx rs9bcb3UagYcAIcnlD96tO221f7Psz38+E16BtJ+ecQW5OPJWsinaB9bKlfDf5dYRmRMs2 oNdLj5p/7thyYO9yt79/1E+Fd6K97l4= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=armlinux.org.uk; s=pandora-2019; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6mai/1zkLhhmEUxeaWpVi/QzAXrwkM3agGKBk9/iEkI=; b=an6X8ydO0MniShvTb/kpEMvXPv jWLqY50FB2LvcWzWy8CtBFmRJwZfNMPEQcghAdDVBIoqGCOjNjnZdDrif3ndrOsa2ngT/EZbvi5MF +Wkpw7PEe7rSe1w56jAKK+KK0WJziDrsSj3FS0RaP0CxvtHB1lL1yMgZ8+U1LOqRGtUXQCiJ9kZfL YFRDBt5yNl0lgh5jSYrNZULtzwo05DU9D2w5/h7RlIY888f5fJ8OJAh9c5a4vepDklpkZzaLsXPm2 LdYt2BmHE3DVdLcbvY0KpuXlN1jlcqFVXbL1vNbNJxdRRtWfrUzI01+wCM2Gh2BBLa6q1eaTh3xr3 S6z0dMkQ==; Received: from shell.armlinux.org.uk ([fd8f:7570:feb6:1:5054:ff:fe00:4ec]:53624) by pandora.armlinux.org.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1srKbe-0000gQ-2J; Thu, 19 Sep 2024 18:06:14 +0100 Received: from linux by shell.armlinux.org.uk with local (Exim 4.96) (envelope-from ) id 1srKbV-0001gs-1e; Thu, 19 Sep 2024 18:06:05 +0100 Date: Thu, 19 Sep 2024 18:06:05 +0100 From: "Russell King (Oracle)" To: Ryan Roberts Cc: Anshuman Khandual , kernel test robot , linux-mm@kvack.org, llvm@lists.linux.dev, oe-kbuild-all@lists.linux.dev, Andrew Morton , David Hildenbrand , "Mike Rapoport (IBM)" , Arnd Bergmann , x86@kernel.org, linux-m68k@lists.linux-m68k.org, linux-fsdevel@vger.kernel.org, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Dimitri Sivanich , Alexander Viro , Muchun Song , Andrey Ryabinin , Miaohe Lin , Dennis Zhou , Tejun Heo , Christoph Lameter , Uladzislau Rezki , Christoph Hellwig Subject: Re: [PATCH V2 7/7] mm: Use pgdp_get() for accessing PGD entries Message-ID: References: <20240917073117.1531207-8-anshuman.khandual@arm.com> <202409190310.ViHBRe12-lkp@intel.com> <8f43251a-5418-4c54-a9b0-29a6e9edd879@arm.com> <82fa108e-5b15-435a-8b61-6253766c7d88@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <82fa108e-5b15-435a-8b61-6253766c7d88@arm.com> X-Rspam-User: X-Stat-Signature: zqaw896ansx8af1ftxcqqjgxth487etu X-Rspamd-Queue-Id: 7F4768002C X-Rspamd-Server: rspam11 X-HE-Tag: 1726765598-68875 X-HE-Meta: U2FsdGVkX18pnhEkWWbTmlslhjUQK69ctq6jtKv1z9LuKSnXjHkon2T28oJ1SoCbsnZbbZybKNdmdJ/p3wV4QkiGZVzd7aghsbWBIDpXChII9y9a5YsuaK1CmZPEOkVe0q+xzpaiidjTmlhdOWGy8urgfDWzrOyjrdyKHO7dExOph4Yk7xZAaPN/aiHw5rPRIj1bCxpk/xCv8ZkRhgslIGr56b+u03t0VeKpM2LRyftlq72cOWha6XOH+NfNHmngvQreoYcDze0beIQEZldhQ9K2ZU71az3WDyWai8ANgKkhJ2UBVTy2lja7n2bCWTuhUnUZ/47Hg+LOaKCagqDsd3xQnrNRWDi0HJmDQSflKkhX4g1D+l6pdNpL7P1xaFlhMOGGlZ+S0JIW4Qe/P6DSbLm68S8GiIX0UMdE852Sz1S0azYe/S1HHSTXdlEuO16yiJeHKKEiq91dvtBA0rCZvzvtKsV/MqyEAuH0kDZyNHS1A8RJyNbXfKXPAeHbu7fznl8MxYRvsV7ssW567n0xMaoOD+/veyI2c6DktH4coWXt32RWlNO17XYn/yz7TKxellfN/6+Ew4aOps3eEd2HZajVt8lISsV8nMOX3/MBBjEKtinoiUTAewgMbjr8Xo4gWsS0qNrxtINFNowd+K2eHp+5Lrb+onZH7kfWiwhGMZernEWTbO7LuCmauXtiKoCkLlXpywUSzB8jUUqy/zb2yBqJEWrYk/ChwYwb8v7WGVg5nEVtVc2ah8k8m9YGzkO9VmuVSN060jk5qqyxyl5TekczJAm5Q5p8TS0lB9vSUY89/IsgDQiL9Axtq0g7doQMitYxBOQK5ghMzdeyjyIT6iRbwPeH4xmVM5DZhOZY8Yz28usPVYi/QCHg+8clvWvOhfDATh6iCFZZGxVJRRzqbL+Kvs47hIu/lm0ZZN3Exs37NKVQaVIRaUX3UBw3V+RBblBImc1ltiNSFNHx6gO U/Jz34sk vAvF5EvHeFklbKAoAngvAA7Oom4a5VPBj1lbPusuu2dagLGwP58zW3ZQqN+5+6Ozo19tIF8AlSkkbymobOriKZmybUzmFpx9YYpJVWejyvF5BFPhB/mqsBdB22W0e3rWMyOzYMde2wDX9+Fwg9XSJzpnOxuIW4qPM8mVY7AjrfWELMEd0Bk2jGj34etGGBWC9fKowwMc5yNdCkWrzazpbka90aIP4kg25REV/WDkrx9dhtt3KZ+YD6r5MmJFCj1kZx2VbWCjiULC3W1qQZ6dy7yPmjhC7TWWiIoFT/1ylKHEofY1TDeb9RGsR1CBeSHe+dPuAKVJE82U/igYpAMrWm1sAY/XwqEfXLpDxNJqO5Hu7ZIEQlzafBlrFU8dNP+LHxsmzHyutbDMBTTWqTVnl7Sdv9rnkqg8QWFHYp77KV7joa9AtmILvYGV/kUBOGKYrMpGLaP5kNtJmNWsgpuZS9WIdifF3s+1K2PitM9dvtcq13ql/s9E8thMauzKDAX25oWEk/E+fdYe4DctBlJu6JnBqBop77SoDecbgoCT/IEngqSbqaA3XPSm1coDpRWgowCdF+Fe+H6tiEtA7uo5cT2gE0EIbAHY35sC1 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 Thu, Sep 19, 2024 at 05:48:58PM +0200, Ryan Roberts wrote: > > 32-bit arm uses, in some circumstances, an array because each level 1 > > page table entry is actually two descriptors. It needs to be this way > > because each level 2 table pointed to by each level 1 entry has 256 > > entries, meaning it only occupies 1024 bytes in a 4096 byte page. > > > > In order to cut down on the wastage, treat the level 1 page table as > > groups of two entries, which point to two consecutive 1024 byte tables > > in the level 2 page. > > > > The level 2 entry isn't suitable for the kernel's use cases (there are > > no bits to represent accessed/dirty and other important stuff that the > > Linux MM wants) so we maintain the hardware page tables and a separate > > set that Linux uses in the same page. Again, the software tables are > > consecutive, so from Linux's perspective, the level 2 page tables > > have 512 entries in them and occupy one full page. > > > > This is documented in arch/arm/include/asm/pgtable-2level.h > > > > However, what this means is that from the software perspective, the > > level 1 page table descriptors are an array of two entries, both of > > which need to be setup when creating a level 2 page table, but only > > the first one should ever be dereferenced when walking the tables, > > otherwise the code that walks the second level of page table entries > > will walk off the end of the software table into the actual hardware > > descriptors. > > > > I've no idea what the idea is behind introducing pgd_get() and what > > it's semantics are, so I can't comment further. > > The helper is intended to read the value of the entry pointed to by the passed > in pointer. And it shoiuld be read in a "single copy atomic" manner, meaning no > tearing. Further, the PTL is expected to be held when calling the getter. If the > HW can write to the entry such that its racing with the lock holder (i.e. HW > update of access/dirty) then READ_ONCE() should be suitable for most > architectures. If there is no possibility of racing (because HW doesn't write to > the entry), then a simple dereference would be sufficient, I think (which is > what the core code was already doing in most cases). The core code should be making no access to the PGD entries on 32-bit ARM since the PGD level does not exist. Writes are done at PMD level in arch code. Reads are done by core code at PMD level. It feels to me like pgd_get() just doesn't fit the model to which 32-bit ARM was designed to use decades ago, so I want full details about what pgd_get() is going to be used for and how it is going to be used, because I feel completely in the dark over this new development. I fear that someone hasn't understood the Linux page table model if they're wanting to access stuff at levels that effectively "aren't implemented" in the architecture specific kernel model of the page tables. Essentially, on 32-bit 2-level ARM, the PGD is merely indexed by the virtual address. As far as the kernel is concerned, each entry is 64-bit, and the generic kernel code has no business accessing that through the pgd pointer. The pgd pointer is passed through the PUD and PMD levels, where it is typecast down through the kernel layers to a pmd_t pointer, where it becomes a 32-bit quantity. This results in only the _first_ level 1 pointer being dereferenced by kernel code to a 32-bit pmd_t quantity. pmd_page_vaddr() converts this pmd_t quantity to a pte pointer (which points at the software level 2 page tables, not the hardware page tables.) So, as I'm now being told that the kernel wants to dereference the pgd level despite the model I describe above, alarm bells are ringing. I want full information please. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!