From: Conor Dooley <conor@kernel.org>
To: Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>, Brian Cain <bcain@quicinc.com>,
"David S. Miller" <davem@davemloft.net>,
Dinh Nguyen <dinguyen@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Greg Ungerer <gerg@linux-m68k.org>, Guo Ren <guoren@kernel.org>,
Helge Deller <deller@gmx.de>, Huacai Chen <chenhuacai@kernel.org>,
Matt Turner <mattst88@gmail.com>,
Max Filippov <jcmvbkbc@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Michal Simek <monstr@monstr.eu>,
Palmer Dabbelt <palmer@dabbelt.com>,
Rich Felker <dalias@libc.org>,
Richard Weinberger <richard@nod.at>,
Russell King <linux@armlinux.org.uk>,
Stafford Horne <shorne@gmail.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Vineet Gupta <vgupta@kernel>
Subject: Re: [PATCH v2 4/4] mm, arch: add generic implementation of pfn_valid() for FLATMEM
Date: Tue, 31 Jan 2023 18:55:07 +0000 [thread overview]
Message-ID: <Y9lkCz73v7/iyyLj@spud> (raw)
In-Reply-To: <Y9lg7R1Yd931C+y5@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2365 bytes --]
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)" <rppt@kernel.org>
> > >
> > > Every architecture that supports FLATMEM memory model defines its own
> > > version of pfn_valid() that essentially compares a pfn to max_mapnr.
> > >
> > > Use mips/powerpc version implemented as static inline as a generic
> > > implementation of pfn_valid() and drop its per-architecture definitions.
> > >
> > > Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
> > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > > Acked-by: Guo Ren <guoren@kernel.org> # csky
> > > Acked-by: Huacai Chen <chenhuacai@loongson.cn> # LoongArch
> > > Acked-by: Stafford Horne <shorne@gmail.com> # OpenRISC
> >
> > 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.
>
> 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?
>
> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_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 = ARCH_PFN_OFFSET;
>
> - return pfn >= pfn_offset && pfn < max_mapnr;
> + return pfn >= 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 <conor.dooley@microchip.com>
Thanks for the prompt fix!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>, Brian Cain <bcain@quicinc.com>,
"David S. Miller" <davem@davemloft.net>,
Dinh Nguyen <dinguyen@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Greg Ungerer <gerg@linux-m68k.org>, Guo Ren <guoren@kernel.org>,
Helge Deller <deller@gmx.de>, Huacai Chen <chenhuacai@kernel.org>,
Matt Turner <mattst88@gmail.com>,
Max Filippov <jcmvbkbc@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Michal Simek <monstr@monstr.eu>,
Palmer Dabbelt <palmer@dabbelt.com>,
Rich Felker <dalias@libc.org>,
Richard Weinberger <richard@nod.at>,
Russell King <linux@armlinux.org.uk>,
Stafford Horne <shorne@gmail.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Vineet Gupta <vgupta@kernel.org>, WANG Xuerui <kernel@xen0n.name>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
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 <chenhuacai@loongson.cn>
Subject: Re: [PATCH v2 4/4] mm, arch: add generic implementation of pfn_valid() for FLATMEM
Date: Tue, 31 Jan 2023 18:55:07 +0000 [thread overview]
Message-ID: <Y9lkCz73v7/iyyLj@spud> (raw)
In-Reply-To: <Y9lg7R1Yd931C+y5@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2365 bytes --]
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)" <rppt@kernel.org>
> > >
> > > Every architecture that supports FLATMEM memory model defines its own
> > > version of pfn_valid() that essentially compares a pfn to max_mapnr.
> > >
> > > Use mips/powerpc version implemented as static inline as a generic
> > > implementation of pfn_valid() and drop its per-architecture definitions.
> > >
> > > Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
> > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > > Acked-by: Guo Ren <guoren@kernel.org> # csky
> > > Acked-by: Huacai Chen <chenhuacai@loongson.cn> # LoongArch
> > > Acked-by: Stafford Horne <shorne@gmail.com> # OpenRISC
> >
> > 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.
>
> 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?
>
> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_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 = ARCH_PFN_OFFSET;
>
> - return pfn >= pfn_offset && pfn < max_mapnr;
> + return pfn >= 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 <conor.dooley@microchip.com>
Thanks for the prompt fix!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>, Brian Cain <bcain@quicinc.com>,
"David S. Miller" <davem@davemloft.net>,
Dinh Nguyen <dinguyen@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Greg Ungerer <gerg@linux-m68k.org>, Guo Ren <guoren@kernel.org>,
Helge Deller <deller@gmx.de>, Huacai Chen <chenhuacai@kernel.org>,
Matt Turner <mattst88@gmail.com>,
Max Filippov <jcmvbkbc@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Michal Simek <monstr@monstr.eu>,
Palmer Dabbelt <palmer@dabbelt.com>,
Rich Felker <dalias@libc.org>,
Richard Weinberger <richard@nod.at>,
Russell King <linux@armlinux.org.uk>,
Stafford Horne <shorne@gmail.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Vineet Gupta <vgupta@kernel.org>, WANG Xuerui <kernel@xen0n.name>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
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 <chenhuacai@loongson.cn>
Subject: Re: [PATCH v2 4/4] mm, arch: add generic implementation of pfn_valid() for FLATMEM
Date: Tue, 31 Jan 2023 18:55:07 +0000 [thread overview]
Message-ID: <Y9lkCz73v7/iyyLj@spud> (raw)
In-Reply-To: <Y9lg7R1Yd931C+y5@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 2365 bytes --]
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)" <rppt@kernel.org>
> > >
> > > Every architecture that supports FLATMEM memory model defines its own
> > > version of pfn_valid() that essentially compares a pfn to max_mapnr.
> > >
> > > Use mips/powerpc version implemented as static inline as a generic
> > > implementation of pfn_valid() and drop its per-architecture definitions.
> > >
> > > Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
> > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > > Acked-by: Guo Ren <guoren@kernel.org> # csky
> > > Acked-by: Huacai Chen <chenhuacai@loongson.cn> # LoongArch
> > > Acked-by: Stafford Horne <shorne@gmail.com> # OpenRISC
> >
> > 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.
>
> 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?
>
> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_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 = ARCH_PFN_OFFSET;
>
> - return pfn >= pfn_offset && pfn < max_mapnr;
> + return pfn >= 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 <conor.dooley@microchip.com>
Thanks for the prompt fix!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>, Brian Cain <bcain@quicinc.com>,
"David S. Miller" <davem@davemloft.net>,
Dinh Nguyen <dinguyen@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Greg Ungerer <gerg@linux-m68k.org>, Guo Ren <guoren@kernel.org>,
Helge Deller <deller@gmx.de>, Huacai Chen <chenhuacai@kernel.org>,
Matt Turner <mattst88@gmail.com>,
Max Filippov <jcmvbkbc@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Michal Simek <monstr@monstr.eu>,
Palmer Dabbelt <palmer@dabbelt.com>,
Rich Felker <dalias@libc.org>,
Richard Weinberger <richard@nod.at>,
Russell King <linux@armlinux.org.uk>,
Stafford Horne <shorne@gmail.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Vineet Gupta <vgupta@kernel.org>, WANG Xuerui <kernel@xen0n.name>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
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 <chenhuacai@loongson.cn>
Subject: Re: [PATCH v2 4/4] mm, arch: add generic implementation of pfn_valid() for FLATMEM
Date: Tue, 31 Jan 2023 18:55:07 +0000 [thread overview]
Message-ID: <Y9lkCz73v7/iyyLj@spud> (raw)
In-Reply-To: <Y9lg7R1Yd931C+y5@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 2365 bytes --]
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)" <rppt@kernel.org>
> > >
> > > Every architecture that supports FLATMEM memory model defines its own
> > > version of pfn_valid() that essentially compares a pfn to max_mapnr.
> > >
> > > Use mips/powerpc version implemented as static inline as a generic
> > > implementation of pfn_valid() and drop its per-architecture definitions.
> > >
> > > Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
> > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > > Acked-by: Guo Ren <guoren@kernel.org> # csky
> > > Acked-by: Huacai Chen <chenhuacai@loongson.cn> # LoongArch
> > > Acked-by: Stafford Horne <shorne@gmail.com> # OpenRISC
> >
> > 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.
>
> 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?
>
> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_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 = ARCH_PFN_OFFSET;
>
> - return pfn >= pfn_offset && pfn < max_mapnr;
> + return pfn >= 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 <conor.dooley@microchip.com>
Thanks for the prompt fix!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 170 bytes --]
_______________________________________________
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>, Brian Cain <bcain@quicinc.com>,
"David S. Miller" <davem@davemloft.net>,
Dinh Nguyen <dinguyen@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Greg Ungerer <gerg@linux-m68k.org>, Guo Ren <guoren@kernel.org>,
Helge Deller <deller@gmx.de>, Huacai Chen <chenhuacai@kernel.org>,
Matt Turner <mattst88@gmail.com>,
Max Filippov <jcmvbkbc@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Michal Simek <monstr@monstr.eu>,
Palmer Dabbelt <palmer@dabbelt.com>,
Rich Felker <dalias@libc.org>,
Richard Weinberger <richard@nod.at>,
Russell King <linux@armlinux.org.uk>,
Stafford Horne <shorne@gmail.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Vineet Gupta <vgupta@kernel.org>, WANG Xuerui <kernel@xen0n.name>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
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 <chenhuacai@loongson.cn>
Subject: Re: [PATCH v2 4/4] mm, arch: add generic implementation of pfn_valid() for FLATMEM
Date: Tue, 31 Jan 2023 18:55:07 +0000 [thread overview]
Message-ID: <Y9lkCz73v7/iyyLj@spud> (raw)
In-Reply-To: <Y9lg7R1Yd931C+y5@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 2365 bytes --]
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)" <rppt@kernel.org>
> > >
> > > Every architecture that supports FLATMEM memory model defines its own
> > > version of pfn_valid() that essentially compares a pfn to max_mapnr.
> > >
> > > Use mips/powerpc version implemented as static inline as a generic
> > > implementation of pfn_valid() and drop its per-architecture definitions.
> > >
> > > Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
> > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > > Acked-by: Guo Ren <guoren@kernel.org> # csky
> > > Acked-by: Huacai Chen <chenhuacai@loongson.cn> # LoongArch
> > > Acked-by: Stafford Horne <shorne@gmail.com> # OpenRISC
> >
> > 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.
>
> 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?
>
> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_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 = ARCH_PFN_OFFSET;
>
> - return pfn >= pfn_offset && pfn < max_mapnr;
> + return pfn >= 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 <conor.dooley@microchip.com>
Thanks for the prompt fix!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 152 bytes --]
_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Mike Rapoport <rppt@kernel.org>
Cc: Rich Felker <dalias@libc.org>,
linux-ia64@vger.kernel.org, linux-sh@vger.kernel.org,
x86@kernel.org, linux-mips@vger.kernel.org,
Max Filippov <jcmvbkbc@gmail.com>, Guo Ren <guoren@kernel.org>,
sparclinux@vger.kernel.org, linux-hexagon@vger.kernel.org,
WANG Xuerui <kernel@xen0n.name>,
Greg Ungerer <gerg@linux-m68k.org>,
linux-arch@vger.kernel.org,
Yoshinori Sato <ysato@users.sourceforge.jp>,
Helge Deller <deller@gmx.de>, Huacai Chen <chenhuacai@kernel.org>,
Russell King <linux@armlinux.org.uk>,
linux-csky@vger.kernel.org,
Geert Uytterhoeven <geert@linux-m68k.org>,
Vineet Gupta <vgupta@kernel.org>,
Matt Turner <mattst88@gmail.com>,
linux-snps-arc@lists.infradead.org,
linux-xtensa@linux-xtensa.org, Arnd Bergmann <arnd@arndb.de>,
linux-alpha@vger.kernel.org, linux-um@lists.infradead.org,
linux-m68k@lists.linux-m68k.org, openrisc@lists.librecores.org,
loongarch@lists.linux.dev, Stafford Horne <shorne@gmail.com>,
linux-arm-kernel@lists.infradead.org,
Brian Cain <bcain@quicinc.com>, Mic hal Simek <monstr@monstr.eu>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
linux-parisc@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Dinh Nguyen <dinguyen@kernel.org>,
linux-riscv@lists.infradead.org,
Palmer Dabbelt <palmer@dabbelt.com>,
Richard Weinberger <richard@nod.at>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>,
Huacai Chen <chenhuacai@loongson.cn>
Subject: Re: [PATCH v2 4/4] mm, arch: add generic implementation of pfn_valid() for FLATMEM
Date: Tue, 31 Jan 2023 18:55:07 +0000 [thread overview]
Message-ID: <Y9lkCz73v7/iyyLj@spud> (raw)
In-Reply-To: <Y9lg7R1Yd931C+y5@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2365 bytes --]
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)" <rppt@kernel.org>
> > >
> > > Every architecture that supports FLATMEM memory model defines its own
> > > version of pfn_valid() that essentially compares a pfn to max_mapnr.
> > >
> > > Use mips/powerpc version implemented as static inline as a generic
> > > implementation of pfn_valid() and drop its per-architecture definitions.
> > >
> > > Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
> > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > > Acked-by: Guo Ren <guoren@kernel.org> # csky
> > > Acked-by: Huacai Chen <chenhuacai@loongson.cn> # LoongArch
> > > Acked-by: Stafford Horne <shorne@gmail.com> # OpenRISC
> >
> > 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.
>
> 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?
>
> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_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 = ARCH_PFN_OFFSET;
>
> - return pfn >= pfn_offset && pfn < max_mapnr;
> + return pfn >= 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 <conor.dooley@microchip.com>
Thanks for the prompt fix!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Arnd Bergmann <arnd@arndb.de>, Brian Cain <bcain@quicinc.com>,
"David S. Miller" <davem@davemloft.net>,
Dinh Nguyen <dinguyen@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Greg Ungerer <gerg@linux-m68k.org>, Guo Ren <guoren@kernel.org>,
Helge Deller <deller@gmx.de>, Huacai Chen <chenhuacai@kernel.org>,
Matt Turner <mattst88@gmail.com>,
Max Filippov <jcmvbkbc@gmail.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Michal Simek <monstr@monstr.eu>,
Palmer Dabbelt <palmer@dabbelt.com>,
Rich Felker <dalias@libc.org>,
Richard Weinberger <richard@nod.at>,
Russell King <linux@armlinux.org.uk>,
Stafford Horne <shorne@gmail.com>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Vineet Gupta <vgupta@kernel.org>, WANG Xuerui <kernel@xen0n.name>,
Yoshinori Sato <ysato@users.sourceforge.jp>,
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 <chenhuacai@loongson.cn>
Subject: Re: [PATCH v2 4/4] mm, arch: add generic implementation of pfn_valid() for FLATMEM
Date: Tue, 31 Jan 2023 18:55:07 +0000 [thread overview]
Message-ID: <Y9lkCz73v7/iyyLj@spud> (raw)
In-Reply-To: <Y9lg7R1Yd931C+y5@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 2365 bytes --]
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)" <rppt@kernel.org>
> > >
> > > Every architecture that supports FLATMEM memory model defines its own
> > > version of pfn_valid() that essentially compares a pfn to max_mapnr.
> > >
> > > Use mips/powerpc version implemented as static inline as a generic
> > > implementation of pfn_valid() and drop its per-architecture definitions.
> > >
> > > Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
> > > Acked-by: Arnd Bergmann <arnd@arndb.de>
> > > Acked-by: Guo Ren <guoren@kernel.org> # csky
> > > Acked-by: Huacai Chen <chenhuacai@loongson.cn> # LoongArch
> > > Acked-by: Stafford Horne <shorne@gmail.com> # OpenRISC
> >
> > 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.
>
> 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?
>
> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_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 = ARCH_PFN_OFFSET;
>
> - return pfn >= pfn_offset && pfn < max_mapnr;
> + return pfn >= 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 <conor.dooley@microchip.com>
Thanks for the prompt fix!
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-01-31 18:55 UTC|newest]
Thread overview: 179+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-29 12:42 [PATCH v2 0/4] mm, arch: add generic implementation of pfn_valid() for FLATMEM Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` [PATCH v2 1/4] arm: include asm-generic/memory_model.h from page.h rather than memory.h Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-02-03 14:30 ` David Hildenbrand
2023-02-03 14:30 ` David Hildenbrand
2023-02-03 14:30 ` David Hildenbrand
2023-02-03 14:30 ` David Hildenbrand
2023-02-03 14:30 ` David Hildenbrand
2023-02-03 14:30 ` David Hildenbrand
2023-02-03 14:30 ` David Hildenbrand
2023-02-03 14:30 ` David Hildenbrand
2023-01-29 12:42 ` [PATCH v2 2/4] m68k: use asm-generic/memory_model.h for both MMU and !MMU Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-02-03 14:31 ` David Hildenbrand
2023-02-03 14:31 ` David Hildenbrand
2023-02-03 14:31 ` David Hildenbrand
2023-02-03 14:31 ` David Hildenbrand
2023-02-03 14:31 ` David Hildenbrand
2023-02-03 14:31 ` David Hildenbrand
2023-02-03 14:31 ` David Hildenbrand
2023-02-03 14:31 ` David Hildenbrand
2023-02-12 17:35 ` Guenter Roeck
2023-02-12 17:35 ` Guenter Roeck
2023-02-12 17:35 ` Guenter Roeck
2023-02-12 17:35 ` Guenter Roeck
2023-02-12 17:35 ` Guenter Roeck
2023-02-12 17:35 ` Guenter Roeck
2023-02-12 17:35 ` Guenter Roeck
2023-02-12 17:35 ` Guenter Roeck
2023-02-13 1:15 ` Mike Rapoport
2023-02-13 1:15 ` Mike Rapoport
2023-02-13 1:15 ` Mike Rapoport
2023-02-13 1:15 ` Mike Rapoport
2023-02-13 1:15 ` Mike Rapoport
2023-02-13 1:15 ` Mike Rapoport
2023-02-13 1:15 ` Mike Rapoport
2023-02-13 1:15 ` Mike Rapoport
2023-02-13 6:25 ` Guenter Roeck
2023-02-13 6:25 ` Guenter Roeck
2023-02-13 6:25 ` Guenter Roeck
2023-02-13 6:25 ` Guenter Roeck
2023-02-13 6:25 ` Guenter Roeck
2023-02-13 6:25 ` Guenter Roeck
2023-02-13 6:25 ` Guenter Roeck
2023-02-13 6:25 ` Guenter Roeck
2023-01-29 12:42 ` [PATCH v2 3/4] mips: drop definition of pfn_valid() for DISCONTIGMEM Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-02-03 14:31 ` David Hildenbrand
2023-02-03 14:31 ` David Hildenbrand
2023-02-03 14:31 ` David Hildenbrand
2023-02-03 14:31 ` David Hildenbrand
2023-02-03 14:31 ` David Hildenbrand
2023-02-03 14:31 ` David Hildenbrand
2023-02-03 14:31 ` David Hildenbrand
2023-02-03 14:31 ` David Hildenbrand
2023-01-29 12:42 ` [PATCH v2 4/4] mm, arch: add generic implementation of pfn_valid() for FLATMEM Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-29 12:42 ` Mike Rapoport
2023-01-30 5:06 ` Michael Ellerman
2023-01-30 5:06 ` Michael Ellerman
2023-01-30 5:06 ` Michael Ellerman
2023-01-30 5:06 ` Michael Ellerman
2023-01-30 5:06 ` Michael Ellerman
2023-01-30 5:06 ` Michael Ellerman
2023-01-30 5:06 ` Michael Ellerman
2023-01-30 5:06 ` Michael Ellerman
2023-01-31 17:47 ` Conor Dooley
2023-01-31 17:47 ` Conor Dooley
2023-01-31 17:47 ` Conor Dooley
2023-01-31 17:47 ` Conor Dooley
2023-01-31 17:47 ` Conor Dooley
2023-01-31 17:47 ` Conor Dooley
2023-01-31 17:47 ` Conor Dooley
2023-01-31 18:41 ` Mike Rapoport
2023-01-31 18:41 ` Mike Rapoport
2023-01-31 18:41 ` Mike Rapoport
2023-01-31 18:41 ` Mike Rapoport
2023-01-31 18:41 ` Mike Rapoport
2023-01-31 18:41 ` Mike Rapoport
2023-01-31 18:41 ` Mike Rapoport
2023-01-31 18:41 ` Mike Rapoport
2023-01-31 18:55 ` Conor Dooley [this message]
2023-01-31 18:55 ` Conor Dooley
2023-01-31 18:55 ` Conor Dooley
2023-01-31 18:55 ` Conor Dooley
2023-01-31 18:55 ` Conor Dooley
2023-01-31 18:55 ` Conor Dooley
2023-01-31 18:55 ` Conor Dooley
2023-02-03 14:33 ` David Hildenbrand
2023-02-03 14:33 ` David Hildenbrand
2023-02-03 14:33 ` David Hildenbrand
2023-02-03 14:33 ` David Hildenbrand
2023-02-03 14:33 ` David Hildenbrand
2023-02-03 14:33 ` David Hildenbrand
2023-02-03 14:33 ` David Hildenbrand
2023-02-03 14:33 ` David Hildenbrand
2023-02-12 16:13 ` Guenter Roeck
2023-02-12 16:13 ` Guenter Roeck
2023-02-12 16:13 ` Guenter Roeck
2023-02-12 16:13 ` Guenter Roeck
2023-02-12 16:13 ` Guenter Roeck
2023-02-12 16:13 ` Guenter Roeck
2023-02-12 16:13 ` Guenter Roeck
2023-02-12 16:13 ` Guenter Roeck
2023-02-12 16:26 ` Mike Rapoport
2023-02-12 16:26 ` Mike Rapoport
2023-02-12 16:26 ` Mike Rapoport
2023-02-12 16:26 ` Mike Rapoport
2023-02-12 16:26 ` Mike Rapoport
2023-02-12 16:26 ` Mike Rapoport
2023-02-12 16:26 ` Mike Rapoport
2023-02-12 16:26 ` Mike Rapoport
2023-02-12 17:38 ` Guenter Roeck
2023-02-12 17:38 ` Guenter Roeck
2023-02-12 17:38 ` Guenter Roeck
2023-02-12 17:38 ` Guenter Roeck
2023-02-12 17:38 ` Guenter Roeck
2023-02-12 17:38 ` Guenter Roeck
2023-02-12 17:38 ` Guenter Roeck
2023-02-12 17:38 ` Guenter Roeck
2023-02-13 1:26 ` Mike Rapoport
2023-02-13 1:26 ` Mike Rapoport
2023-02-13 1:26 ` Mike Rapoport
2023-02-13 1:26 ` Mike Rapoport
2023-02-13 1:26 ` Mike Rapoport
2023-02-13 1:26 ` Mike Rapoport
2023-02-13 1:26 ` Mike Rapoport
2023-02-13 1:26 ` Mike Rapoport
2023-02-13 6:37 ` Guenter Roeck
2023-02-13 6:37 ` Guenter Roeck
2023-02-13 6:37 ` Guenter Roeck
2023-02-13 6:37 ` Guenter Roeck
2023-02-13 6:37 ` Guenter Roeck
2023-02-13 6:37 ` Guenter Roeck
2023-02-13 6:37 ` Guenter Roeck
2023-02-13 6:37 ` Guenter Roeck
2023-02-13 7:54 ` Mike Rapoport
2023-02-13 7:54 ` Mike Rapoport
2023-02-13 7:54 ` Mike Rapoport
2023-02-13 7:54 ` Mike Rapoport
2023-02-13 7:54 ` Mike Rapoport
2023-02-13 7:54 ` Mike Rapoport
2023-02-13 7:54 ` Mike Rapoport
2023-02-13 7:54 ` Mike Rapoport
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y9lkCz73v7/iyyLj@spud \
--to=conor@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=bcain@quicinc.com \
--cc=chenhuacai@kernel.org \
--cc=dalias@libc.org \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=dinguyen@kernel.org \
--cc=geert@linux-m68k.org \
--cc=gerg@linux-m68k.org \
--cc=guoren@kernel.org \
--cc=jcmvbkbc@gmail.com \
--cc=linux@armlinux.org.uk \
--cc=mattst88@gmail.com \
--cc=monstr@monstr.eu \
--cc=mpe@ellerman.id.au \
--cc=palmer@dabbelt.com \
--cc=richard@nod.at \
--cc=rppt@kernel.org \
--cc=shorne@gmail.com \
--cc=tsbogend@alpha.franken.de \
--cc=vgupta@kernel \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.