[PATCH v3] MIPS: fix incorrect mem=X@Y handling

[PATCH v3] MIPS: fix incorrect mem=X@Y handling

[Marcin Nowakowski]

Commit 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing") added a
fix to ensure that the memory range between PHYS_OFFSET and low memory
address specified by mem= cmdline argument is not later processed by
free_all_bootmem.  This change was incorrect for systems where the
commandline specifies more than 1 mem argument, as it will cause all
memory between PHYS_OFFSET and each of the memory offsets to be marked
as reserved, which results in parts of the RAM marked as reserved
(Creator CI20's u-boot has a default commandline argument 'mem=256M@0x0
mem=768M@0x30000000').

Change the behaviour to ensure that only the range between PHYS_OFFSET
and the lowest start address of the memories is marked as protected.

This change also ensures that the range is marked protected even if it's
only defined through the devicetree and not only via commandline
arguments.

Reported-by: Mathieu Malaterre <mathieu.malaterre@gmail.com>
Signed-off-by: Marcin Nowakowski <marcin.nowakowski@mips.com>
Fixes: 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing")
Cc: <stable@vger.kernel.org> # v4.11+
---
v3: Update stable version, code cleanup as suggested by James Hogan
v2: Use updated email adress, add tag for stable.
---
 arch/mips/kernel/setup.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 702c678de116..e4a1581ce822 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -375,6 +375,7 @@ static void __init bootmem_init(void)
 	unsigned long reserved_end;
 	unsigned long mapstart = ~0UL;
 	unsigned long bootmap_size;
+	phys_addr_t ramstart = (phys_addr_t)ULLONG_MAX;
 	bool bootmap_valid = false;
 	int i;
 
@@ -395,7 +396,8 @@ static void __init bootmem_init(void)
 	max_low_pfn = 0;
 
 	/*
-	 * Find the highest page frame number we have available.
+	 * Find the highest page frame number we have available
+	 * and the lowest used RAM address
 	 */
 	for (i = 0; i < boot_mem_map.nr_map; i++) {
 		unsigned long start, end;
@@ -407,6 +409,8 @@ static void __init bootmem_init(void)
 		end = PFN_DOWN(boot_mem_map.map[i].addr
 				+ boot_mem_map.map[i].size);
 
+		ramstart = min(ramstart, boot_mem_map.map[i].addr);
+
 #ifndef CONFIG_HIGHMEM
 		/*
 		 * Skip highmem here so we get an accurate max_low_pfn if low
@@ -436,6 +440,13 @@ static void __init bootmem_init(void)
 		mapstart = max(reserved_end, start);
 	}
 
+	/*
+	 * Reserve any memory between the start of RAM and PHYS_OFFSET
+	 */
+	if (ramstart > PHYS_OFFSET)
+		add_memory_region(PHYS_OFFSET, ramstart - PHYS_OFFSET,
+				  BOOT_MEM_RESERVED);
+
 	if (min_low_pfn >= max_low_pfn)
 		panic("Incorrect memory mapping !!!");
 	if (min_low_pfn > ARCH_PFN_OFFSET) {
@@ -664,9 +675,6 @@ static int __init early_parse_mem(char *p)
 
 	add_memory_region(start, size, BOOT_MEM_RAM);
 
-	if (start && start > PHYS_OFFSET)
-		add_memory_region(PHYS_OFFSET, start - PHYS_OFFSET,
-				BOOT_MEM_RESERVED);
 	return 0;
 }
 early_param("mem", early_parse_mem);
-- 
2.14.1

Re: [PATCH v3] MIPS: fix incorrect mem=X@Y handling

[Mathieu Malaterre]

On Thu, Feb 1, 2018 at 12:37 PM, Marcin Nowakowski
<marcin.nowakowski@mips.com> wrote:
> Commit 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing") added a
> fix to ensure that the memory range between PHYS_OFFSET and low memory
> address specified by mem= cmdline argument is not later processed by
> free_all_bootmem.  This change was incorrect for systems where the
> commandline specifies more than 1 mem argument, as it will cause all
> memory between PHYS_OFFSET and each of the memory offsets to be marked
> as reserved, which results in parts of the RAM marked as reserved
> (Creator CI20's u-boot has a default commandline argument 'mem=256M@0x0
> mem=768M@0x30000000').
>
> Change the behaviour to ensure that only the range between PHYS_OFFSET
> and the lowest start address of the memories is marked as protected.
>
> This change also ensures that the range is marked protected even if it's
> only defined through the devicetree and not only via commandline
> arguments.
>
> Reported-by: Mathieu Malaterre <mathieu.malaterre@gmail.com>
> Signed-off-by: Marcin Nowakowski <marcin.nowakowski@mips.com>
> Fixes: 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing")
> Cc: <stable@vger.kernel.org> # v4.11+
> ---
> v3: Update stable version, code cleanup as suggested by James Hogan
> v2: Use updated email adress, add tag for stable.
> ---
>  arch/mips/kernel/setup.c | 16 ++++++++++++----
>  1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> index 702c678de116..e4a1581ce822 100644
> --- a/arch/mips/kernel/setup.c
> +++ b/arch/mips/kernel/setup.c
> @@ -375,6 +375,7 @@ static void __init bootmem_init(void)
>         unsigned long reserved_end;
>         unsigned long mapstart = ~0UL;
>         unsigned long bootmap_size;
> +       phys_addr_t ramstart = (phys_addr_t)ULLONG_MAX;
>         bool bootmap_valid = false;
>         int i;
>
> @@ -395,7 +396,8 @@ static void __init bootmem_init(void)
>         max_low_pfn = 0;
>
>         /*
> -        * Find the highest page frame number we have available.
> +        * Find the highest page frame number we have available
> +        * and the lowest used RAM address
>          */
>         for (i = 0; i < boot_mem_map.nr_map; i++) {
>                 unsigned long start, end;
> @@ -407,6 +409,8 @@ static void __init bootmem_init(void)
>                 end = PFN_DOWN(boot_mem_map.map[i].addr
>                                 + boot_mem_map.map[i].size);
>
> +               ramstart = min(ramstart, boot_mem_map.map[i].addr);
> +
>  #ifndef CONFIG_HIGHMEM
>                 /*
>                  * Skip highmem here so we get an accurate max_low_pfn if low
> @@ -436,6 +440,13 @@ static void __init bootmem_init(void)
>                 mapstart = max(reserved_end, start);
>         }
>
> +       /*
> +        * Reserve any memory between the start of RAM and PHYS_OFFSET
> +        */
> +       if (ramstart > PHYS_OFFSET)
> +               add_memory_region(PHYS_OFFSET, ramstart - PHYS_OFFSET,
> +                                 BOOT_MEM_RESERVED);
> +
>         if (min_low_pfn >= max_low_pfn)
>                 panic("Incorrect memory mapping !!!");
>         if (min_low_pfn > ARCH_PFN_OFFSET) {
> @@ -664,9 +675,6 @@ static int __init early_parse_mem(char *p)
>
>         add_memory_region(start, size, BOOT_MEM_RAM);
>
> -       if (start && start > PHYS_OFFSET)
> -               add_memory_region(PHYS_OFFSET, start - PHYS_OFFSET,
> -                               BOOT_MEM_RESERVED);
>         return 0;
>  }
>  early_param("mem", early_parse_mem);
> --
> 2.14.1
>

Looks good to me:

$ cat /proc/cpuinfo
system type : JZ4780
machine : Creator CI20
processor : 0
cpu model : Ingenic JZRISC V4.15  FPU V0.0
BogoMIPS : 956.00
wait instruction : yes
microsecond timers : no
tlb_entries : 32
extra interrupt vector : yes
hardware watchpoint : yes, count: 1, address/irw mask: [0x0fff]
isa : mips1 mips2 mips32r1 mips32r2
ASEs implemented :
shadow register sets : 1
kscratch registers : 0
package : 0
core : 0
VCED exceptions : not available
VCEI exceptions : not available
$ uname -a
Linux ci20 4.15.0+ #323 PREEMPT Thu Feb 1 13:08:11 CET 2018 mips GNU/Linux

Tested-by: Mathieu Malaterre <malat@debian.org>

Thanks

Re: [PATCH v3] MIPS: fix incorrect mem=X@Y handling

[Mathieu Malaterre]

James,

On Thu, Feb 1, 2018 at 1:12 PM, Mathieu Malaterre <malat@debian.org> wrote:
> On Thu, Feb 1, 2018 at 12:37 PM, Marcin Nowakowski
> <marcin.nowakowski@mips.com> wrote:
>> Commit 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing") added a
>> fix to ensure that the memory range between PHYS_OFFSET and low memory
>> address specified by mem= cmdline argument is not later processed by
>> free_all_bootmem.  This change was incorrect for systems where the
>> commandline specifies more than 1 mem argument, as it will cause all
>> memory between PHYS_OFFSET and each of the memory offsets to be marked
>> as reserved, which results in parts of the RAM marked as reserved
>> (Creator CI20's u-boot has a default commandline argument 'mem=256M@0x0
>> mem=768M@0x30000000').
>>
>> Change the behaviour to ensure that only the range between PHYS_OFFSET
>> and the lowest start address of the memories is marked as protected.
>>
>> This change also ensures that the range is marked protected even if it's
>> only defined through the devicetree and not only via commandline
>> arguments.
>>
>> Reported-by: Mathieu Malaterre <mathieu.malaterre@gmail.com>
>> Signed-off-by: Marcin Nowakowski <marcin.nowakowski@mips.com>
>> Fixes: 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing")
>> Cc: <stable@vger.kernel.org> # v4.11+
>> ---
>> v3: Update stable version, code cleanup as suggested by James Hogan
>> v2: Use updated email adress, add tag for stable.
>> ---
>>  arch/mips/kernel/setup.c | 16 ++++++++++++----
>>  1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
>> index 702c678de116..e4a1581ce822 100644
>> --- a/arch/mips/kernel/setup.c
>> +++ b/arch/mips/kernel/setup.c
>> @@ -375,6 +375,7 @@ static void __init bootmem_init(void)
>>         unsigned long reserved_end;
>>         unsigned long mapstart = ~0UL;
>>         unsigned long bootmap_size;
>> +       phys_addr_t ramstart = (phys_addr_t)ULLONG_MAX;
>>         bool bootmap_valid = false;
>>         int i;
>>
>> @@ -395,7 +396,8 @@ static void __init bootmem_init(void)
>>         max_low_pfn = 0;
>>
>>         /*
>> -        * Find the highest page frame number we have available.
>> +        * Find the highest page frame number we have available
>> +        * and the lowest used RAM address
>>          */
>>         for (i = 0; i < boot_mem_map.nr_map; i++) {
>>                 unsigned long start, end;
>> @@ -407,6 +409,8 @@ static void __init bootmem_init(void)
>>                 end = PFN_DOWN(boot_mem_map.map[i].addr
>>                                 + boot_mem_map.map[i].size);
>>
>> +               ramstart = min(ramstart, boot_mem_map.map[i].addr);
>> +
>>  #ifndef CONFIG_HIGHMEM
>>                 /*
>>                  * Skip highmem here so we get an accurate max_low_pfn if low
>> @@ -436,6 +440,13 @@ static void __init bootmem_init(void)
>>                 mapstart = max(reserved_end, start);
>>         }
>>
>> +       /*
>> +        * Reserve any memory between the start of RAM and PHYS_OFFSET
>> +        */
>> +       if (ramstart > PHYS_OFFSET)
>> +               add_memory_region(PHYS_OFFSET, ramstart - PHYS_OFFSET,
>> +                                 BOOT_MEM_RESERVED);
>> +
>>         if (min_low_pfn >= max_low_pfn)
>>                 panic("Incorrect memory mapping !!!");
>>         if (min_low_pfn > ARCH_PFN_OFFSET) {
>> @@ -664,9 +675,6 @@ static int __init early_parse_mem(char *p)
>>
>>         add_memory_region(start, size, BOOT_MEM_RAM);
>>
>> -       if (start && start > PHYS_OFFSET)
>> -               add_memory_region(PHYS_OFFSET, start - PHYS_OFFSET,
>> -                               BOOT_MEM_RESERVED);
>>         return 0;
>>  }
>>  early_param("mem", early_parse_mem);
>> --
>> 2.14.1
>>
>
> Looks good to me:
>
> $ cat /proc/cpuinfo
> system type : JZ4780
> machine : Creator CI20
> processor : 0
> cpu model : Ingenic JZRISC V4.15  FPU V0.0
> BogoMIPS : 956.00
> wait instruction : yes
> microsecond timers : no
> tlb_entries : 32
> extra interrupt vector : yes
> hardware watchpoint : yes, count: 1, address/irw mask: [0x0fff]
> isa : mips1 mips2 mips32r1 mips32r2
> ASEs implemented :
> shadow register sets : 1
> kscratch registers : 0
> package : 0
> core : 0
> VCED exceptions : not available
> VCEI exceptions : not available
> $ uname -a
> Linux ci20 4.15.0+ #323 PREEMPT Thu Feb 1 13:08:11 CET 2018 mips GNU/Linux
>
> Tested-by: Mathieu Malaterre <malat@debian.org>
>
> Thanks

Could you please review the patch v3 ?

Thanks,

Re: [PATCH v3] MIPS: fix incorrect mem=X@Y handling

[James Hogan]

[-- Attachment #1: Type: text/plain, Size: 5612 bytes --]

On Tue, Feb 13, 2018 at 01:14:29PM +0100, Mathieu Malaterre wrote:
> On Thu, Feb 1, 2018 at 1:12 PM, Mathieu Malaterre <malat@debian.org> wrote:
> > On Thu, Feb 1, 2018 at 12:37 PM, Marcin Nowakowski
> > <marcin.nowakowski@mips.com> wrote:
> >> Commit 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing") added a
> >> fix to ensure that the memory range between PHYS_OFFSET and low memory
> >> address specified by mem= cmdline argument is not later processed by
> >> free_all_bootmem.  This change was incorrect for systems where the
> >> commandline specifies more than 1 mem argument, as it will cause all
> >> memory between PHYS_OFFSET and each of the memory offsets to be marked
> >> as reserved, which results in parts of the RAM marked as reserved
> >> (Creator CI20's u-boot has a default commandline argument 'mem=256M@0x0
> >> mem=768M@0x30000000').
> >>
> >> Change the behaviour to ensure that only the range between PHYS_OFFSET
> >> and the lowest start address of the memories is marked as protected.
> >>
> >> This change also ensures that the range is marked protected even if it's
> >> only defined through the devicetree and not only via commandline
> >> arguments.
> >>
> >> Reported-by: Mathieu Malaterre <mathieu.malaterre@gmail.com>
> >> Signed-off-by: Marcin Nowakowski <marcin.nowakowski@mips.com>
> >> Fixes: 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing")
> >> Cc: <stable@vger.kernel.org> # v4.11+
> >> ---
> >> v3: Update stable version, code cleanup as suggested by James Hogan
> >> v2: Use updated email adress, add tag for stable.
> >> ---
> >>  arch/mips/kernel/setup.c | 16 ++++++++++++----
> >>  1 file changed, 12 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
> >> index 702c678de116..e4a1581ce822 100644
> >> --- a/arch/mips/kernel/setup.c
> >> +++ b/arch/mips/kernel/setup.c
> >> @@ -375,6 +375,7 @@ static void __init bootmem_init(void)
> >>         unsigned long reserved_end;
> >>         unsigned long mapstart = ~0UL;
> >>         unsigned long bootmap_size;
> >> +       phys_addr_t ramstart = (phys_addr_t)ULLONG_MAX;
> >>         bool bootmap_valid = false;
> >>         int i;
> >>
> >> @@ -395,7 +396,8 @@ static void __init bootmem_init(void)
> >>         max_low_pfn = 0;
> >>
> >>         /*
> >> -        * Find the highest page frame number we have available.
> >> +        * Find the highest page frame number we have available
> >> +        * and the lowest used RAM address
> >>          */
> >>         for (i = 0; i < boot_mem_map.nr_map; i++) {
> >>                 unsigned long start, end;
> >> @@ -407,6 +409,8 @@ static void __init bootmem_init(void)
> >>                 end = PFN_DOWN(boot_mem_map.map[i].addr
> >>                                 + boot_mem_map.map[i].size);
> >>
> >> +               ramstart = min(ramstart, boot_mem_map.map[i].addr);
> >> +
> >>  #ifndef CONFIG_HIGHMEM
> >>                 /*
> >>                  * Skip highmem here so we get an accurate max_low_pfn if low
> >> @@ -436,6 +440,13 @@ static void __init bootmem_init(void)
> >>                 mapstart = max(reserved_end, start);
> >>         }
> >>
> >> +       /*
> >> +        * Reserve any memory between the start of RAM and PHYS_OFFSET
> >> +        */
> >> +       if (ramstart > PHYS_OFFSET)
> >> +               add_memory_region(PHYS_OFFSET, ramstart - PHYS_OFFSET,
> >> +                                 BOOT_MEM_RESERVED);
> >> +
> >>         if (min_low_pfn >= max_low_pfn)
> >>                 panic("Incorrect memory mapping !!!");
> >>         if (min_low_pfn > ARCH_PFN_OFFSET) {
> >> @@ -664,9 +675,6 @@ static int __init early_parse_mem(char *p)
> >>
> >>         add_memory_region(start, size, BOOT_MEM_RAM);
> >>
> >> -       if (start && start > PHYS_OFFSET)
> >> -               add_memory_region(PHYS_OFFSET, start - PHYS_OFFSET,
> >> -                               BOOT_MEM_RESERVED);
> >>         return 0;
> >>  }
> >>  early_param("mem", early_parse_mem);
> >> --
> >> 2.14.1
> >>
> >
> > Looks good to me:
> >
> > $ cat /proc/cpuinfo
> > system type : JZ4780
> > machine : Creator CI20
> > processor : 0
> > cpu model : Ingenic JZRISC V4.15  FPU V0.0
> > BogoMIPS : 956.00
> > wait instruction : yes
> > microsecond timers : no
> > tlb_entries : 32
> > extra interrupt vector : yes
> > hardware watchpoint : yes, count: 1, address/irw mask: [0x0fff]
> > isa : mips1 mips2 mips32r1 mips32r2
> > ASEs implemented :
> > shadow register sets : 1
> > kscratch registers : 0
> > package : 0
> > core : 0
> > VCED exceptions : not available
> > VCEI exceptions : not available
> > $ uname -a
> > Linux ci20 4.15.0+ #323 PREEMPT Thu Feb 1 13:08:11 CET 2018 mips GNU/Linux
> >
> > Tested-by: Mathieu Malaterre <malat@debian.org>
> >
> > Thanks
> 
> Could you please review the patch v3 ?

Yes, looks good to me, and Ralf had applied to his test branch so I
presume he's happy with it too. I'll apply for 4.16.

Commit 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing") which
this fixes was evidently requested to be backported to stable (unsure
who by) and added to the 4.9 queue, but then this arose and it was
removed until this fix is merged (see
https://patchwork.linux-mips.org/patch/17268/).

Anybody know how far back before 4.11 both of these patches should be
applied to stable? If not I'll just leave it at 4.11 and if its
important before then for kexec or whatever they can be requested again.

Thanks
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3] MIPS: fix incorrect mem=X@Y handling

[Mathieu Malaterre]

James,

On Tue, Feb 13, 2018 at 2:38 PM, James Hogan <jhogan@kernel.org> wrote:
> On Tue, Feb 13, 2018 at 01:14:29PM +0100, Mathieu Malaterre wrote:
>> On Thu, Feb 1, 2018 at 1:12 PM, Mathieu Malaterre <malat@debian.org> wrote:
>> > On Thu, Feb 1, 2018 at 12:37 PM, Marcin Nowakowski
>> > <marcin.nowakowski@mips.com> wrote:
>> >> Commit 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing") added a
>> >> fix to ensure that the memory range between PHYS_OFFSET and low memory
>> >> address specified by mem= cmdline argument is not later processed by
>> >> free_all_bootmem.  This change was incorrect for systems where the
>> >> commandline specifies more than 1 mem argument, as it will cause all
>> >> memory between PHYS_OFFSET and each of the memory offsets to be marked
>> >> as reserved, which results in parts of the RAM marked as reserved
>> >> (Creator CI20's u-boot has a default commandline argument 'mem=256M@0x0
>> >> mem=768M@0x30000000').
>> >>
>> >> Change the behaviour to ensure that only the range between PHYS_OFFSET
>> >> and the lowest start address of the memories is marked as protected.
>> >>
>> >> This change also ensures that the range is marked protected even if it's
>> >> only defined through the devicetree and not only via commandline
>> >> arguments.
>> >>
>> >> Reported-by: Mathieu Malaterre <mathieu.malaterre@gmail.com>
>> >> Signed-off-by: Marcin Nowakowski <marcin.nowakowski@mips.com>
>> >> Fixes: 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing")
>> >> Cc: <stable@vger.kernel.org> # v4.11+
>> >> ---
>> >> v3: Update stable version, code cleanup as suggested by James Hogan
>> >> v2: Use updated email adress, add tag for stable.
>> >> ---
>> >>  arch/mips/kernel/setup.c | 16 ++++++++++++----
>> >>  1 file changed, 12 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
>> >> index 702c678de116..e4a1581ce822 100644
>> >> --- a/arch/mips/kernel/setup.c
>> >> +++ b/arch/mips/kernel/setup.c
>> >> @@ -375,6 +375,7 @@ static void __init bootmem_init(void)
>> >>         unsigned long reserved_end;
>> >>         unsigned long mapstart = ~0UL;
>> >>         unsigned long bootmap_size;
>> >> +       phys_addr_t ramstart = (phys_addr_t)ULLONG_MAX;
>> >>         bool bootmap_valid = false;
>> >>         int i;
>> >>
>> >> @@ -395,7 +396,8 @@ static void __init bootmem_init(void)
>> >>         max_low_pfn = 0;
>> >>
>> >>         /*
>> >> -        * Find the highest page frame number we have available.
>> >> +        * Find the highest page frame number we have available
>> >> +        * and the lowest used RAM address
>> >>          */
>> >>         for (i = 0; i < boot_mem_map.nr_map; i++) {
>> >>                 unsigned long start, end;
>> >> @@ -407,6 +409,8 @@ static void __init bootmem_init(void)
>> >>                 end = PFN_DOWN(boot_mem_map.map[i].addr
>> >>                                 + boot_mem_map.map[i].size);
>> >>
>> >> +               ramstart = min(ramstart, boot_mem_map.map[i].addr);
>> >> +
>> >>  #ifndef CONFIG_HIGHMEM
>> >>                 /*
>> >>                  * Skip highmem here so we get an accurate max_low_pfn if low
>> >> @@ -436,6 +440,13 @@ static void __init bootmem_init(void)
>> >>                 mapstart = max(reserved_end, start);
>> >>         }
>> >>
>> >> +       /*
>> >> +        * Reserve any memory between the start of RAM and PHYS_OFFSET
>> >> +        */
>> >> +       if (ramstart > PHYS_OFFSET)
>> >> +               add_memory_region(PHYS_OFFSET, ramstart - PHYS_OFFSET,
>> >> +                                 BOOT_MEM_RESERVED);
>> >> +
>> >>         if (min_low_pfn >= max_low_pfn)
>> >>                 panic("Incorrect memory mapping !!!");
>> >>         if (min_low_pfn > ARCH_PFN_OFFSET) {
>> >> @@ -664,9 +675,6 @@ static int __init early_parse_mem(char *p)
>> >>
>> >>         add_memory_region(start, size, BOOT_MEM_RAM);
>> >>
>> >> -       if (start && start > PHYS_OFFSET)
>> >> -               add_memory_region(PHYS_OFFSET, start - PHYS_OFFSET,
>> >> -                               BOOT_MEM_RESERVED);
>> >>         return 0;
>> >>  }
>> >>  early_param("mem", early_parse_mem);
>> >> --
>> >> 2.14.1
>> >>
>> >
>> > Looks good to me:
>> >
>> > $ cat /proc/cpuinfo
>> > system type : JZ4780
>> > machine : Creator CI20
>> > processor : 0
>> > cpu model : Ingenic JZRISC V4.15  FPU V0.0
>> > BogoMIPS : 956.00
>> > wait instruction : yes
>> > microsecond timers : no
>> > tlb_entries : 32
>> > extra interrupt vector : yes
>> > hardware watchpoint : yes, count: 1, address/irw mask: [0x0fff]
>> > isa : mips1 mips2 mips32r1 mips32r2
>> > ASEs implemented :
>> > shadow register sets : 1
>> > kscratch registers : 0
>> > package : 0
>> > core : 0
>> > VCED exceptions : not available
>> > VCEI exceptions : not available
>> > $ uname -a
>> > Linux ci20 4.15.0+ #323 PREEMPT Thu Feb 1 13:08:11 CET 2018 mips GNU/Linux
>> >
>> > Tested-by: Mathieu Malaterre <malat@debian.org>
>> >
>> > Thanks
>>
>> Could you please review the patch v3 ?
>
> Yes, looks good to me, and Ralf had applied to his test branch so I
> presume he's happy with it too. I'll apply for 4.16.

Hum, just to be sure I understand the process. Which branch are you
talking about:

https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git

> Commit 73fbc1eba7ff ("MIPS: fix mem=X@Y commandline processing") which
> this fixes was evidently requested to be backported to stable (unsure
> who by) and added to the 4.9 queue, but then this arose and it was
> removed until this fix is merged (see
> https://patchwork.linux-mips.org/patch/17268/).
>
> Anybody know how far back before 4.11 both of these patches should be
> applied to stable? If not I'll just leave it at 4.11 and if its
> important before then for kexec or whatever they can be requested again.

Re: [PATCH v3] MIPS: fix incorrect mem=X@Y handling

[James Hogan]

[-- Attachment #1: Type: text/plain, Size: 975 bytes --]

On Tue, Feb 13, 2018 at 03:03:24PM +0100, Mathieu Malaterre wrote:
> James,
> 
> On Tue, Feb 13, 2018 at 2:38 PM, James Hogan <jhogan@kernel.org> wrote:
> > On Tue, Feb 13, 2018 at 01:14:29PM +0100, Mathieu Malaterre wrote:
> >> Could you please review the patch v3 ?
> >
> > Yes, looks good to me, and Ralf had applied to his test branch so I
> > presume he's happy with it too. I'll apply for 4.16.
> 
> Hum, just to be sure I understand the process. Which branch are you
> talking about:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git

I was referring to upstream-sfr.git branch=mips-next-test
https://git.linux-mips.org/cgit/ralf/upstream-sfr.git/log/?h=mips-next-test

(The mips-next branch there is what Ralf puts into linux-next)

I've applied the patch to my mips-fixes branch here:
git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips.git

Sorry it seems a bit haphazard with multiple trees in use.

Cheers
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH v3] MIPS: fix incorrect mem=X@Y handling

[Mathieu Malaterre]

Hi,

On Tue, Feb 13, 2018 at 3:32 PM, James Hogan <jhogan@kernel.org> wrote:
> On Tue, Feb 13, 2018 at 03:03:24PM +0100, Mathieu Malaterre wrote:
>> James,
>>
>> On Tue, Feb 13, 2018 at 2:38 PM, James Hogan <jhogan@kernel.org> wrote:
>> > On Tue, Feb 13, 2018 at 01:14:29PM +0100, Mathieu Malaterre wrote:
>> >> Could you please review the patch v3 ?
>> >
>> > Yes, looks good to me, and Ralf had applied to his test branch so I
>> > presume he's happy with it too. I'll apply for 4.16.
>>
>> Hum, just to be sure I understand the process. Which branch are you
>> talking about:
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/ralf/linux.git
>
> I was referring to upstream-sfr.git branch=mips-next-test
> https://git.linux-mips.org/cgit/ralf/upstream-sfr.git/log/?h=mips-next-test
>
> (The mips-next branch there is what Ralf puts into linux-next)
>
> I've applied the patch to my mips-fixes branch here:
> git://git.kernel.org/pub/scm/linux/kernel/git/jhogan/mips.git
>
> Sorry it seems a bit haphazard with multiple trees in use.

I see it now, sorry for the noise. I was not looking at the right location.

Anyway if that answer earlier question 4.11 should be correct, since I
asked Greg to not backport the earlier patch:

https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1505915.html