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 3FE25C636CC for ; Tue, 31 Jan 2023 18:55:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9E6626B0074; Tue, 31 Jan 2023 13:55:23 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 96F716B0075; Tue, 31 Jan 2023 13:55:23 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8105E6B0078; Tue, 31 Jan 2023 13:55:23 -0500 (EST) 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 726F36B0074 for ; Tue, 31 Jan 2023 13:55:23 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 4278D140C59 for ; Tue, 31 Jan 2023 18:55:23 +0000 (UTC) X-FDA: 80415997326.18.B5E131C Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf07.hostedemail.com (Postfix) with ESMTP id 52C854001F for ; Tue, 31 Jan 2023 18:55:21 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=p4r9YCVi; spf=pass (imf07.hostedemail.com: domain of conor@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=conor@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1675191321; 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=I8JevipPL/vr6kdKG7LW1YAfbfko2YgW1tUgA+dbKSQ=; b=6hwk8SxQGy5uDj1R4ZGIkIDuhblJYF77A1B/Y3qE5zjJoSnlxl20F8B8TmP2SQnzqgnCN7 HhNAkLrwL2qksojxJDQu38AkumEowYw3sVfSQtwWJwa7Isu2sdUoQqVUA66oIrSdlwFrht 7eMFDk1JrbmHLTQo9eQNPCkdpt4yDhM= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=p4r9YCVi; spf=pass (imf07.hostedemail.com: domain of conor@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=conor@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1675191321; a=rsa-sha256; cv=none; b=1/UrA0hZvaIeWF38JsIS6YHoJcP1DWMFQeEEdZoV6BbFHFC9hH9xhea14mawDzP4Q9+B6h Oy1M2ey+Qi+z2y5ysW22C2Tvo8EOudLYMp5JtuW87MG9Tz85fR8GOCKFlhv/HOnDzOySnF Rkggw3pqMIzCyg/2SVQLTerThsb7RH4= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B440CB81E69; Tue, 31 Jan 2023 18:55:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 249B8C433EF; Tue, 31 Jan 2023 18:55:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675191318; bh=bIDjyyvdysd52cz3wo+R2FqIpQuhXwaSP+2JinM77Zs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=p4r9YCVihzZrIRlizFq96lF4LsuRcYuXyit+cVXFPxJSxGfL99cms2/SSKpvkF2Pp NgIawOhOvw555KfS+LAiMfG5/YT2a/THCQd4ucSFldwug8pgOxrs80vH+lCVDLHIZh fh6CSOEpoCrswZLqAXRWz9pZ9CFIa58ZjTeMXFlgy8V6KmgUqFk322AZ/O2du+jfxI cQP8VEptS2HT9jSp8zZqLDDlrzS+XSn+HUeeyHjnm0LO863o/QOiqT647VANwYetka 9TpahVOYB0s8YL82xibnQ7Ggye7lO/va5K0QbIxfYIjwKYESn8Y2//JUV74+mpgZ7e krHdpZB95Rbtg== Date: Tue, 31 Jan 2023 18:55:07 +0000 From: Conor Dooley To: Mike Rapoport Cc: Andrew Morton , Arnd Bergmann , Brian Cain , "David S. Miller" , Dinh Nguyen , Geert Uytterhoeven , Greg Ungerer , Guo Ren , Helge Deller , Huacai Chen , Matt Turner , Max Filippov , Michael Ellerman , Michal Simek , Palmer Dabbelt , Rich Felker , Richard Weinberger , Russell King , Stafford Horne , Thomas Bogendoerfer , Vineet Gupta , WANG Xuerui , Yoshinori Sato , linux-alpha@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-csky@vger.kernel.org, linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-parisc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-sh@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-um@lists.infradead.org, linux-xtensa@linux-xtensa.org, linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev, openrisc@lists.librecores.org, sparclinux@vger.kernel.org, x86@kernel.org, Huacai Chen Subject: Re: [PATCH v2 4/4] mm, arch: add generic implementation of pfn_valid() for FLATMEM Message-ID: References: <20230129124235.209895-1-rppt@kernel.org> <20230129124235.209895-5-rppt@kernel.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hiaCFsst32mLBZni" Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: bbch5hw58t3epcusewa6s9zjendoek6y X-Rspamd-Queue-Id: 52C854001F X-HE-Tag: 1675191321-97183 X-HE-Meta: U2FsdGVkX19cX6AdXTrJMtB0Rt2flhA1+/k2ppgoZCdw/eRgV6+f6F1l0hrQzOG0BB5KNYheotOA0cZ719drf4fM78m/Q2Fu1qsV6Vj0vQ+auPcvNgOypdsI/B7nKcnZsbd7XCUgdyLzbkGlJWEfMk7AP+6SjqcUmrd4OGNLJwEGrE3vFzRFu1UIsEVKPLHn+6CBYdPMC+LyibOFN19Khoabs7HiwNKrpTjh2Ksn430n0Hxuoew5FTy7OUXqcdZvHZMWQ6w5LlSXvN987mgvLAZC4PzKkwJu+pGvxkVohsX9PNYPRTDLLU4WljDYsOn4qDCF8FWlLE7NR4G9hxv/2NcbWzeNFJKAsuLdfYg4mn/zFS280hx6eaYwzVWLXVlnt7UngFbucKBpNJi9z9fqyAWbySh4/sORIoqCVChTCpQXj8evr42N64LEsnwRwhH5n8wqWAzp7jpMOj+Wl/BtNFFBqfglQSN/kEuQsQert6u5CNwJr0MZEWH3DkNIxyb7eNNYdVMKHXYR1ak/WSFECLcJJvBRk58WYm1McwDtKfmPpLkrbiShnEuOO280UkAZZuCQaRar1aHRlZrxBI1wMP5H4GH4mLPe3x+fxLm4RQijRn609ry3LZO3xEkVUFhdk9bL2uFD2yBBj0tO13tuVxO2AG3RHHCxHhGvaFdlosR3sGLTEQFtNeIbH0vi9jACGcj082+Pl1vaXSqNrZ1KQkpshGYr094DNmliXFhOulq0qufHjHRYiV1FwnKijf0cT8SMktGaMTCgzJmF5WIuNUO1sn8mQ7suBV4w2+BnKULanImNPEGEmCttSqeetlihXqilZDwrJNZvjOLwIqzA1SntI2ULhMrNUSqoFAT3ocSOiucpSIQiS/YCJq1TzHRrkONc3oy/gBLwREHZp2R8ktaPL4hoRmKOoL0lCXwpVv8UChiD4SSv8/wOJRGZQuWjVUJFQU4hOShvE1umUTX ZzQJ4f9g 2jFNovID3FsnCC8E9ClKoAt0rkL1qyH55iC2x4Qd1noiov0LYJAQkUTjvkvK2D4G53kTqCnJTLYtbViGmZq3bQwiQr97J4lrTaZtuaN0OntWlc7YoXUEpaERB5prbI4MwpBEb2tn1LseDknZC9mXC/auyCqXBrDrcLaeVp1fPQMvXr7XiyPhJRclLfBiQVQGXbBBCbAMMqNRN2kx3wS8XBJ+hCSdvxfxD5bZ8SEQC9bL+0qgn3fxlidrr6Z8TEhzoHhmYBDKD1Mh/5NFUA2jfFCZo3YBNwE3UHtWCMnbWjxMsTN4cfBbV2TIGFSjh32NaRuaNRDtrmv42L5eZ4OOGFYxW+CjOrZbVBh4ZNjHcwaTMPAkP/OduqxgeFsCDDY27yGUa6si6hCQ1mQzvDEfGWSApiPS7hNnemDwnFqbH5f3A0ZUp+YNewRhO2BAQE3gprYL2js34X5RPpOLF9lVf47Ln3wggHvn5CiKxh4kSn3IoPCz+GVfsjW5O7AuoNa9dYMXhO9bEWGE0iFq33LaiZU+f8gXodss9n7v/0FrMzscikjEQ6s+bSO5n2bRtv83b3QNPzB+1LcmckaeDsBUMErBhMbZPy9P7E3Luo00WIZ/ANsmZSUjkWsSnUOwBak5xHiGx 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: --hiaCFsst32mLBZni Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Mike, On Tue, Jan 31, 2023 at 08:41:49PM +0200, Mike Rapoport wrote: > On Tue, Jan 31, 2023 at 05:47:24PM +0000, Conor Dooley wrote: > > On Sun, Jan 29, 2023 at 02:42:35PM +0200, Mike Rapoport wrote: > > > From: "Mike Rapoport (IBM)" > > >=20 > > > Every architecture that supports FLATMEM memory model defines its own > > > version of pfn_valid() that essentially compares a pfn to max_mapnr. > > >=20 > > > Use mips/powerpc version implemented as static inline as a generic > > > implementation of pfn_valid() and drop its per-architecture definitio= ns. > > >=20 > > > Signed-off-by: Mike Rapoport (IBM) > > > Acked-by: Arnd Bergmann > > > Acked-by: Guo Ren # csky > > > Acked-by: Huacai Chen # LoongArch > > > Acked-by: Stafford Horne # OpenRISC > >=20 > > Hmm, so this landed in linux-next today and I bisected a boot failure in > > my CI to it. However, I am not really sure if it is a real issue worth > > worrying about as the platform it triggered on is supposed to be using > > SPARSEMEM, but isn't. > > I had thought that my CI was using a config with SPARSEMEM since that > > became required for riscv defconfig builds to boot in v6.1-rc1, but I > > must have just forgotten to add it to my $platform_defconfig builds too. > > However, those $platform_defconfig builds continued booting without > > SPARSEMEM enabled until today. >=20 > The issue seems to be that the generic pfn_valid() does not take into > account pfn_offset when it compares it with max_mapnr. > Can you please test with the patch below? >=20 > diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/mem= ory_model.h > index 13d2a844d928..6796abe1900e 100644 > --- a/include/asm-generic/memory_model.h > +++ b/include/asm-generic/memory_model.h > @@ -26,7 +26,7 @@ static inline int pfn_valid(unsigned long pfn) > extern unsigned long max_mapnr; > unsigned long pfn_offset =3D ARCH_PFN_OFFSET; > =20 > - return pfn >=3D pfn_offset && pfn < max_mapnr; > + return pfn >=3D pfn_offset && (pfn - pfn_offset) < max_mapnr; > } > #define pfn_valid pfn_valid > #endif Gave that a go, board is booting properly again! Feel free to add a: Tested-by: Conor Dooley Thanks for the prompt fix! --hiaCFsst32mLBZni Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCY9lkCwAKCRB4tDGHoIJi 0pIDAP9nc8RsXGyfp84b29PfLE6bd1djEIZ71+YYWPrhRbOT0QEAs5hvd2Aq0mES TzWIEs2xL7+wjwVIWLwPjr1kP0shHA0= =AQg2 -----END PGP SIGNATURE----- --hiaCFsst32mLBZni--