Re: [PATCH v2 09/13] arm, arm64: move free_unused_memmap() to generic mm
On Sun, Nov 01, 2020 at 07:04:50PM +0200, Mike Rapoport wrote: > From: Mike Rapoport > > ARM and ARM64 free unused parts of the memory map just before the > initialization of the page allocator. To allow holes in the memory map both > architectures overload pfn_valid() and define HAVE_ARCH_PFN_VALID. > > Allowing holes in the memory map for FLATMEM may be useful for small > machines, such as ARC and m68k and will enable those architectures to cease > using DISCONTIGMEM and still support more than one memory bank. > > Move the functions that free unused memory map to generic mm and enable > them in case HAVE_ARCH_PFN_VALID=y. > > Signed-off-by: Mike Rapoport For arm64: Acked-by: Catalin Marinas ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed
On 2020-11-13 15:59, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> 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
> pgd = a27bd01c
> [] *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 : []lr : []psr: 6013
> sp : e376bbe0 ip : fp : c1e2921c
> r10: 0002 r9 : c1dda730 r8 :
> r7 : e8ff7a00 r6 : r5 : 02f9ffa0 r4 : e371
> r3 : 000fdffe r2 : c1e0ce80 r1 : ebf979a0 r0 :
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Control: 30c5383d Table: 235c2a80 DAC: fffd
> 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")
> Cc: Stefan Agner
> Cc: Mike Rapoport
> Cc: Kirill A. Shutemov
> Cc: Nitin Gupta
> Cc: Minchan Kim
> Cc: Vineet Gupta
> Cc: linux-snps-arc@lists.infradead.org
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: Thomas Bogendoerfer
> Cc: linux-m...@vger.kernel.org
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: Paul Walmsley
> Cc: Palmer Dabbelt
> Cc: Albert Ou
> Cc: linux-ri...@lists.infradead.org
> Link:
> https://lore.kernel.org/linux-mm/bdfa44bf1c570b05d6c70898e2bbb0acf234ecdf.1604762181.git.ste...@agner.ch/
> Signed-off-by: Arnd Bergmann
> ---
> If everyone is happy with this version, I would suggest merging this as
> a bugfix through my asm-generic tree for linux-5.10. I originally
> said I'd send individual patches for each architecture tree, but
> I now think this is easier and better documents what is going on.
> ---
> arch/arc/include/asm/pgtable.h | 2 ++
> arch/arm/include/asm/pgtable-2level.h| 2 ++
> arch/arm/include/asm/pgtable-3level.h| 2 ++
Tested, it fixed the issue on my test system, thanks!
For ARM:
Reviewed-by: Stefan Agner
Tested-by: Stefan Agner
--
Stefan
> arch/mips/include/asm/pgtable-32.h | 3 +++
> arch/powerpc/include/asm/book3s/32/pgtable.h | 2 ++
> arch/powerpc/include/asm/nohash/32/pgtable.h | 2 ++
> arch/riscv/include/asm/pgtable-32.h | 2 ++
> include/linux/pgtable.h | 13 +
> 8 files changed, 28 insertions(+)
>
> diff --git a/arch/arc/include/asm/pgtable.h b/arch/arc/include/asm/pgtable.h
> index f1ed17edb085..163641726a2b 100644
> --- a/arch/arc/include/asm/pgtable.h
> +++ b/arch/arc/include/asm/pgtable.h
> @@ -134,8 +134,10 @@
>
> #ifdef CONFIG_ARC_HAS_PAE40
> #define PTE_BITS_NON_RWX_IN_PD1 (0xff | PAGE_MASK |
> _PAGE_CACHEABLE)
> +#define MAX_POSSIBLE_PHYSMEM_BITS 40
> #else
> #define PTE_BITS_NON_RWX_IN_PD1 (PAGE_MASK | _PAGE_CACHEABLE)
> +#define MAX_POSSIBLE_PHYSMEM_BITS 32
> #endif
Re: [PATCH] arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed
On Fri, Nov 13, 2020 at 03:59:32PM +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> 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
> pgd = a27bd01c
> [] *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 : []lr : []psr: 6013
> sp : e376bbe0 ip : fp : c1e2921c
> r10: 0002 r9 : c1dda730 r8 :
> r7 : e8ff7a00 r6 : r5 : 02f9ffa0 r4 : e371
> r3 : 000fdffe r2 : c1e0ce80 r1 : ebf979a0 r0 :
> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> Control: 30c5383d Table: 235c2a80 DAC: fffd
> 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")
> Cc: Stefan Agner
> Cc: Mike Rapoport
> Cc: Kirill A. Shutemov
> Cc: Nitin Gupta
> Cc: Minchan Kim
> Cc: Vineet Gupta
> Cc: linux-snps-arc@lists.infradead.org
> Cc: Russell King
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: Thomas Bogendoerfer
> Cc: linux-m...@vger.kernel.org
> Cc: Michael Ellerman
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: Paul Walmsley
> Cc: Palmer Dabbelt
> Cc: Albert Ou
> Cc: linux-ri...@lists.infradead.org
> Link:
> https://lore.kernel.org/linux-mm/bdfa44bf1c570b05d6c70898e2bbb0acf234ecdf.1604762181.git.ste...@agner.ch/
> Signed-off-by: Arnd Bergmann
Acked-by: Mike Rapoport
> ---
> If everyone is happy with this version, I would suggest merging this as
> a bugfix through my asm-generic tree for linux-5.10. I originally
> said I'd send individual patches for each architecture tree, but
> I now think this is easier and better documents what is going on.
> ---
> arch/arc/include/asm/pgtable.h | 2 ++
> arch/arm/include/asm/pgtable-2level.h| 2 ++
> arch/arm/include/asm/pgtable-3level.h| 2 ++
> arch/mips/include/asm/pgtable-32.h | 3 +++
> arch/powerpc/include/asm/book3s/32/pgtable.h | 2 ++
> arch/powerpc/include/asm/nohash/32/pgtable.h | 2 ++
> arch/riscv/include/asm/pgtable-32.h | 2 ++
> include/linux/pgtable.h | 13 +
> 8 files changed, 28 insertions(+)
>
> diff --git a/arch/arc/include/asm/pgtable.h b/arch/arc/include/asm/pgtable.h
> index f1ed17edb085..163641726a2b 100644
> --- a/arch/arc/include/asm/pgtable.h
> +++ b/arch/arc/include/asm/pgtable.h
> @@ -134,8 +134,10 @@
>
> #ifdef CONFIG_ARC_HAS_PAE40
> #define PTE_BITS_NON_RWX_IN_PD1 (0xff | PAGE_MASK |
> _PAGE_CACHEABLE)
> +#define MAX_POSSIBLE_PHYSMEM_BITS 40
> #else
> #define PTE_BITS_NON_RWX_IN_PD1 (PAGE_MASK | _PAGE_CACHEABLE)
> +#define MAX_POSSIBLE_PHYSMEM_BITS 32
> #endif
>
> /**
