From: Greg KH <gregkh@linuxfoundation.org>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Sasha Levin <sashal@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Stefan Agner <stefan@agner.ch>,
Mike Rapoport <rppt@linux.ibm.com>,
Vineet Gupta <vgupta@synopsys.com>,
Russell King <linux@armlinux.org.uk>,
Ralf Baechle <ralf@linux-mips.org>,
Paul Burton <paul.burton@mips.com>,
James Hogan <jhogan@kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Palmer Dabbelt <palmer@sifive.com>,
Albert Ou <aou@eecs.berkeley.edu>,
"open list:SYNOPSYS ARC ARCHITECTURE"
<linux-snps-arc@lists.infradead.org>,
"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
"open list:MIPS" <linux-mips@linux-mips.org>,
"open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)"
<linuxppc-dev@lists.ozlabs.org>,
"open list:RISC-V ARCHITECTURE" <linux-riscv@lists.infradead.org>,
"open list:GENERIC INCLUDE/ASM HEADER FILES"
<linux-arch@vger.kernel.org>
Subject: Re: [PATCH stable 4.19 1/1] arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed
Date: Thu, 4 Nov 2021 09:34:58 +0100 [thread overview]
Message-ID: <YYObMlXLFi7pAJ83@kroah.com> (raw)
In-Reply-To: <20211103205656.374678-1-f.fainelli@gmail.com>
On Wed, Nov 03, 2021 at 01:56:56PM -0700, Florian Fainelli wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> [ Upstream commit cef397038167ac15d085914493d6c86385773709 ]
>
> Stefan Agner reported a bug when using zsram on 32-bit Arm machines
> with RAM above the 4GB address boundary:
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = a27bd01c
> [00000000] *pgd=236a0003, *pmd=1ffa64003
> Internal error: Oops: 207 [#1] SMP ARM
> Modules linked in: mdio_bcm_unimac(+) brcmfmac cfg80211 brcmutil raspberrypi_hwmon hci_uart crc32_arm_ce bcm2711_thermal phy_generic genet
> CPU: 0 PID: 123 Comm: mkfs.ext4 Not tainted 5.9.6 #1
> Hardware name: BCM2711
> PC is at zs_map_object+0x94/0x338
> LR is at zram_bvec_rw.constprop.0+0x330/0xa64
> pc : [<c0602b38>] lr : [<c0bda6a0>] psr: 60000013
> sp : e376bbe0 ip : 00000000 fp : c1e2921c
> r10: 00000002 r9 : c1dda730 r8 : 00000000
> r7 : e8ff7a00 r6 : 00000000 r5 : 02f9ffa0 r4 : e3710000
> r3 : 000fdffe r2 : c1e0ce80 r1 : ebf979a0 r0 : 00000000
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Control: 30c5383d Table: 235c2a80 DAC: fffffffd
> Process mkfs.ext4 (pid: 123, stack limit = 0x495a22e6)
> Stack: (0xe376bbe0 to 0xe376c000)
>
> As it turns out, zsram needs to know the maximum memory size, which
> is defined in MAX_PHYSMEM_BITS when CONFIG_SPARSEMEM is set, or in
> MAX_POSSIBLE_PHYSMEM_BITS on the x86 architecture.
>
> The same problem will be hit on all 32-bit architectures that have a
> physical address space larger than 4GB and happen to not enable sparsemem
> and include asm/sparsemem.h from asm/pgtable.h.
>
> After the initial discussion, I suggested just always defining
> MAX_POSSIBLE_PHYSMEM_BITS whenever CONFIG_PHYS_ADDR_T_64BIT is
> set, or provoking a build error otherwise. This addresses all
> configurations that can currently have this runtime bug, but
> leaves all other configurations unchanged.
>
> I looked up the possible number of bits in source code and
> datasheets, here is what I found:
>
> - on ARC, CONFIG_ARC_HAS_PAE40 controls whether 32 or 40 bits are used
> - on ARM, CONFIG_LPAE enables 40 bit addressing, without it we never
> support more than 32 bits, even though supersections in theory allow
> up to 40 bits as well.
> - on MIPS, some MIPS32r1 or later chips support 36 bits, and MIPS32r5
> XPA supports up to 60 bits in theory, but 40 bits are more than
> anyone will ever ship
> - On PowerPC, there are three different implementations of 36 bit
> addressing, but 32-bit is used without CONFIG_PTE_64BIT
> - On RISC-V, the normal page table format can support 34 bit
> addressing. There is no highmem support on RISC-V, so anything
> above 2GB is unused, but it might be useful to eventually support
> CONFIG_ZRAM for high pages.
>
> Fixes: 61989a80fb3a ("staging: zsmalloc: zsmalloc memory allocation library")
> Fixes: 02390b87a945 ("mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS")
> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Reviewed-by: Stefan Agner <stefan@agner.ch>
> Tested-by: Stefan Agner <stefan@agner.ch>
> Acked-by: Mike Rapoport <rppt@linux.ibm.com>
> Link: https://lore.kernel.org/linux-mm/bdfa44bf1c570b05d6c70898e2bbb0acf234ecdf.1604762181.git.stefan@agner.ch/
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> [florian: patch arch/powerpc/include/asm/pte-common.h for 4.19.y]
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
All now queued up, thanks.
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Sasha Levin <sashal@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Stefan Agner <stefan@agner.ch>,
Mike Rapoport <rppt@linux.ibm.com>,
Vineet Gupta <vgupta@synopsys.com>,
Russell King <linux@armlinux.org.uk>,
Ralf Baechle <ralf@linux-mips.org>,
Paul Burton <paul.burton@mips.com>,
James Hogan <jhogan@kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Palmer Dabbelt <palmer@sifive.com>,
Albert Ou <aou@eecs.berkeley.edu>,
"open list:SYNOPSYS ARC ARCHITECTURE"
<linux-snps-arc@lists.infradead.org>,
"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
"open list:MIPS" <linux-mips@linux-mips.org>,
"open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)"
<linuxppc-dev@lists.ozlabs.org>,
"open list:RISC-V ARCHITECTURE"
<linux-riscv@lists.infradead.org>,
"open list:GENERIC INCLUDE/ASM HEADER FILES"
<linux-arch@vger.kernel.org>
Subject: Re: [PATCH stable 4.19 1/1] arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed
Date: Thu, 4 Nov 2021 09:34:58 +0100 [thread overview]
Message-ID: <YYObMlXLFi7pAJ83@kroah.com> (raw)
In-Reply-To: <20211103205656.374678-1-f.fainelli@gmail.com>
On Wed, Nov 03, 2021 at 01:56:56PM -0700, Florian Fainelli wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> [ Upstream commit cef397038167ac15d085914493d6c86385773709 ]
>
> Stefan Agner reported a bug when using zsram on 32-bit Arm machines
> with RAM above the 4GB address boundary:
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = a27bd01c
> [00000000] *pgd=236a0003, *pmd=1ffa64003
> Internal error: Oops: 207 [#1] SMP ARM
> Modules linked in: mdio_bcm_unimac(+) brcmfmac cfg80211 brcmutil raspberrypi_hwmon hci_uart crc32_arm_ce bcm2711_thermal phy_generic genet
> CPU: 0 PID: 123 Comm: mkfs.ext4 Not tainted 5.9.6 #1
> Hardware name: BCM2711
> PC is at zs_map_object+0x94/0x338
> LR is at zram_bvec_rw.constprop.0+0x330/0xa64
> pc : [<c0602b38>] lr : [<c0bda6a0>] psr: 60000013
> sp : e376bbe0 ip : 00000000 fp : c1e2921c
> r10: 00000002 r9 : c1dda730 r8 : 00000000
> r7 : e8ff7a00 r6 : 00000000 r5 : 02f9ffa0 r4 : e3710000
> r3 : 000fdffe r2 : c1e0ce80 r1 : ebf979a0 r0 : 00000000
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Control: 30c5383d Table: 235c2a80 DAC: fffffffd
> Process mkfs.ext4 (pid: 123, stack limit = 0x495a22e6)
> Stack: (0xe376bbe0 to 0xe376c000)
>
> As it turns out, zsram needs to know the maximum memory size, which
> is defined in MAX_PHYSMEM_BITS when CONFIG_SPARSEMEM is set, or in
> MAX_POSSIBLE_PHYSMEM_BITS on the x86 architecture.
>
> The same problem will be hit on all 32-bit architectures that have a
> physical address space larger than 4GB and happen to not enable sparsemem
> and include asm/sparsemem.h from asm/pgtable.h.
>
> After the initial discussion, I suggested just always defining
> MAX_POSSIBLE_PHYSMEM_BITS whenever CONFIG_PHYS_ADDR_T_64BIT is
> set, or provoking a build error otherwise. This addresses all
> configurations that can currently have this runtime bug, but
> leaves all other configurations unchanged.
>
> I looked up the possible number of bits in source code and
> datasheets, here is what I found:
>
> - on ARC, CONFIG_ARC_HAS_PAE40 controls whether 32 or 40 bits are used
> - on ARM, CONFIG_LPAE enables 40 bit addressing, without it we never
> support more than 32 bits, even though supersections in theory allow
> up to 40 bits as well.
> - on MIPS, some MIPS32r1 or later chips support 36 bits, and MIPS32r5
> XPA supports up to 60 bits in theory, but 40 bits are more than
> anyone will ever ship
> - On PowerPC, there are three different implementations of 36 bit
> addressing, but 32-bit is used without CONFIG_PTE_64BIT
> - On RISC-V, the normal page table format can support 34 bit
> addressing. There is no highmem support on RISC-V, so anything
> above 2GB is unused, but it might be useful to eventually support
> CONFIG_ZRAM for high pages.
>
> Fixes: 61989a80fb3a ("staging: zsmalloc: zsmalloc memory allocation library")
> Fixes: 02390b87a945 ("mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS")
> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Reviewed-by: Stefan Agner <stefan@agner.ch>
> Tested-by: Stefan Agner <stefan@agner.ch>
> Acked-by: Mike Rapoport <rppt@linux.ibm.com>
> Link: https://lore.kernel.org/linux-mm/bdfa44bf1c570b05d6c70898e2bbb0acf234ecdf.1604762181.git.stefan@agner.ch/
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> [florian: patch arch/powerpc/include/asm/pte-common.h for 4.19.y]
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
All now queued up, thanks.
greg k-h
_______________________________________________
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: Greg KH <gregkh@linuxfoundation.org>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Sasha Levin <sashal@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Stefan Agner <stefan@agner.ch>,
Mike Rapoport <rppt@linux.ibm.com>,
Vineet Gupta <vgupta@synopsys.com>,
Russell King <linux@armlinux.org.uk>,
Ralf Baechle <ralf@linux-mips.org>,
Paul Burton <paul.burton@mips.com>,
James Hogan <jhogan@kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Palmer Dabbelt <palmer@sifive.com>,
Albert Ou <aou@eecs.berkeley.edu>,
"open list:SYNOPSYS ARC ARCHITECTURE"
<linux-snps-arc@lists.infradead.org>,
"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
"open list:MIPS" <linux-mips@linux-mips.org>,
"open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)"
<linuxppc-dev@lists.ozlabs.org>,
"open list:RISC-V ARCHITECTURE"
<linux-riscv@lists.infradead.org>,
"open list:GENERIC INCLUDE/ASM HEADER FILES"
<linux-arch@vger.kernel.org>
Subject: Re: [PATCH stable 4.19 1/1] arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed
Date: Thu, 4 Nov 2021 09:34:58 +0100 [thread overview]
Message-ID: <YYObMlXLFi7pAJ83@kroah.com> (raw)
In-Reply-To: <20211103205656.374678-1-f.fainelli@gmail.com>
On Wed, Nov 03, 2021 at 01:56:56PM -0700, Florian Fainelli wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> [ Upstream commit cef397038167ac15d085914493d6c86385773709 ]
>
> Stefan Agner reported a bug when using zsram on 32-bit Arm machines
> with RAM above the 4GB address boundary:
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = a27bd01c
> [00000000] *pgd=236a0003, *pmd=1ffa64003
> Internal error: Oops: 207 [#1] SMP ARM
> Modules linked in: mdio_bcm_unimac(+) brcmfmac cfg80211 brcmutil raspberrypi_hwmon hci_uart crc32_arm_ce bcm2711_thermal phy_generic genet
> CPU: 0 PID: 123 Comm: mkfs.ext4 Not tainted 5.9.6 #1
> Hardware name: BCM2711
> PC is at zs_map_object+0x94/0x338
> LR is at zram_bvec_rw.constprop.0+0x330/0xa64
> pc : [<c0602b38>] lr : [<c0bda6a0>] psr: 60000013
> sp : e376bbe0 ip : 00000000 fp : c1e2921c
> r10: 00000002 r9 : c1dda730 r8 : 00000000
> r7 : e8ff7a00 r6 : 00000000 r5 : 02f9ffa0 r4 : e3710000
> r3 : 000fdffe r2 : c1e0ce80 r1 : ebf979a0 r0 : 00000000
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Control: 30c5383d Table: 235c2a80 DAC: fffffffd
> Process mkfs.ext4 (pid: 123, stack limit = 0x495a22e6)
> Stack: (0xe376bbe0 to 0xe376c000)
>
> As it turns out, zsram needs to know the maximum memory size, which
> is defined in MAX_PHYSMEM_BITS when CONFIG_SPARSEMEM is set, or in
> MAX_POSSIBLE_PHYSMEM_BITS on the x86 architecture.
>
> The same problem will be hit on all 32-bit architectures that have a
> physical address space larger than 4GB and happen to not enable sparsemem
> and include asm/sparsemem.h from asm/pgtable.h.
>
> After the initial discussion, I suggested just always defining
> MAX_POSSIBLE_PHYSMEM_BITS whenever CONFIG_PHYS_ADDR_T_64BIT is
> set, or provoking a build error otherwise. This addresses all
> configurations that can currently have this runtime bug, but
> leaves all other configurations unchanged.
>
> I looked up the possible number of bits in source code and
> datasheets, here is what I found:
>
> - on ARC, CONFIG_ARC_HAS_PAE40 controls whether 32 or 40 bits are used
> - on ARM, CONFIG_LPAE enables 40 bit addressing, without it we never
> support more than 32 bits, even though supersections in theory allow
> up to 40 bits as well.
> - on MIPS, some MIPS32r1 or later chips support 36 bits, and MIPS32r5
> XPA supports up to 60 bits in theory, but 40 bits are more than
> anyone will ever ship
> - On PowerPC, there are three different implementations of 36 bit
> addressing, but 32-bit is used without CONFIG_PTE_64BIT
> - On RISC-V, the normal page table format can support 34 bit
> addressing. There is no highmem support on RISC-V, so anything
> above 2GB is unused, but it might be useful to eventually support
> CONFIG_ZRAM for high pages.
>
> Fixes: 61989a80fb3a ("staging: zsmalloc: zsmalloc memory allocation library")
> Fixes: 02390b87a945 ("mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS")
> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Reviewed-by: Stefan Agner <stefan@agner.ch>
> Tested-by: Stefan Agner <stefan@agner.ch>
> Acked-by: Mike Rapoport <rppt@linux.ibm.com>
> Link: https://lore.kernel.org/linux-mm/bdfa44bf1c570b05d6c70898e2bbb0acf234ecdf.1604762181.git.stefan@agner.ch/
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> [florian: patch arch/powerpc/include/asm/pte-common.h for 4.19.y]
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
All now queued up, thanks.
greg k-h
_______________________________________________
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: Greg KH <gregkh@linuxfoundation.org>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: "open list:MIPS" <linux-mips@linux-mips.org>,
Palmer Dabbelt <palmer@sifive.com>,
Stefan Agner <stefan@agner.ch>, Paul Mackerras <paulus@samba.org>,
stable@vger.kernel.org,
"open list:RISC-V ARCHITECTURE" <linux-riscv@lists.infradead.org>,
Sasha Levin <sashal@kernel.org>,
Russell King <linux@armlinux.org.uk>,
Mike Rapoport <rppt@linux.ibm.com>,
James Hogan <jhogan@kernel.org>,
"open list:SYNOPSYS ARC ARCHITECTURE"
<linux-snps-arc@lists.infradead.org>,
"open list:GENERIC INCLUDE/ASM HEADER FILES"
<linux-arch@vger.kernel.org>, Albert Ou <aou@eecs.berkeley.edu>,
Arnd Bergmann <arnd@arndb.de>,
"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Vineet Gupta <vgupta@synopsys.com>,
linux-kernel@vger.kernel.org, Ralf Baechle <ralf@linux-mips.org>,
Paul Burton <paul.burton@mips.com>,
"open list:LINUX FOR POWERPC \(32-BIT AND 64-BIT\)"
<linuxppc-dev@lists.ozlabs.org>
Subject: Re: [PATCH stable 4.19 1/1] arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed
Date: Thu, 4 Nov 2021 09:34:58 +0100 [thread overview]
Message-ID: <YYObMlXLFi7pAJ83@kroah.com> (raw)
In-Reply-To: <20211103205656.374678-1-f.fainelli@gmail.com>
On Wed, Nov 03, 2021 at 01:56:56PM -0700, Florian Fainelli wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> [ Upstream commit cef397038167ac15d085914493d6c86385773709 ]
>
> Stefan Agner reported a bug when using zsram on 32-bit Arm machines
> with RAM above the 4GB address boundary:
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = a27bd01c
> [00000000] *pgd=236a0003, *pmd=1ffa64003
> Internal error: Oops: 207 [#1] SMP ARM
> Modules linked in: mdio_bcm_unimac(+) brcmfmac cfg80211 brcmutil raspberrypi_hwmon hci_uart crc32_arm_ce bcm2711_thermal phy_generic genet
> CPU: 0 PID: 123 Comm: mkfs.ext4 Not tainted 5.9.6 #1
> Hardware name: BCM2711
> PC is at zs_map_object+0x94/0x338
> LR is at zram_bvec_rw.constprop.0+0x330/0xa64
> pc : [<c0602b38>] lr : [<c0bda6a0>] psr: 60000013
> sp : e376bbe0 ip : 00000000 fp : c1e2921c
> r10: 00000002 r9 : c1dda730 r8 : 00000000
> r7 : e8ff7a00 r6 : 00000000 r5 : 02f9ffa0 r4 : e3710000
> r3 : 000fdffe r2 : c1e0ce80 r1 : ebf979a0 r0 : 00000000
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Control: 30c5383d Table: 235c2a80 DAC: fffffffd
> Process mkfs.ext4 (pid: 123, stack limit = 0x495a22e6)
> Stack: (0xe376bbe0 to 0xe376c000)
>
> As it turns out, zsram needs to know the maximum memory size, which
> is defined in MAX_PHYSMEM_BITS when CONFIG_SPARSEMEM is set, or in
> MAX_POSSIBLE_PHYSMEM_BITS on the x86 architecture.
>
> The same problem will be hit on all 32-bit architectures that have a
> physical address space larger than 4GB and happen to not enable sparsemem
> and include asm/sparsemem.h from asm/pgtable.h.
>
> After the initial discussion, I suggested just always defining
> MAX_POSSIBLE_PHYSMEM_BITS whenever CONFIG_PHYS_ADDR_T_64BIT is
> set, or provoking a build error otherwise. This addresses all
> configurations that can currently have this runtime bug, but
> leaves all other configurations unchanged.
>
> I looked up the possible number of bits in source code and
> datasheets, here is what I found:
>
> - on ARC, CONFIG_ARC_HAS_PAE40 controls whether 32 or 40 bits are used
> - on ARM, CONFIG_LPAE enables 40 bit addressing, without it we never
> support more than 32 bits, even though supersections in theory allow
> up to 40 bits as well.
> - on MIPS, some MIPS32r1 or later chips support 36 bits, and MIPS32r5
> XPA supports up to 60 bits in theory, but 40 bits are more than
> anyone will ever ship
> - On PowerPC, there are three different implementations of 36 bit
> addressing, but 32-bit is used without CONFIG_PTE_64BIT
> - On RISC-V, the normal page table format can support 34 bit
> addressing. There is no highmem support on RISC-V, so anything
> above 2GB is unused, but it might be useful to eventually support
> CONFIG_ZRAM for high pages.
>
> Fixes: 61989a80fb3a ("staging: zsmalloc: zsmalloc memory allocation library")
> Fixes: 02390b87a945 ("mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS")
> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Reviewed-by: Stefan Agner <stefan@agner.ch>
> Tested-by: Stefan Agner <stefan@agner.ch>
> Acked-by: Mike Rapoport <rppt@linux.ibm.com>
> Link: https://lore.kernel.org/linux-mm/bdfa44bf1c570b05d6c70898e2bbb0acf234ecdf.1604762181.git.stefan@agner.ch/
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> [florian: patch arch/powerpc/include/asm/pte-common.h for 4.19.y]
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
All now queued up, thanks.
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <gregkh@linuxfoundation.org>
To: Florian Fainelli <f.fainelli@gmail.com>
Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Sasha Levin <sashal@kernel.org>, Arnd Bergmann <arnd@arndb.de>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Stefan Agner <stefan@agner.ch>,
Mike Rapoport <rppt@linux.ibm.com>,
Vineet Gupta <vgupta@synopsys.com>,
Russell King <linux@armlinux.org.uk>,
Ralf Baechle <ralf@linux-mips.org>,
Paul Burton <paul.burton@mips.com>,
James Hogan <jhogan@kernel.org>,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Palmer Dabbelt <palmer@sifive.com>,
Albert Ou <aou@eecs.berkeley.edu>,
"open list:SYNOPSYS ARC ARCHITECTURE"
<linux-snps-arc@lists.infradead.org>,
"moderated list:ARM PORT" <linux-arm-kernel@lists.infradead.org>,
"open list:MIPS" <linux-mips@linux-mips.org>,
"open list:LINUX FOR POWERPC (32-BIT AND 64-BIT)"
<linuxppc-dev@lists.ozlabs.org>,
"open list:RISC-V ARCHITECTURE"
<linux-riscv@lists.infradead.org>,
"open list:GENERIC INCLUDE/ASM HEADER FILES"
<linux-arch@vger.kernel.org>
Subject: Re: [PATCH stable 4.19 1/1] arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed
Date: Thu, 4 Nov 2021 09:34:58 +0100 [thread overview]
Message-ID: <YYObMlXLFi7pAJ83@kroah.com> (raw)
In-Reply-To: <20211103205656.374678-1-f.fainelli@gmail.com>
On Wed, Nov 03, 2021 at 01:56:56PM -0700, Florian Fainelli wrote:
> From: Arnd Bergmann <arnd@arndb.de>
>
> [ Upstream commit cef397038167ac15d085914493d6c86385773709 ]
>
> Stefan Agner reported a bug when using zsram on 32-bit Arm machines
> with RAM above the 4GB address boundary:
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> pgd = a27bd01c
> [00000000] *pgd=236a0003, *pmd=1ffa64003
> Internal error: Oops: 207 [#1] SMP ARM
> Modules linked in: mdio_bcm_unimac(+) brcmfmac cfg80211 brcmutil raspberrypi_hwmon hci_uart crc32_arm_ce bcm2711_thermal phy_generic genet
> CPU: 0 PID: 123 Comm: mkfs.ext4 Not tainted 5.9.6 #1
> Hardware name: BCM2711
> PC is at zs_map_object+0x94/0x338
> LR is at zram_bvec_rw.constprop.0+0x330/0xa64
> pc : [<c0602b38>] lr : [<c0bda6a0>] psr: 60000013
> sp : e376bbe0 ip : 00000000 fp : c1e2921c
> r10: 00000002 r9 : c1dda730 r8 : 00000000
> r7 : e8ff7a00 r6 : 00000000 r5 : 02f9ffa0 r4 : e3710000
> r3 : 000fdffe r2 : c1e0ce80 r1 : ebf979a0 r0 : 00000000
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Control: 30c5383d Table: 235c2a80 DAC: fffffffd
> Process mkfs.ext4 (pid: 123, stack limit = 0x495a22e6)
> Stack: (0xe376bbe0 to 0xe376c000)
>
> As it turns out, zsram needs to know the maximum memory size, which
> is defined in MAX_PHYSMEM_BITS when CONFIG_SPARSEMEM is set, or in
> MAX_POSSIBLE_PHYSMEM_BITS on the x86 architecture.
>
> The same problem will be hit on all 32-bit architectures that have a
> physical address space larger than 4GB and happen to not enable sparsemem
> and include asm/sparsemem.h from asm/pgtable.h.
>
> After the initial discussion, I suggested just always defining
> MAX_POSSIBLE_PHYSMEM_BITS whenever CONFIG_PHYS_ADDR_T_64BIT is
> set, or provoking a build error otherwise. This addresses all
> configurations that can currently have this runtime bug, but
> leaves all other configurations unchanged.
>
> I looked up the possible number of bits in source code and
> datasheets, here is what I found:
>
> - on ARC, CONFIG_ARC_HAS_PAE40 controls whether 32 or 40 bits are used
> - on ARM, CONFIG_LPAE enables 40 bit addressing, without it we never
> support more than 32 bits, even though supersections in theory allow
> up to 40 bits as well.
> - on MIPS, some MIPS32r1 or later chips support 36 bits, and MIPS32r5
> XPA supports up to 60 bits in theory, but 40 bits are more than
> anyone will ever ship
> - On PowerPC, there are three different implementations of 36 bit
> addressing, but 32-bit is used without CONFIG_PTE_64BIT
> - On RISC-V, the normal page table format can support 34 bit
> addressing. There is no highmem support on RISC-V, so anything
> above 2GB is unused, but it might be useful to eventually support
> CONFIG_ZRAM for high pages.
>
> Fixes: 61989a80fb3a ("staging: zsmalloc: zsmalloc memory allocation library")
> Fixes: 02390b87a945 ("mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS")
> Acked-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> Reviewed-by: Stefan Agner <stefan@agner.ch>
> Tested-by: Stefan Agner <stefan@agner.ch>
> Acked-by: Mike Rapoport <rppt@linux.ibm.com>
> Link: https://lore.kernel.org/linux-mm/bdfa44bf1c570b05d6c70898e2bbb0acf234ecdf.1604762181.git.stefan@agner.ch/
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> [florian: patch arch/powerpc/include/asm/pte-common.h for 4.19.y]
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
All now queued up, thanks.
greg k-h
_______________________________________________
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:[~2021-11-04 8:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-03 20:56 [PATCH stable 4.19 1/1] arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed Florian Fainelli
2021-11-03 20:56 ` Florian Fainelli
2021-11-03 20:56 ` Florian Fainelli
2021-11-03 20:56 ` Florian Fainelli
2021-11-03 20:56 ` Florian Fainelli
2021-11-04 8:34 ` Greg KH [this message]
2021-11-04 8:34 ` Greg KH
2021-11-04 8:34 ` Greg KH
2021-11-04 8:34 ` Greg KH
2021-11-04 8:34 ` Greg KH
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=YYObMlXLFi7pAJ83@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=aou@eecs.berkeley.edu \
--cc=arnd@arndb.de \
--cc=benh@kernel.crashing.org \
--cc=f.fainelli@gmail.com \
--cc=jhogan@kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
--cc=palmer@sifive.com \
--cc=paul.burton@mips.com \
--cc=paulus@samba.org \
--cc=ralf@linux-mips.org \
--cc=rppt@linux.ibm.com \
--cc=sashal@kernel.org \
--cc=stable@vger.kernel.org \
--cc=stefan@agner.ch \
--cc=tsbogend@alpha.franken.de \
--cc=vgupta@synopsys.com \
/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.