[PATCH v3] MIPS: Fix memory reservation in bootmem_init for certain non-usermem setups

[PATCH v3] MIPS: Fix memory reservation in bootmem_init for certain non-usermem setups

[Tobias Wolf]

Commit 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling") introduced a new
issue for rt288x where "PHYS_OFFSET" is 0x0 but the calculated "ramstart" is
not. As the prerequisite of custom memory map has been removed, this results
in the full memory range of 0x0 - 0x8000000 to be marked as reserved for this
platform.

This patch adds the originally intended prerequisite again.

Signed-off-by: Tobias Wolf <dev-NTEO@vplace.de>
---
 arch/mips/kernel/setup.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 563188ac6fa2..c3ca55128926 100644

v2: Correctly compare that usermem is not null.
v3: Added/changed position of changelog and fixed sender address.
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -371,6 +371,8 @@ static unsigned long __init bootmap_bytes(unsigned long 
pages)
 	return ALIGN(bytes, sizeof(long));
 }
 
+static int usermem __initdata;
+
 static void __init bootmem_init(void)
 {
 	unsigned long reserved_end;
@@ -444,7 +446,7 @@ static void __init bootmem_init(void)
 	/*
 	 * Reserve any memory between the start of RAM and PHYS_OFFSET
 	 */
-	if (ramstart > PHYS_OFFSET)
+	if (usermem && ramstart > PHYS_OFFSET)
 		add_memory_region(PHYS_OFFSET, ramstart - PHYS_OFFSET,
 				  BOOT_MEM_RESERVED);
 
@@ -654,8 +656,6 @@ static void __init bootmem_init(void)
  * initialization hook for anything else was introduced.
  */
 
-static int usermem __initdata;
-
 static int __init early_parse_mem(char *p)
 {
 	phys_addr_t start, size;

Re: [PATCH v3] MIPS: Fix memory reservation in bootmem_init for certain non-usermem setups

[Mathieu Malaterre]

On Mon, Aug 20, 2018 at 1:10 PM Tobias Wolf <dev-NTEO@vplace.de> wrote:
>
> Commit 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling") introduced a new
> issue for rt288x where "PHYS_OFFSET" is 0x0 but the calculated "ramstart" is
> not. As the prerequisite of custom memory map has been removed, this results
> in the full memory range of 0x0 - 0x8000000 to be marked as reserved for this
> platform.
>
> This patch adds the originally intended prerequisite again.
>
> Signed-off-by: Tobias Wolf <dev-NTEO@vplace.de>

You are missing the Fixes: line

Ref:
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes

You could use 67a3ba25aa95 as an example.


> ---
>  arch/mips/kernel/setup.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index 563188ac6fa2..c3ca55128926 100644
>
> v2: Correctly compare that usermem is not null.
> v3: Added/changed position of changelog and fixed sender address.
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -371,6 +371,8 @@ static unsigned long __init bootmap_bytes(unsigned long
> pages)
>         return ALIGN(bytes, sizeof(long));
>  }
>
> +static int usermem __initdata;
> +
>  static void __init bootmem_init(void)
>  {
>         unsigned long reserved_end;
> @@ -444,7 +446,7 @@ static void __init bootmem_init(void)
>         /*
>          * Reserve any memory between the start of RAM and PHYS_OFFSET
>          */
> -       if (ramstart > PHYS_OFFSET)
> +       if (usermem && ramstart > PHYS_OFFSET)
>                 add_memory_region(PHYS_OFFSET, ramstart - PHYS_OFFSET,
>                                   BOOT_MEM_RESERVED);
>
> @@ -654,8 +656,6 @@ static void __init bootmem_init(void)
>   * initialization hook for anything else was introduced.
>   */
>
> -static int usermem __initdata;
> -
>  static int __init early_parse_mem(char *p)
>  {
>         phys_addr_t start, size;
>
>
>
>


-- 
Mathieu

Re: [PATCH v3] MIPS: Fix memory reservation in bootmem_init for certain non-usermem setups

[Greg KH]

On Mon, Aug 20, 2018 at 01:10:38PM +0200, Tobias Wolf wrote:
> Commit 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling") introduced a new
> issue for rt288x where "PHYS_OFFSET" is 0x0 but the calculated "ramstart" is
> not. As the prerequisite of custom memory map has been removed, this results
> in the full memory range of 0x0 - 0x8000000 to be marked as reserved for this
> platform.
> 
> This patch adds the originally intended prerequisite again.
> 
> Signed-off-by: Tobias Wolf <dev-NTEO@vplace.de>
> ---
>  arch/mips/kernel/setup.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>

Re: [PATCH v3] MIPS: Fix memory reservation in bootmem_init for certain non-usermem setups

[Paul Burton]

Hi Tobias,

On Mon, Aug 20, 2018 at 01:10:38PM +0200, Tobias Wolf wrote:
> Commit 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling") introduced a new
> issue for rt288x where "PHYS_OFFSET" is 0x0 but the calculated "ramstart" is
> not. As the prerequisite of custom memory map has been removed, this results
> in the full memory range of 0x0 - 0x8000000 to be marked as reserved for this
> platform.
> 
> This patch adds the originally intended prerequisite again.

Could you please give an example of a typical memory layout on your
platform, and what mem= arguments you're using? That would help a lot in
being able to understand what's going wrong with the existing code.

> Signed-off-by: Tobias Wolf <dev-NTEO@vplace.de>

You'd want to add at least a fixes tag here:

  Fixes: 67a3ba25aa95 ("MIPS: Fix incorrect mem=X@Y handling")

And ideally add the Cc: stable tag indicating the version the fix ought
to be backported to, something like:

  Cc: stable@vger.kernel.org # v4.16+

As an aside, if your system generally has a non-zero ramstart perhaps it
would be worth having it select MIPS_AUTO_PFN_OFFSET in Kconfig? (New in
the 4.19 merge window.) That would effectively adjust PHYS_OFFSET to
match ramstart, and not waste memory on struct page for the region below
ramstart.

Thanks,
    Paul