commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear
mapping") added logic to allow using RAM below the kernel load address.
However, this does not work for NOMMU, where PAGE_OFFSET is fixed to the
kernel load address. Since that range of memory corresponds to PFNs
below ARCH_PFN_OFFSET, mm initialization runs off the beginning of
mem_map and corrupts adjacent kernel memory. Fix this by restoring the
previous behavior for NOMMU kernels.

Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping")
Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
---

 arch/riscv/include/asm/page.h | 2 +-
 arch/riscv/mm/init.c          | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
index 57e887bfa34c..94b3d6930fc3 100644
--- a/arch/riscv/include/asm/page.h
+++ b/arch/riscv/include/asm/page.h
@@ -89,7 +89,7 @@ typedef struct page *pgtable_t;
 #define PTE_FMT "%08lx"
 #endif
 
-#ifdef CONFIG_64BIT
+#if defined(CONFIG_64BIT) && defined(CONFIG_MMU)
 /*
  * We override this value as its generic definition uses __pa too early in
  * the boot process (before kernel_map.va_pa_offset is set).
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
index fa34cf55037b..0c00efc75643 100644
--- a/arch/riscv/mm/init.c
+++ b/arch/riscv/mm/init.c
@@ -232,7 +232,7 @@ static void __init setup_bootmem(void)
 	 * In 64-bit, any use of __va/__pa before this point is wrong as we
 	 * did not know the start of DRAM before.
 	 */
-	if (IS_ENABLED(CONFIG_64BIT))
+	if (IS_ENABLED(CONFIG_64BIT) && IS_ENABLED(CONFIG_MMU))
 		kernel_map.va_pa_offset = PAGE_OFFSET - phys_ram_base;
 
 	/*
-- 
2.43.0

On Mon, Feb 26, 2024 at 04:34:47PM -0800, Samuel Holland wrote:
> commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear
> mapping") added logic to allow using RAM below the kernel load address.
> However, this does not work for NOMMU, where PAGE_OFFSET is fixed to the
> kernel load address. Since that range of memory corresponds to PFNs
> below ARCH_PFN_OFFSET, mm initialization runs off the beginning of
> mem_map and corrupts adjacent kernel memory. Fix this by restoring the
> previous behavior for NOMMU kernels.
> 
> Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping")

This commit was a year ago, why has nobody reported this as being an
issue before?

> Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
> ---
> 
>  arch/riscv/include/asm/page.h | 2 +-
>  arch/riscv/mm/init.c          | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
> index 57e887bfa34c..94b3d6930fc3 100644
> --- a/arch/riscv/include/asm/page.h
> +++ b/arch/riscv/include/asm/page.h
> @@ -89,7 +89,7 @@ typedef struct page *pgtable_t;
>  #define PTE_FMT "%08lx"
>  #endif
>  
> -#ifdef CONFIG_64BIT
> +#if defined(CONFIG_64BIT) && defined(CONFIG_MMU)
>  /*
>   * We override this value as its generic definition uses __pa too early in
>   * the boot process (before kernel_map.va_pa_offset is set).
> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
> index fa34cf55037b..0c00efc75643 100644
> --- a/arch/riscv/mm/init.c
> +++ b/arch/riscv/mm/init.c
> @@ -232,7 +232,7 @@ static void __init setup_bootmem(void)
>  	 * In 64-bit, any use of __va/__pa before this point is wrong as we
>  	 * did not know the start of DRAM before.
>  	 */
> -	if (IS_ENABLED(CONFIG_64BIT))
> +	if (IS_ENABLED(CONFIG_64BIT) && IS_ENABLED(CONFIG_MMU))
>  		kernel_map.va_pa_offset = PAGE_OFFSET - phys_ram_base;
>  
>  	/*
> -- 
> 2.43.0
> 

Hi Conor,

On 2024-02-27 6:18 AM, Conor Dooley wrote:
> On Mon, Feb 26, 2024 at 04:34:47PM -0800, Samuel Holland wrote:
>> commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear
>> mapping") added logic to allow using RAM below the kernel load address.
>> However, this does not work for NOMMU, where PAGE_OFFSET is fixed to the
>> kernel load address. Since that range of memory corresponds to PFNs
>> below ARCH_PFN_OFFSET, mm initialization runs off the beginning of
>> mem_map and corrupts adjacent kernel memory. Fix this by restoring the
>> previous behavior for NOMMU kernels.
>>
>> Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping")
> 
> This commit was a year ago, why has nobody reported this as being an
> issue before?

I can think of a few reasons:
1) NOMMU users are likely to be using RV32, which is not affected.
2) Before patch 4 of this series, NOMMU implied M-mode, so there was nothing in
the way to prevent loading Linux at the very beginning of RAM. (U-Boot/SPL
relocates itself to the end of RAM, so it would not cause a problem.)
3) Platforms where RAM does not begin at exactly 0x80000000 would be affected,
there are several workarounds: change the start of RAM (for soft cores), change
PAGE_OFFSET, or change the memory ranges in the devicetree to exclude anything
below PAGE_OFFSET.

It's possible that nobody was affected, but it's still technically a regression
(a hypothetical platform with RAM from 0x40000000 to 0xc0000000 would crash
instead of only being able to use half its RAM), so I thought it still deserved
the Fixes: tag.

Regards,
Samuel

>> Signed-off-by: Samuel Holland <samuel.holland@sifive.com>
>> ---
>>
>>  arch/riscv/include/asm/page.h | 2 +-
>>  arch/riscv/mm/init.c          | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
>> index 57e887bfa34c..94b3d6930fc3 100644
>> --- a/arch/riscv/include/asm/page.h
>> +++ b/arch/riscv/include/asm/page.h
>> @@ -89,7 +89,7 @@ typedef struct page *pgtable_t;
>>  #define PTE_FMT "%08lx"
>>  #endif
>>  
>> -#ifdef CONFIG_64BIT
>> +#if defined(CONFIG_64BIT) && defined(CONFIG_MMU)
>>  /*
>>   * We override this value as its generic definition uses __pa too early in
>>   * the boot process (before kernel_map.va_pa_offset is set).
>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
>> index fa34cf55037b..0c00efc75643 100644
>> --- a/arch/riscv/mm/init.c
>> +++ b/arch/riscv/mm/init.c
>> @@ -232,7 +232,7 @@ static void __init setup_bootmem(void)
>>  	 * In 64-bit, any use of __va/__pa before this point is wrong as we
>>  	 * did not know the start of DRAM before.
>>  	 */
>> -	if (IS_ENABLED(CONFIG_64BIT))
>> +	if (IS_ENABLED(CONFIG_64BIT) && IS_ENABLED(CONFIG_MMU))
>>  		kernel_map.va_pa_offset = PAGE_OFFSET - phys_ram_base;
>>  
>>  	/*
>> -- 
>> 2.43.0
>>

On Tue, Feb 27, 2024 at 01:22:12PM -0600, Samuel Holland wrote:
> Hi Conor,
> 
> On 2024-02-27 6:18 AM, Conor Dooley wrote:
> > On Mon, Feb 26, 2024 at 04:34:47PM -0800, Samuel Holland wrote:
> >> commit 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear
> >> mapping") added logic to allow using RAM below the kernel load address.
> >> However, this does not work for NOMMU, where PAGE_OFFSET is fixed to the
> >> kernel load address. Since that range of memory corresponds to PFNs
> >> below ARCH_PFN_OFFSET, mm initialization runs off the beginning of
> >> mem_map and corrupts adjacent kernel memory. Fix this by restoring the
> >> previous behavior for NOMMU kernels.
> >>
> >> Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping")
> > 
> > This commit was a year ago, why has nobody reported this as being an
> > issue before?
> 
> I can think of a few reasons:
> 1) NOMMU users are likely to be using RV32, which is not affected.
> 2) Before patch 4 of this series, NOMMU implied M-mode, so there was nothing in
> the way to prevent loading Linux at the very beginning of RAM. (U-Boot/SPL
> relocates itself to the end of RAM, so it would not cause a problem.)
> 3) Platforms where RAM does not begin at exactly 0x80000000 would be affected,
> there are several workarounds: change the start of RAM (for soft cores), change
> PAGE_OFFSET, or change the memory ranges in the devicetree to exclude anything
> below PAGE_OFFSET.
> 
> It's possible that nobody was affected, but it's still technically a regression
> (a hypothetical platform with RAM from 0x40000000 to 0xc0000000 would crash
> instead of only being able to use half its RAM), so I thought it still deserved
> the Fixes: tag.

Right, thanks for explaining.

Cheers,
Conor.