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 1B5A1C7EE22 for ; Thu, 11 May 2023 06:53:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9B1D26B0075; Thu, 11 May 2023 02:53:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 961D96B0078; Thu, 11 May 2023 02:53:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8344B6B007B; Thu, 11 May 2023 02:53:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 731C26B0075 for ; Thu, 11 May 2023 02:53:45 -0400 (EDT) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 1D2221C729E for ; Thu, 11 May 2023 06:53:45 +0000 (UTC) X-FDA: 80777058810.05.C55FD02 Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com [209.85.160.170]) by imf28.hostedemail.com (Postfix) with ESMTP id 36E0CC0008 for ; Thu, 11 May 2023 06:53:41 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of geert.uytterhoeven@gmail.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=geert.uytterhoeven@gmail.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683788022; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MblyuSVWD0Rw/dgsETYZNoTE8y2XjkYZe4ysDLt2Njg=; b=lU+7RAyJf5D9gkmrRWx9RiPtlivpd5eSB8HpKsdpJA0YXpmgqYmV73Tsa7+QKFzh+v7Fto C53aLkyngLs9pyLIY0Qu0BSVNdDc6y1oanhuEtD2qMIAxEUIsvKMRko8nN3kkjnAez2nSY Gka6v6cY0q6S+5VYOatgC+PCr9IGWJg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683788022; a=rsa-sha256; cv=none; b=t+RQ4ORsA62oFkCnzyPXpiWi9+f9Vje1lTGxprb/qwMHgokb9KYTFKpVEDGPDy/AbspT7c 69YTRCiE35SwDm69Gtq5s4Z4WU9SMHipIJfIPXl29u4895n96gyEX4pi0XzmnCezxDCHuE BxI0zyWSCkaFRW0yKl76fLkFuscSnsE= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of geert.uytterhoeven@gmail.com designates 209.85.160.170 as permitted sender) smtp.mailfrom=geert.uytterhoeven@gmail.com; dmarc=none Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-3ef2f81a96cso82431921cf.0 for ; Wed, 10 May 2023 23:53:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683788021; x=1686380021; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=MblyuSVWD0Rw/dgsETYZNoTE8y2XjkYZe4ysDLt2Njg=; b=XnlWr09Sk1u6nIxsWQnnxcmVbmNoulJjFGXPYyFfOZ4J2SWN++AtXGJ4761vLOaNBN hYkCx0O2n43zm3REMH6T0asoKaV+dWG0ujIS3rDe47RxcW/1OgOU+G6yjvoSECiEJIUd TB4TW9pVQ1GS+yFb0m6d9X4QYlSo3pU6S/QJQ2AGPwx9Z62VakqjmE7OthcDL3WkrEPi 5RpSDPzJTwOWv1zRWRol10fjCiNos2GCcozA68MjyCUcyYUgNObDD8k6ny4s4zLO4NB6 D9nxaUBLHMxQ8yLuysQkasfiNrWsw+OUMS8AeS9UIcir+N0dbhVd0AjBL3cvTeVFDel8 +cmA== X-Gm-Message-State: AC+VfDyXJ8rrTZw2V6GoL64yA+ydlQRiJ39WfdxTyFN56mEZZrAMOOVQ hjNy8Lmeh3ZSHWG5HMDuRlo9l4kjc1iwUA== X-Google-Smtp-Source: ACHHUZ7DnNDCRqs7o/Soh8mXsSdyQ5sBmajI5QLuXwql5K6E5Gkc4bl38fd5xbgdlrD+VwrO6S3ong== X-Received: by 2002:a05:622a:130a:b0:3e3:91da:488e with SMTP id v10-20020a05622a130a00b003e391da488emr33689274qtk.53.1683788020813; Wed, 10 May 2023 23:53:40 -0700 (PDT) Received: from mail-qt1-f170.google.com (mail-qt1-f170.google.com. [209.85.160.170]) by smtp.gmail.com with ESMTPSA id o16-20020ae9f510000000b0075772c756e0sm3050140qkg.101.2023.05.10.23.53.40 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 10 May 2023 23:53:40 -0700 (PDT) Received: by mail-qt1-f170.google.com with SMTP id d75a77b69052e-3ef588dcf7aso82338041cf.1 for ; Wed, 10 May 2023 23:53:40 -0700 (PDT) X-Received: by 2002:a25:aaa6:0:b0:b9d:a27c:3fc9 with SMTP id t35-20020a25aaa6000000b00b9da27c3fc9mr17668190ybi.33.1683787999800; Wed, 10 May 2023 23:53:19 -0700 (PDT) MIME-Version: 1.0 References: <77a5d8c-406b-7068-4f17-23b7ac53bc83@google.com> <237c8410-ce61-94c-4260-7318ad6a4f3@google.com> In-Reply-To: From: Geert Uytterhoeven Date: Thu, 11 May 2023 08:53:07 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 05/23] m68k: allow pte_offset_map[_lock]() to fail To: Hugh Dickins Cc: Andrew Morton , Mike Kravetz , Mike Rapoport , "Kirill A. Shutemov" , Matthew Wilcox , David Hildenbrand , Suren Baghdasaryan , Qi Zheng , Russell King , Catalin Marinas , Will Deacon , 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 , 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 36E0CC0008 X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: npp7ax5p8pfy4qcdu913zbp7ax9qumr9 X-HE-Tag: 1683788021-918991 X-HE-Meta: U2FsdGVkX1+Eucf4LiLa4L/Yc23oq3gn4x+FOceRiE4iiwAwKKD7XZows6W5010QaPcqQ+3fAZb//jWUqZuXvyIMagyqsc4C32r16I+1huVlFFdxCKD5tFDOGoTDtWxj/RNFwh8ch304EtPmr1SdEW8XUQnbJzuuO2hpc4rUoiIhigl9RLCnAxkohJHDkDK7WYbOKSsDcGzefzkl8eVT6YyhvRqolLNm0h0UAudCCLagUiRpc025ZL3IkkJzR2MrQ+s7ymCQ1a2auHjgf5mz2xq2msOZWZTqD13AZJTTE3YnBX2mgxo+xv/0fXIOFtSSQrN2+MHDCGOjEzJpuNMIY9SHqSZZ64qOUT1wbrhhrjvPgKi09fRyq3QSNs6RPjA20HB0yRUA5JHeQ/CqpUmmV6/tm+8MMIRD6EK0hKSFxMDi0VXOWdYiD43rmiMsW+w/M17YbcmO4xJF1UJHxt2gc9U25hLDdelXRL1co4S1yHVUqwFMdOS8RSynwxLw2ljDG/HNTQ7e5LhC58rPtm1N+QXDk4XtuTcrrleg3fFa65FpDFVO6aPfAvRpEnG/theGgtwfPwfyADPvKLp8tGlU1PHtSCjzBCHc166zfc2+C6gBQVJIFtEkO9be4AcdLPCYVfRmT1PQs6Ct23ZP89pWgp45yV4v8kxii1L76Mrx+1VzIIrhuFTv0ExdcXCClGNprmxDjCDIjRIFwp6uPMah/NFVeYKoep/vYwx+vSGklmqJPExVP/XNojLQ713oCRoi6468hPAFNRZLsWEj1IDIoSDaJfG+KkdfbbAaaW/hFWgMlVPXT1tjJZTastFp7zcmEFsoIxfP/T9c3+TbkIw5JO311PKZRpeK2ATslqyeHIbnoO44wvNHyzw7Q7Y571LyzCaVpZPLphas/BzhGp2PnRHVO9ll3QSloEniE1SydbyWFocfb6jLAPcCCwGf3sWc+XkaRBRjZdlZE59L0hi klaDhZqq AU+EXRyNiXbpl/7Wy87Qd2HvRUnFk+DskPNbEvb/33/58G+dpsgbhcyj10YZEPzYHbvGunpeRcNbAto98h2fazE0xOcDPOVrwQoNwncFdnsXeai2e0cDGfsSnLVHsRR+9TFgZ8utkoleVWkfW7DvyVzXzplSTQT+FeY5zmmgsR3cwXFlxX8QJ6GF03zoSh/ZQVoZJ7HknKlL5eQ/yg+8ZqrYoRdL8yq7GL/GpCOIlWQMP0JUMEDJ8ye2JCTWouT7elAiQubDLnJUTxy8eC0Benm/0MsQTZvK9ewEukuaerT23N9ZjWpS/6nWnPoWZhRB1uf+Rbu0goKah62An1l3WIJcVhQ8Ub3T3BgnZDIUaQ+9YBLdiHWIZT06DsADGJ3WzCRQXe+yKJO/3B535zN+JKsfbiGR8lVvtd6WbPQg7OCyPRu6hMU/Zn4KMgMZBTtrZXzbXE7gz4LyjEjEcYgwkkG2ymDyofO2jRexPY5FWhtV0xtxAUjDIVvvGgUJAujTZSiME4hM/P88ncdKz65hIf8N+5A== 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: Hi Hugh, On Thu, May 11, 2023 at 4:58=E2=80=AFAM Hugh Dickins wro= te: > On Wed, 10 May 2023, Geert Uytterhoeven wrote: > > On Wed, May 10, 2023 at 6:48=E2=80=AFAM Hugh Dickins = wrote: > > > In rare transient cases, not yet made possible, pte_offset_map() and > > > pte_offset_map_lock() may not find a page table: handle appropriately= . > > > > > > Restructure cf_tlb_miss() with a pte_unmap() (previously omitted) > > > at label out, followed by one local_irq_restore() for all. > > > > That's a bug fix, which should be a separate patch? > > No, that's not a bug fix for the current tree, since m68k does not > offer CONFIG_HIGHPTE, so pte_unmap() is never anything but a no-op > for m68k (see include/linux/pgtable.h). > > But I want to change pte_unmap() to do something even without > CONFIG_HIGHPTE, so have to fix up any such previously harmless > omissions in this series first. OK. > > > --- a/arch/m68k/include/asm/mmu_context.h > > > +++ b/arch/m68k/include/asm/mmu_context.h > > > @@ -99,7 +99,7 @@ static inline void load_ksp_mmu(struct task_struct = *task) > > > p4d_t *p4d; > > > pud_t *pud; > > > pmd_t *pmd; > > > - pte_t *pte; > > > + pte_t *pte =3D NULL; > > > unsigned long mmuar; > > > > > > local_irq_save(flags); > > > @@ -139,7 +139,7 @@ static inline void load_ksp_mmu(struct task_struc= t *task) > > > > > > pte =3D (mmuar >=3D PAGE_OFFSET) ? pte_offset_kernel(pmd, mmu= ar) > > > : pte_offset_map(pmd, mmuar); > > > - if (pte_none(*pte) || !pte_present(*pte)) > > > + if (!pte || pte_none(*pte) || !pte_present(*pte)) > > > goto bug; > > > > If the absence of a pte is to become a non-abnormal case, it should > > probably jump to "end" instead, to avoid spamming the kernel log. > > I don't think so (but of course it's hard for you to tell, without > seeing all completed series of series). If pmd_none(*pmd) can safely > goto bug just above, and pte_none(*pte) goto bug here, well, the !pte > case is going to be stranger than either of those. > > My understanding of this function, load_ksp_mmu(), is that it's dealing > at context switch with a part of userspace which very much needs to be > present: whatever keeps that from being swapped out or migrated at > present, will be sure to keep the !pte case away - we cannot steal its > page table just at random (and a THP on m68k would be surprising too). > > Though there is one case I can think of which will cause !pte here, > and so goto bug: if the pmd entry has got corrupted, and counts as > pmd_bad(), which will be tested (and cleared) in pte_offset_map(). > But it is okay to report a bug in that case. > > I can certainly change this to goto end instead if you still prefer, > no problem; but I'd rather keep it as is, if only for me to be proved > wrong by you actually seeing spam there. OK, makes sense. > > > @@ -161,6 +161,8 @@ static inline void load_ksp_mmu(struct task_struc= t *task) > > > bug: > > > pr_info("ksp load failed: mm=3D0x%p ksp=3D0x08%lx\n", mm, mmu= ar); > > > end: > > > + if (pte && mmuar < PAGE_OFFSET) > > > + pte_unmap(pte); > > > > Is this also a bugfix, not mentioned in the patch description? > > I'm not sure whether you're referring to the pte_unmap() which we > already discussed above, or you're seeing something else in addition; > but I don't think there's a bugfix here, just a rearrangement because > we now want lots of cases to do the pte_unmap() and local_irq_restore(). I was referring to the addition of pte_unmap(). As per your explanation above, this is not a bugfix. Gr{oetje,eeting}s, Geert --=20 Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k= .org In personal conversations with technical people, I call myself a hacker. Bu= t when I'm talking to journalists I just say "programmer" or something like t= hat. -- Linus Torvalds