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 6589AC77B7C for ; Thu, 11 May 2023 05:58:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 83FEA6B0072; Thu, 11 May 2023 01:58:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7F0136B0074; Thu, 11 May 2023 01:58:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B86C6B0075; Thu, 11 May 2023 01:58:16 -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 5D9146B0072 for ; Thu, 11 May 2023 01:58:16 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 4F1F2161393 for ; Thu, 11 May 2023 04:41:26 +0000 (UTC) X-FDA: 80776725372.28.2A363DB Received: from mail-qk1-f174.google.com (unknown [209.85.222.174]) by imf05.hostedemail.com (Postfix) with ESMTP id 7AEA9100003 for ; Thu, 11 May 2023 04:41:23 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=google.com header.s=20221208 header.b=gnIzLnb5; spf=temperror (imf05.hostedemail.com: error in processing during lookup of hughd@google.com: DNS error) smtp.mailfrom=hughd@google.com; dmarc=temperror reason="server fail" header.from=google.com (policy=temperror) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683780083; 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=+p7cDTQzCuKi1QAFDlX+tde47HjymadRIrRiXpBnjrE=; b=jkURzOKAkM7ZxGZCtLA07WMl0dLpamEnaYm+SIX0c0+fwrbdmxOAhfOgMkhBNt0VhmGnpN +rUbGRwtqfRKPV1Ogoq4jWJQpfu2CQA2+0fA0cflMkgLyJgNPH/KJHFXR2SHLwF3tiVNU5 Fk9i7CM4VSs1hXf4rEMEO7OGfNHhXsk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683780083; a=rsa-sha256; cv=none; b=spCsyBCNkWoI1czAXPOF4Sylvn5Utal7xtMYQgM7EY4ffjOVCEHbwSNOlyl6rH5GcgoNpr bR951JuDAYB7hu61JIwYJD06qimNWLA7n/XSenOpinRrRaHEi9iaaIFwwtHPFiLnOm2EQf 5LcLcHV7HVGRiuxNAXl7QIlwWb/9ulo= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=temperror ("DNS error when getting key") header.d=google.com header.s=20221208 header.b=gnIzLnb5; spf=temperror (imf05.hostedemail.com: error in processing during lookup of hughd@google.com: DNS error) smtp.mailfrom=hughd@google.com; dmarc=temperror reason="server fail" header.from=google.com (policy=temperror) Received: by mail-qk1-f174.google.com with SMTP id af79cd13be357-75783ac48e7so356612985a.0 for ; Wed, 10 May 2023 21:41:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1683780073; x=1686372073; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:from:to:cc:subject:date:message-id:reply-to; bh=+p7cDTQzCuKi1QAFDlX+tde47HjymadRIrRiXpBnjrE=; b=gnIzLnb5h1M5BVckwh0shhJS+plq8hjI8gYOvhtF5JLJJU4povPDc+iaVs/Vhmyeci ZDJOrDYpTblzHGtT1lSNZmeSm0Mfuncn1gyD2pAEZOffeno2b5RvTt7QNbqRQn9gGpu5 w8/6WW+KOV3CdVgacA5VPS4venwyzKKQXV+x7LP5tDWdI4SG2DZOXG5qFK3yP+Vt73u8 XnUhPPrVmvF61VSL6iqNTD48eCqqqgywJnnNajIjUe+OcI5/j/KgwA4ER0iOPrXoCxwU ZZUKo/P0WeaGGfABe/CJiFylpJdIMseNcR1yJ4/ehGOimpgsWuf7Uzg3xi7FcE6FCYBX NyWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683780073; x=1686372073; h=mime-version:references:message-id:in-reply-to:subject:cc:to:from :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+p7cDTQzCuKi1QAFDlX+tde47HjymadRIrRiXpBnjrE=; b=QodekmZXMJ0KRjEz+/rGgI42WqbFF1rQr9IisYEkJAdBjuGGw9EOIXOLQ00JfAXnG3 JauE3/1CzbySD8odiv9A5F6ZuKVMy9ikj7Ud0s2nq/IB1oVjQIPDiFfx7xTehcymNSHk Rkbw1idM9KUhU56TLJPiDSPVREKSmmA6Lqc1oSTsKSx91tH0NOxhqQEYiYOBMV2MdFr1 D5rGzjR6c/fyDYkr49zwaBiCAP4r9N1D/rNiR8RjH3RXTCZy/4UflkP9HDUD9E0gA7FM 0c+Ox1ZkTF4zxAaBJRZx8dKgQFqFGAXzUh/i8sVpWGt+i5w6VQ8cJUCmWV19AHDqJ3sk KPCA== X-Gm-Message-State: AC+VfDyNiCfO6V8cxmx2Br4+ZAai5ZUje5ruF9oZuuLJIF2MNuBAAy9X CgEcQ1fULmgqKmApqj0FaIJQkXJ9vPcjk/H/SLUSslW/ X-Google-Smtp-Source: ACHHUZ4jNGBbv4gj0OghzQ/5FaHnsUorF/gO/2yZgUAa0GVD52UTO1h980KsCPnjFH9AHSAArpdGLQ== X-Received: by 2002:a25:4884:0:b0:b9d:fe06:1f5b with SMTP id v126-20020a254884000000b00b9dfe061f5bmr18740294yba.15.1683779748403; Wed, 10 May 2023 21:35:48 -0700 (PDT) Received: from ripple.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id a81-20020a251a54000000b00b7767ca749esm4213494yba.59.2023.05.10.21.35.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 10 May 2023 21:35:47 -0700 (PDT) Date: Wed, 10 May 2023 21:35:44 -0700 (PDT) From: Hugh Dickins X-X-Sender: hugh@ripple.attlocal.net To: Matthew Wilcox cc: Hugh Dickins , Andrew Morton , Mike Kravetz , Mike Rapoport , "Kirill A. Shutemov" , David Hildenbrand , Suren Baghdasaryan , Qi Zheng , Russell King , Catalin Marinas , Will Deacon , Geert Uytterhoeven , Greg Ungerer , Michal Simek , Thomas Bogendoerfer , Helge Deller , John David Anglin , "Aneesh Kumar K.V" , Michael Ellerman , Alexandre Ghiti , Palmer Dabbelt , Heiko Carstens , Christian Borntraeger , Claudio Imbrenda , John Paul Adrian Glaubitz , "David S. Miller" , Chris Zankel , Max Filippov , Peter Zijlstra , x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 00/23] arch: allow pte_offset_map[_lock]() to fail In-Reply-To: Message-ID: References: <77a5d8c-406b-7068-4f17-23b7ac53bc83@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Stat-Signature: njf787db7npdjtekecao869xsmuacwja X-Rspamd-Server: rspam03 X-Rspam-User: X-Rspamd-Queue-Id: 7AEA9100003 X-HE-Tag: 1683780083-258681 X-HE-Meta: U2FsdGVkX18iUzN11TOk2wELjbxiH10wedy7/aehww3wNzkNT0YDgIc07TxyEH6BMifstdwDGAPY5a1ylVm8O4dHMUQY4ymrnqKDNwxmtteJq0vfIktSALhVcSpINJ319ebQO41F8ntPxonQ0K2c4bisBUa0Wa2rUUzIDh4c0lhPyJ8Bi+gqRDGjkDI0jcRLZP4aG8UrQJGmVaqIYf+TTtRSiouXF4SCIf1WhWhb6sNlT22fxtKI3PbEdZ0uKnJ6I3aeB6RPzANZnZUC6R1HsvZCQKKtKOKbnPmX58feoN0oyY67FSY4cmTwialUQz2Amcw6yeKBuK/X3Yw8RI74rZR/k/Ndmsl4s3yP+DwRXvwvVkZXJWa+Nv3/16bOy/TyIJ0paILhOWC+2W71yZFUm5+YAatsQNCf52UMiCTGoChgi6ZfZVTbx5wb+egjwZJQrfeUr8TWQPEv1aMiecCm3igU2q/yO2E3HNqQUd93z/UFDRwZ3kfcTMatHARHOyKR3x1lrBZ/Fj8N+uOQIvZQAKo8NgSDJljke2QpUKWF0hbSNcdV255DgtcWauKfuWZsjsSgl34Kk+b8A6GCuzIFqrZdqpVmNDWkFr7SYE59wzZeb5gWwH/qm2/ywLa01Z6C9ZyMw1llicls9wvWahH3wrDUWOR9eMFfFgcBTJ5NJdFBmQTt2wSzq9L4A9f+Xl1rpcKlxqrh85sBXBlytdwDUn47ECi8EDw4SfyuT43tOpljgwTIe14F8ySTeKkI+uz/dtKfGp3TYeXRVqa1d69c0ZLh/44Cc/Wfsw8357Oq4/uEazCRjV6h1GeLZgr6sWHTB2ffrygngKauXKqO2uok7Z1CfECbHgfl3ijn9JNyzBWGGl+DUsZ1O0yIcapkB1s04G6NttkdDtNbzqPz1n5qXy3NGlB2NXfR4B0WFnbZeNI2+A6nRcXrJb5ZyB4afQXjYDK6DOXiQXJliu5lCCA FFZf45TK m6XEJRIDkSNMzenhFwMtULG1CQ2O+oer8mbUCr1sH5W4LNI6L5pquPlcVn0lCsaesAO22MzYmlLSXYaXhm+2mSGdD/Xe3rOPv7vnazA7dqLPmB3PGcRRHvIxKHXwZQYz+fK0Krsc9yca5MyphrlFYQDOhZ4wKCltTamsHK7UDx9wokg8Gh49DylvLmtpZ6JQXo8ePH1Tj+qI0QNUpwgpJkx4fTBR/fZ89ifQ0J+/K0aFhP8GL7/1fz7RBEK+kDi8nq9S5dHMixE2YuSoz1tS3URsW7BdKZTS94AghrWKUA+Nsn4y6ZMgRTtQl7/w2Oxf7P13XwmfFPVy4dRVq1hf3p50/FHxicKWIw2LOOple75Y2K6HHDA0OKtlmt7pHDiP4ocpetY8i3JEGxjdzEXlrk7RJa3KKbSdGZf68gnd+LQ8zPoVIgzirCc9mhqQT7Z2r5PnI8NzDKaBhrXj2I/pQ9QLt6J0eFOHgX0ZD3oJgjNTCW9jNnsT5ZJXiycA5LmKea2LvB1PPw4Iz9MRaVovrMDkVZECtamZcRKnCY2KGXrpBTz/7mIBa2BDg/ovdMcfqConC2LzLeKhBkxR4QYbkeZZW+GazoTh/TCwiAZKcd6ubiBgr3YqrTVvTfMUAUsDQTtYSa7nCYuu7FM1p6OP0DuAtMg== 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: On Wed, 10 May 2023, Matthew Wilcox wrote: > On Tue, May 09, 2023 at 09:39:13PM -0700, Hugh Dickins wrote: > > Two: pte_offset_map() will need to do an rcu_read_lock(), with the > > corresponding rcu_read_unlock() in pte_unmap(). But most architectures > > never supported CONFIG_HIGHPTE, so some don't always call pte_unmap() > > after pte_offset_map(), or have used userspace pte_offset_map() where > > pte_offset_kernel() is more correct. No problem in the current tree, > > but a problem once an rcu_read_unlock() will be needed to keep balance. > > Hi Hugh, > > I shall have to spend some time looking at these patches, but at LSFMM > just a few hours ago, I proposed and nobody objected to removing > CONFIG_HIGHPTE. I don't intend to take action on that consensus > immediately, so I can certainly wait until your patches are applied, but > if this information simplifies what you're doing, feel free to act on it. Thanks a lot, Matthew: very considerate, as usual. Yes, I did see your "Whither Highmem?" (wither highmem!) proposal on the list, and it did make me think, better get these patches and preview out soon, before you get to vanish pte_unmap() altogether. HIGHMEM or not, HIGHPTE or not, I think pte_offset_map() and pte_unmap() still have an important role to play. I don't really understand why you're going down a remove-CONFIG_HIGHPTE route: I thought you were motivated by the awkardness of kmap on large folios; but I don't see how removing HIGHPTE helps with that at all (unless you have a "large page tables" effort in mind, but I doubt it). But I've no investment in CONFIG_HIGHPTE if people think now is the time to remove it: I disagree, but wouldn't miss it myself - so long as you leave pte_offset_map() and pte_unmap() (under whatever names). I don't think removing CONFIG_HIGHPTE will simplify what I'm doing. For a moment it looked like it would: the PAE case is nasty (and our data centres have not been on PAE for a long time, so it wasn't a problem I had to face before); and knowing pmd_high must be 0 for a page table looked like it would help, but now I'm not so sure of that (hmm, I'm changing my mind again as I write). Peter's pmdp_get_lockless() does rely for complete correctness on interrupts being disabled, and I suspect that I may be forced in the PAE case to do so briefly; but detest that notion. For now I'm just deferring it, hoping for a better idea before third series finalized. I mention this (and Cc Peter) in passing: don't want this arch thread to go down into that rabbit hole: we can start a fresh thread on it if you wish, but right now my priority is commit messages for the second series, rather than solving (or even detailing) the PAE problem. Hugh