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 BAEDDC433EF for ; Wed, 20 Apr 2022 14:44:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4F8AD6B0071; Wed, 20 Apr 2022 10:44:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CD846B0072; Wed, 20 Apr 2022 10:44:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 36F0A6B0074; Wed, 20 Apr 2022 10:44:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.27]) by kanga.kvack.org (Postfix) with ESMTP id 26B3B6B0071 for ; Wed, 20 Apr 2022 10:44:22 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0876F62DCB for ; Wed, 20 Apr 2022 14:44:22 +0000 (UTC) X-FDA: 79377527964.22.3519333 Received: from mail-qv1-f50.google.com (mail-qv1-f50.google.com [209.85.219.50]) by imf28.hostedemail.com (Postfix) with ESMTP id 9E010C0019 for ; Wed, 20 Apr 2022 14:44:19 +0000 (UTC) Received: by mail-qv1-f50.google.com with SMTP id i14so1438134qvk.13 for ; Wed, 20 Apr 2022 07:44:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JEzFnCq+BQP5/7i1OwdP+xfd73rvdn4Cf2EKhcjMDFo=; b=KO7k2jXgJzVLksQofpOnRkx5nlg3jMUZh3npbY14d3Ne1xPoOhhc5jm4fIbkIfI1kW 1jEl131iHwsTVgTrYQKU17MJgCpxB1zSjXqkwNVQsrhY5tm7SnCWCNy75LFL+BQcsjKA T/1efXzKR+b+PSgk6E4nldDwbHnh3MebFc6FmxuyyJDsff/GA8XaQaEp3dB4CAuGBBcT G3eAva4BHU1b218incI5UMLx3HkRfntkApZC96uHvK9O4Vg2skOcTFX2BXbNqGlbBA8s Kk0lXs0zud+FUHGFaHQ55UW0aPloAc18tuzP1/mnAnxy+vDP9A5IoA1JbfhrV9t05Oa+ sWrA== X-Gm-Message-State: AOAM533ttbou1XtXhX8DLEb8xlV5yqDVBBYZPCk0t9j7IuBYVbyEqKk+ OjD2+XcoipWHVm4YJjpNKB2BjTWeP6lnTg== X-Google-Smtp-Source: ABdhPJyoKI+RdrYhvTMci0yp6XbUy9u+ZQPnsQI6JTc5QbrFJ97S7k7lQZzsYDpVPpO+3q2ndxoGMA== X-Received: by 2002:ad4:5deb:0:b0:446:44ec:8d88 with SMTP id jn11-20020ad45deb000000b0044644ec8d88mr15350533qvb.126.1650465860535; Wed, 20 Apr 2022 07:44:20 -0700 (PDT) Received: from mail-yw1-f176.google.com (mail-yw1-f176.google.com. [209.85.128.176]) by smtp.gmail.com with ESMTPSA id f11-20020a05620a12eb00b0069c88d15b6asm1528163qkl.68.2022.04.20.07.44.19 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Apr 2022 07:44:19 -0700 (PDT) Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-2eba37104a2so20946587b3.0 for ; Wed, 20 Apr 2022 07:44:19 -0700 (PDT) X-Received: by 2002:a81:4f0d:0:b0:2ec:1556:815 with SMTP id d13-20020a814f0d000000b002ec15560815mr21306644ywb.256.1650465859173; Wed, 20 Apr 2022 07:44:19 -0700 (PDT) MIME-Version: 1.0 References: <481a13f8-d339-f726-0418-ab4258228e91@foss.st.com> <95a0d1dd-bcce-76c7-97b9-8374c9913321@google.com> <7f2993a9-adc5-2b90-9218-c4ca8239c3e@google.com> <3695dc2a-7518-dee4-a647-821c7cda4a0f@foss.st.com> <2a462b23-5b8e-bbf4-ec7d-778434a3b9d7@google.com> <6f56d0d6-6d0d-f0c9-87df-f3ff25b26fc5@linux-m68k.org> In-Reply-To: <6f56d0d6-6d0d-f0c9-87df-f3ff25b26fc5@linux-m68k.org> From: Geert Uytterhoeven Date: Wed, 20 Apr 2022 16:44:08 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Regression with v5.18-rc1 tag on STM32F7 and STM32H7 based boards To: Greg Ungerer Cc: Hugh Dickins , Patrice CHOTARD , Arnd Bergmann , Mikulas Patocka , Lukas Czerner , "Darrick J . Wong" , Christoph Hellwig , zkabelac@redhat.com, Miklos Szeredi , Borislav Petkov , Andrew Morton , Alexandre TORGUE - foss , Valentin CARON - foss , linux-stm32@st-md-mailman.stormreply.com, Linux Kernel Mailing List , Linux FS Devel , Linux MM , Linux-Arch , Linux ARM , "moderated list:H8/300 ARCHITECTURE" , linux-m68k , Yoshinori Sato , Russell King Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: xz9bn8y3wowtyfm17dskjbgh9auc1d46 X-Rspam-User: Authentication-Results: imf28.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf28.hostedemail.com: domain of geert.uytterhoeven@gmail.com designates 209.85.219.50 as permitted sender) smtp.mailfrom=geert.uytterhoeven@gmail.com X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 9E010C0019 X-HE-Tag: 1650465859-338220 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 Greg, On Wed, Apr 20, 2022 at 3:53 PM Greg Ungerer wrote: > On 16/4/22 10:58, Hugh Dickins wrote: > > Just to wrap up this thread: the tentative arch/ patches below did not > > go into 5.18-rc2, but 5.18-rc3 will contain > > 1bdec44b1eee ("tmpfs: fix regressions from wider use of ZERO_PAGE") > > which fixes a further issue, and deletes the line which gave you trouble. > > > > With arch/h8300 removed from linux-next, and arch/arm losing a page by > > the patch below, I don't think it's worth my arguing for those changes. > > I'd still prefer arch/m68k to expose its empty_zero_page in ZERO_PAGE(), > > or else not allocate it; but I won't be pursuing this further. > > Thanks for pointing this out. It certainly does look wrong to me for > the m68k nommu case. I am not aware of any existing issues caused by > this - but there is no good reason not to fix it. > > So I propose this change. Build and run tested on my m68knommu targets. > > Regards > Greg > > > From f809fb8fbca9e5e637b8fda380955bd799bb3926 Mon Sep 17 00:00:00 2001 > From: Greg Ungerer > Date: Wed, 20 Apr 2022 23:27:47 +1000 > Subject: [PATCH] m68knommu: set ZERO_PAGE() allocated zeroed page > > The non-MMU m68k pagetable ZERO_PAGE() macro is being set to the > somewhat non-sensical value of "virt_to_page(0)". The zeroth page > is not in any way guaranteed to be a page full of "0". So the result > is that ZERO_PAGE() will almost certainly contain random values. > > We already allocate a real "empty_zero_page" in the mm setup code shared > between MMU m68k and non-MMU m68k. It is just not hooked up to the > ZERO_PAGE() macro for the non-MMU m68k case. > > Fix ZERO_PAGE() to use the allocated "empty_zero_page" pointer. > > I am not aware of any specific issues caused by the old code. > > Link: https://lore.kernel.org/linux-m68k/2a462b23-5b8e-bbf4-ec7d-778434a3b9d7@google.com/T/#t > Reported-by: Hugh Dickens > Signed-off-by: Greg Ungerer > --- > arch/m68k/include/asm/pgtable_no.h | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/arch/m68k/include/asm/pgtable_no.h b/arch/m68k/include/asm/pgtable_no.h > index 87151d67d91e..bce5ca56c388 100644 > --- a/arch/m68k/include/asm/pgtable_no.h > +++ b/arch/m68k/include/asm/pgtable_no.h > @@ -42,7 +42,8 @@ extern void paging_init(void); > * ZERO_PAGE is a global shared page that is always zero: used > * for zero-mapped memory areas etc.. > */ > -#define ZERO_PAGE(vaddr) (virt_to_page(0)) > +extern void *empty_zero_page; > +#define ZERO_PAGE(vaddr) (virt_to_page(empty_zero_page)) > > /* > * All 32bit addresses are effectively valid for vmalloc... And after that (or combined with this?), this can be factored out from arch/m68k/include/asm/pgtable_{mm,no}.h into arch/m68k/include/asm/pgtable.h. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds