[PATCH v2 0/5] mips: Post-bootmem-memblock transition fixes

[PATCH v2 0/5] mips: Post-bootmem-memblock transition fixes

[Serge Semin]

First attempt of making the MIPS subsystem utilizing the memblock early memory
allocator was done by me a few years ago. I created a patchset with
21 patches [1]. It turned out to be too complicated and I decided to resend a
reworked patchset with smaller number of changes [2]. I did this and after a
small review process a v2 patchset was also posted. Then my spare
time was over and I couldn't proceed with the patchset support and
resubmission.

In a year Mike Rapoport took charge in this task and posted a small
patch which essentially did the bootmem allocator removal from MIPS
subsystem [3]. A single small patch did in general the whole thing my huge
patchsetes were intended for in the first place (though it lacked a few fixes).
Mike even went further and completely removed the bootmem allocator from
kernel code, so all the subsystems would need to use the only one early
memory allocator. This significantly simplified the platforms code as well
as removed a deprecated subsystem with duplicated functionality. Million
credits to Mike for this.

Getting back to the MIPS subsystem and it memblock allocator usage. Even
though the patch suggested by Mike [3] fixed most of the problems caused
by enabling the memblock allocator usage, some of them have been left
uncovered by it. First of all the PFNs calculation algorithm hasn't been
fully refactored. A reserved memory declaration loop has been left
untouched though it was clearly over-complicated for the new initialization
procedure. Secondly the MIPS platform code reserved the whole space below
kernel start address, which doesn't seem right since kernel can be
located much higher than memory space really starts. Thirdly CMA if it
is enabled reserves memory regions by means of memblock in the first place.
So the bootmem-init code doesn't need to do it again. Fifthly at early
platform initialization stage non of bootmem-left methods can be called
since there is no memory pages mapping at that moment, so __nosave* region
must be reserved by means of memblock allocator. Finally aside from memblock
allocator introduction my early patchsets included a series of useful
alterations like "nomap" property implementation for "reserved-memory"
dts-nodes, memblock_dump_all() method call after early memory allocator
initialization for debugging, low-memory test procedure, kernel memory
mapping printout at boot-time, and so on. So all of these fixes and
alterations are introduced in this new patchset. Please review. Hope
this time I'll be more responsive and finish this series up until it
is merged.

[1] https://lkml.org/lkml/2016/12/18/195
[2] https://lkml.org/lkml/2018/1/17/1201
[3] https://lkml.org/lkml/2018/9/10/302

NOTE I added a few "Reviewed-by:  Matt Redfearn <matt.redfearn@mips.com>"
since some patches of this series have been picked up from my earlier
patchsets, which Matt's already reviewed. I didn't add the tag for patches,
which were either new or partially ported.

Changelog v2
- Discard forcible selection of OF_RESERVED_MEM config
- Reword 'mips: Dump memblock regions for debugging' commit message since
  memblock debug printout is activated by memblock=debug kernel parameter
- Rebase onto mips-next
- Keep patches from 8 to 12 as the rest of them have already been merged


Serge Semin (5):
  mips: Dump memblock regions for debugging
  mips: Perform early low memory test
  mips: Print the kernel virtual mem layout on debugging
  mips: Make sure dt memory regions are valid
  mips: Manually call fdt_init_reserved_mem() method

 arch/mips/kernel/prom.c  | 14 +++++++++++-
 arch/mips/kernel/setup.c |  7 ++++++
 arch/mips/mm/init.c      | 49 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 69 insertions(+), 1 deletion(-)

-- 
2.21.0

[PATCH v2 1/5] mips: Dump memblock regions for debugging

[Serge Semin]

It is useful to have the whole memblock memory space printed to console
when basic memlock initializations are done. It can be performed by
ready-to-use method memblock_dump_all(), which prints the available
and reserved memory spaces if memblock=debug kernel parameter is
specified. Lets call it at the very end of arch_mem_init() function,
when all memblock memory and reserved regions are defined, but before
any serious allocation is performed.

Signed-off-by: Serge Semin <fancer.lancer@gmail.com>

---
Changelog v2
- Reword commit message since memblock debug printout is activated by
  memblock=debug kernel parameter
---
 arch/mips/kernel/setup.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index 2a1b2e7a1bc9..ca493fdf69b0 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -824,6 +824,8 @@ static void __init arch_mem_init(char **cmdline_p)
 	/* Reserve for hibernation. */
 	memblock_reserve(__pa_symbol(&__nosave_begin),
 		__pa_symbol(&__nosave_end) - __pa_symbol(&__nosave_begin));
+
+	memblock_dump_all();
 }
 
 static void __init resource_init(void)
-- 
2.21.0

Re: [PATCH v2 1/5] mips: Dump memblock regions for debugging

[Paul Burton]

Hello,

Serge Semin wrote:
> It is useful to have the whole memblock memory space printed to console
> when basic memlock initializations are done. It can be performed by
> ready-to-use method memblock_dump_all(), which prints the available
> and reserved memory spaces if memblock=debug kernel parameter is
> specified. Lets call it at the very end of arch_mem_init() function,
> when all memblock memory and reserved regions are defined, but before
> any serious allocation is performed.
> 
> Signed-off-by: Serge Semin <fancer.lancer@gmail.com>

Applied to mips-next.

Thanks,
    Paul

[ This message was auto-generated; if you believe anything is incorrect
  then please email paul.burton@mips.com to report it. ]

[PATCH v2 2/5] mips: Perform early low memory test

[Serge Semin]

memblock subsystem provides a method to optionally test the passed
memory region in case if it was requested via special kernel boot
argument. Lets add the function at the bottom of the arch_mem_init()
method. Testing at this point in the boot sequence should be safe since all
critical areas are now reserved and a minimum of allocations have been
done.

Reviewed-by: Matt Redfearn <matt.redfearn@mips.com>
Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
---
 arch/mips/kernel/setup.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index ca493fdf69b0..fbd216b4e929 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -826,6 +826,8 @@ static void __init arch_mem_init(char **cmdline_p)
 		__pa_symbol(&__nosave_end) - __pa_symbol(&__nosave_begin));
 
 	memblock_dump_all();
+
+	early_memtest(PFN_PHYS(min_low_pfn), PFN_PHYS(max_low_pfn));
 }
 
 static void __init resource_init(void)
-- 
2.21.0

Re: [PATCH v2 2/5] mips: Perform early low memory test

[Paul Burton]

Hello,

Serge Semin wrote:
> memblock subsystem provides a method to optionally test the passed
> memory region in case if it was requested via special kernel boot
> argument. Lets add the function at the bottom of the arch_mem_init()
> method. Testing at this point in the boot sequence should be safe since all
> critical areas are now reserved and a minimum of allocations have been
> done.
> 
> Reviewed-by: Matt Redfearn <matt.redfearn@mips.com>
> Signed-off-by: Serge Semin <fancer.lancer@gmail.com>

Applied to mips-next.

Thanks,
    Paul

[ This message was auto-generated; if you believe anything is incorrect
  then please email paul.burton@mips.com to report it. ]

[PATCH v2 3/5] mips: Print the kernel virtual mem layout on debugging

[Serge Semin]

It is useful at least for debugging to have the kernel virtual
memory layout printed at boot time so to have the full information
about the booted kernel. Make the printing optional and available
only when DEBUG_KERNEL config is enabled so not to leak a sensitive
kernel information.

Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
---
 arch/mips/mm/init.c | 49 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 49 insertions(+)

diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c
index bbb196ad5f26..c338bbd03b2a 100644
--- a/arch/mips/mm/init.c
+++ b/arch/mips/mm/init.c
@@ -31,6 +31,7 @@
 #include <linux/gfp.h>
 #include <linux/kcore.h>
 #include <linux/initrd.h>
+#include <linux/sizes.h>
 
 #include <asm/bootinfo.h>
 #include <asm/cachectl.h>
@@ -56,6 +57,53 @@ unsigned long empty_zero_page, zero_page_mask;
 EXPORT_SYMBOL_GPL(empty_zero_page);
 EXPORT_SYMBOL(zero_page_mask);
 
+/*
+ * Print out the kernel virtual memory layout
+ */
+#define MLK(b, t) (void *)b, (void *)t, ((t) - (b)) >> 10
+#define MLM(b, t) (void *)b, (void *)t, ((t) - (b)) >> 20
+#define MLK_ROUNDUP(b, t) (void *)b, (void *)t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
+static void __init mem_print_kmap_info(void)
+{
+#ifdef CONFIG_DEBUG_KERNEL
+	pr_notice("Kernel virtual memory layout:\n"
+		  "    lowmem  : 0x%px - 0x%px  (%4ld MB)\n"
+		  "      .text : 0x%px - 0x%px  (%4td kB)\n"
+		  "      .data : 0x%px - 0x%px  (%4td kB)\n"
+		  "      .init : 0x%px - 0x%px  (%4td kB)\n"
+		  "      .bss  : 0x%px - 0x%px  (%4td kB)\n"
+		  "    vmalloc : 0x%px - 0x%px  (%4ld MB)\n"
+#ifdef CONFIG_HIGHMEM
+		  "    pkmap   : 0x%px - 0x%px  (%4ld MB)\n"
+#endif
+		  "    fixmap  : 0x%px - 0x%px  (%4ld kB)\n",
+		  MLM(PAGE_OFFSET, (unsigned long)high_memory),
+		  MLK_ROUNDUP(_text, _etext),
+		  MLK_ROUNDUP(_sdata, _edata),
+		  MLK_ROUNDUP(__init_begin, __init_end),
+		  MLK_ROUNDUP(__bss_start, __bss_stop),
+		  MLM(VMALLOC_START, VMALLOC_END),
+#ifdef CONFIG_HIGHMEM
+		  MLM(PKMAP_BASE, (PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE)),
+#endif
+		  MLK(FIXADDR_START, FIXADDR_TOP));
+
+	/* Check some fundamental inconsistencies. May add something else? */
+#ifdef CONFIG_HIGHMEM
+	BUILD_BUG_ON(VMALLOC_END < PAGE_OFFSET);
+	BUG_ON(VMALLOC_END < (unsigned long)high_memory);
+	BUILD_BUG_ON((PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE) < PAGE_OFFSET);
+	BUG_ON((PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE) <
+		(unsigned long)high_memory);
+#endif
+	BUILD_BUG_ON(FIXADDR_TOP < PAGE_OFFSET);
+	BUG_ON(FIXADDR_TOP < (unsigned long)high_memory);
+#endif /* CONFIG_DEBUG_KERNEL */
+}
+#undef MLK
+#undef MLM
+#undef MLK_ROUNDUP
+
 /*
  * Not static inline because used by IP27 special magic initialization code
  */
@@ -479,6 +527,7 @@ void __init mem_init(void)
 	setup_zero_pages();	/* Setup zeroed pages.  */
 	mem_init_free_highmem();
 	mem_init_print_info(NULL);
+	mem_print_kmap_info();
 
 #ifdef CONFIG_64BIT
 	if ((unsigned long) &_text > (unsigned long) CKSEG0)
-- 
2.21.0

Re: [PATCH v2 3/5] mips: Print the kernel virtual mem layout on debugging

[Paul Burton]

Hi Serge,

On Fri, May 03, 2019 at 08:50:39PM +0300, Serge Semin wrote:
> It is useful at least for debugging to have the kernel virtual
> memory layout printed at boot time so to have the full information
> about the booted kernel. Make the printing optional and available
> only when DEBUG_KERNEL config is enabled so not to leak a sensitive
> kernel information.
> 
> Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> ---
>  arch/mips/mm/init.c | 49 +++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 49 insertions(+)

FYI the rest of the series is in mips-next, but I left this one out
because it gives me compile errors for 64r6el_defconfig:

In file included from ./include/linux/printk.h:7,
                 from ./include/linux/kernel.h:15,
                 from ./include/asm-generic/bug.h:18,
                 from ./arch/mips/include/asm/bug.h:42,
                 from ./include/linux/bug.h:5,
                 from arch/mips/mm/init.c:11:
arch/mips/mm/init.c: In function ‘mem_print_kmap_info’:
./include/linux/kern_levels.h:5:18: error: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘long long unsigned int’ [-Werror=format=]
 #define KERN_SOH "\001"  /* ASCII Start Of Header */
                  ^~~~~~
./include/linux/kern_levels.h:13:21: note: in expansion of macro ‘KERN_SOH’
 #define KERN_NOTICE KERN_SOH "5" /* normal but significant condition */
                     ^~~~~~~~
./include/linux/printk.h:307:9: note: in expansion of macro ‘KERN_NOTICE’
  printk(KERN_NOTICE pr_fmt(fmt), ##__VA_ARGS__)
         ^~~~~~~~~~~
arch/mips/mm/init.c:69:2: note: in expansion of macro ‘pr_notice’
  pr_notice("Kernel virtual memory layout:\n"
  ^~~~~~~~~
arch/mips/mm/init.c:70:39: note: format string is defined here
     "    lowmem  : 0x%px - 0x%px  (%4ld MB)\n"
                                    ~~~^
                                    %4lld
In file included from ./arch/mips/include/asm/bug.h:5,
                 from ./include/linux/bug.h:5,
                 from arch/mips/mm/init.c:11:
In function ‘mem_print_kmap_info’,
    inlined from ‘mem_init’ at arch/mips/mm/init.c:530:2:
./include/linux/compiler.h:344:38: error: call to ‘__compiletime_assert_99’ declared with attribute error: BUILD_BUG_ON failed: FIXADDR_TOP < PAGE_OFFSET
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
                                      ^
./include/linux/compiler.h:325:4: note: in definition of macro ‘__compiletime_assert’
    prefix ## suffix();    \
    ^~~~~~
./include/linux/compiler.h:344:2: note: in expansion of macro ‘_compiletime_assert’
  _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
  ^~~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’
 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                     ^~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:50:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
  BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
  ^~~~~~~~~~~~~~~~
arch/mips/mm/init.c:99:2: note: in expansion of macro ‘BUILD_BUG_ON’
  BUILD_BUG_ON(FIXADDR_TOP < PAGE_OFFSET);
  ^~~~~~~~~~~~
cc1: all warnings being treated as errors
make[3]: *** [scripts/Makefile.build:278: arch/mips/mm/init.o] Error 1
make[2]: *** [scripts/Makefile.build:489: arch/mips/mm] Error 2

Thanks,
    Paul

Re: [PATCH v2 3/5] mips: Print the kernel virtual mem layout on debugging

[Serge Semin]

Hello Paul

On Mon, May 06, 2019 at 07:14:21PM +0000, Paul Burton wrote:
> Hi Serge,
> 
> On Fri, May 03, 2019 at 08:50:39PM +0300, Serge Semin wrote:
> > It is useful at least for debugging to have the kernel virtual
> > memory layout printed at boot time so to have the full information
> > about the booted kernel. Make the printing optional and available
> > only when DEBUG_KERNEL config is enabled so not to leak a sensitive
> > kernel information.
> > 
> > Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
> > ---
> >  arch/mips/mm/init.c | 49 +++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 49 insertions(+)
> 
> FYI the rest of the series is in mips-next, but I left this one out
> because it gives me compile errors for 64r6el_defconfig:
> 
> In file included from ./include/linux/printk.h:7,
>                  from ./include/linux/kernel.h:15,
>                  from ./include/asm-generic/bug.h:18,
>                  from ./arch/mips/include/asm/bug.h:42,
>                  from ./include/linux/bug.h:5,
>                  from arch/mips/mm/init.c:11:
> arch/mips/mm/init.c: In function ‘mem_print_kmap_info’:
> ./include/linux/kern_levels.h:5:18: error: format ‘%ld’ expects argument of type ‘long int’, but argument 4 has type ‘long long unsigned int’ [-Werror=format=]
>  #define KERN_SOH "\001"  /* ASCII Start Of Header */
>                   ^~~~~~
> ./include/linux/kern_levels.h:13:21: note: in expansion of macro ‘KERN_SOH’
>  #define KERN_NOTICE KERN_SOH "5" /* normal but significant condition */
>                      ^~~~~~~~
> ./include/linux/printk.h:307:9: note: in expansion of macro ‘KERN_NOTICE’
>   printk(KERN_NOTICE pr_fmt(fmt), ##__VA_ARGS__)
>          ^~~~~~~~~~~
> arch/mips/mm/init.c:69:2: note: in expansion of macro ‘pr_notice’
>   pr_notice("Kernel virtual memory layout:\n"
>   ^~~~~~~~~
> arch/mips/mm/init.c:70:39: note: format string is defined here
>      "    lowmem  : 0x%px - 0x%px  (%4ld MB)\n"
>                                     ~~~^
>                                     %4lld
> In file included from ./arch/mips/include/asm/bug.h:5,
>                  from ./include/linux/bug.h:5,
>                  from arch/mips/mm/init.c:11:
> In function ‘mem_print_kmap_info’,
>     inlined from ‘mem_init’ at arch/mips/mm/init.c:530:2:
> ./include/linux/compiler.h:344:38: error: call to ‘__compiletime_assert_99’ declared with attribute error: BUILD_BUG_ON failed: FIXADDR_TOP < PAGE_OFFSET
>   _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>                                       ^
> ./include/linux/compiler.h:325:4: note: in definition of macro ‘__compiletime_assert’
>     prefix ## suffix();    \
>     ^~~~~~
> ./include/linux/compiler.h:344:2: note: in expansion of macro ‘_compiletime_assert’
>   _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>   ^~~~~~~~~~~~~~~~~~~
> ./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’
>  #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
>                                      ^~~~~~~~~~~~~~~~~~
> ./include/linux/build_bug.h:50:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
>   BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
>   ^~~~~~~~~~~~~~~~
> arch/mips/mm/init.c:99:2: note: in expansion of macro ‘BUILD_BUG_ON’
>   BUILD_BUG_ON(FIXADDR_TOP < PAGE_OFFSET);
>   ^~~~~~~~~~~~
> cc1: all warnings being treated as errors
> make[3]: *** [scripts/Makefile.build:278: arch/mips/mm/init.o] Error 1
> make[2]: *** [scripts/Makefile.build:489: arch/mips/mm] Error 2
> 
> Thanks,
>     Paul

Thanks for the report regarding this issue. I actually thought I tested the patch
being buildable for 64bit systems. It turns out I didn't.(

Should I resend the fixed patch as a separate v3 one In-Reply-to this v2 patch
or resubmit the patchset with cover-letter and only the fixed patch being there?

Cheers,
-Sergey

Re: [PATCH v2 3/5] mips: Print the kernel virtual mem layout on debugging

[Paul Burton]

Hi Serge,

On Wed, May 08, 2019 at 01:36:07AM +0300, Serge Semin wrote:
> Thanks for the report regarding this issue. I actually thought I
> tested the patch being buildable for 64bit systems. It turns out I
> didn't.(

Easily done :)

> Should I resend the fixed patch as a separate v3 one In-Reply-to this
> v2 patch or resubmit the patchset with cover-letter and only the fixed
> patch being there?

Replying with just v3 of this patch will be fine, no need to resend the
cover letter.

I currently plan to submit a pull request for mips-next as-is, without
this patch, in the next day or two. There are a few last minute
submissions this time round that I'll then queue up & send a second pull
request next week, which this can be part of.

Thanks,
    Paul

Re: [PATCH v2 3/5] mips: Print the kernel virtual mem layout on debugging

[Serge Semin]

On Tue, May 07, 2019 at 10:41:10PM +0000, Paul Burton wrote:
> Hi Serge,
> 
> On Wed, May 08, 2019 at 01:36:07AM +0300, Serge Semin wrote:
> > Thanks for the report regarding this issue. I actually thought I
> > tested the patch being buildable for 64bit systems. It turns out I
> > didn't.(
> 
> Easily done :)
> 
> > Should I resend the fixed patch as a separate v3 one In-Reply-to this
> > v2 patch or resubmit the patchset with cover-letter and only the fixed
> > patch being there?
> 
> Replying with just v3 of this patch will be fine, no need to resend the
> cover letter.
> 

Ok. I've just submitted the v3 version with fixed buildability problem.

> I currently plan to submit a pull request for mips-next as-is, without
> this patch, in the next day or two. There are a few last minute
> submissions this time round that I'll then queue up & send a second pull
> request next week, which this can be part of.
> 
> Thanks,
>     Paul

Regarding this patch being part of the mips mm init code. I've just found out
that 32-bit arm subsystem maintainers removed the same functionality from the
kernel 5.1. This also was removed from arm64 in kernel 4.15:
commit 1c31d4e96b8c ("ARM: 8820/1: mm: Stop printing the virtual memory layout")
commit 071929dbdd86 ("arm64: Stop printing the virtual memory layout")

Maintainer of m68k and unicore32 discarded the printing as well:
commit 1476ea250cf0 ("unicore32: stop printing the virtual memory layout")
commit 31833332f798 ("m68k/mm: Stop printing the virtual memory layout")

The reasoning of these removal was that since commit ad67b74d2469 ("printk:
hash addresses printed with %p") the kernel virtual addresses weren't
printed to the system log anyway. So instead of replacing the format string with
"%px" they decided not to leak a virtual memory layout information and completely
removed the printing. I don't really know why they didn't closed the printing for
debug kernel only as we did, since the info might be useful in this case.

Since I see a tendency of this functionality removal, we might need to
reconsider this patch integration into the MIPS arch code. What do you think?

Although some architectures still perform the virtual memory layout printing
at boot-time: x86_32, parisc, xtensa, sh, nds32 (might be others).

Cheers,
-Sergey

Re: [PATCH v2 3/5] mips: Print the kernel virtual mem layout on debugging

[Serge Semin]

Hello Paul

On Wed, May 08, 2019 at 02:38:49AM +0300, Serge Semin wrote:
> On Tue, May 07, 2019 at 10:41:10PM +0000, Paul Burton wrote:
> > Hi Serge,
> > 
> > On Wed, May 08, 2019 at 01:36:07AM +0300, Serge Semin wrote:
> > > Thanks for the report regarding this issue. I actually thought I
> > > tested the patch being buildable for 64bit systems. It turns out I
> > > didn't.(
> > 
> > Easily done :)
> > 
> > > Should I resend the fixed patch as a separate v3 one In-Reply-to this
> > > v2 patch or resubmit the patchset with cover-letter and only the fixed
> > > patch being there?
> > 
> > Replying with just v3 of this patch will be fine, no need to resend the
> > cover letter.
> > 
> 
> Ok. I've just submitted the v3 version with fixed buildability problem.
> 
> > I currently plan to submit a pull request for mips-next as-is, without
> > this patch, in the next day or two. There are a few last minute
> > submissions this time round that I'll then queue up & send a second pull
> > request next week, which this can be part of.
> > 
> > Thanks,
> >     Paul
> 
> Regarding this patch being part of the mips mm init code. I've just found out
> that 32-bit arm subsystem maintainers removed the same functionality from the
> kernel 5.1. This also was removed from arm64 in kernel 4.15:
> commit 1c31d4e96b8c ("ARM: 8820/1: mm: Stop printing the virtual memory layout")
> commit 071929dbdd86 ("arm64: Stop printing the virtual memory layout")
> 
> Maintainer of m68k and unicore32 discarded the printing as well:
> commit 1476ea250cf0 ("unicore32: stop printing the virtual memory layout")
> commit 31833332f798 ("m68k/mm: Stop printing the virtual memory layout")
> 
> The reasoning of these removal was that since commit ad67b74d2469 ("printk:
> hash addresses printed with %p") the kernel virtual addresses weren't
> printed to the system log anyway. So instead of replacing the format string with
> "%px" they decided not to leak a virtual memory layout information and completely
> removed the printing. I don't really know why they didn't closed the printing for
> debug kernel only as we did, since the info might be useful in this case.
> 
> Since I see a tendency of this functionality removal, we might need to
> reconsider this patch integration into the MIPS arch code. What do you think?
> 
> Although some architectures still perform the virtual memory layout printing
> at boot-time: x86_32, parisc, xtensa, sh, nds32 (might be others).
> 
> Cheers,
> -Sergey

So any update on this patch status?

Regards,
-Sergey

[PATCH v3] mips: Print the kernel virtual mem layout on debugging

[Serge Semin]

It is useful at least for debugging to have the kernel virtual
memory layout printed at boot time so to have the full information
about the booted kernel. Make the printing optional and available
only when DEBUG_KERNEL config is enabled so not to leak a sensitive
kernel information.

Signed-off-by: Serge Semin <fancer.lancer@gmail.com>

---
Changelog v3
- Add MLM_ROUNDUP() and use it to calculate the low memory addresses range.
- Print KB instead of kB for kilobyte quantities.
- Check constants inconsistancies for systems with HIGHMEM only.
---
 arch/mips/mm/init.c | 51 +++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)

diff --git a/arch/mips/mm/init.c b/arch/mips/mm/init.c
index bbb196ad5f26..40558b979f96 100644
--- a/arch/mips/mm/init.c
+++ b/arch/mips/mm/init.c
@@ -31,6 +31,7 @@
 #include <linux/gfp.h>
 #include <linux/kcore.h>
 #include <linux/initrd.h>
+#include <linux/sizes.h>
 
 #include <asm/bootinfo.h>
 #include <asm/cachectl.h>
@@ -56,6 +57,55 @@ unsigned long empty_zero_page, zero_page_mask;
 EXPORT_SYMBOL_GPL(empty_zero_page);
 EXPORT_SYMBOL(zero_page_mask);
 
+/*
+ * Print out the kernel virtual memory layout
+ */
+#define MLK(b, t) (void *)b, (void *)t, ((t) - (b)) >> 10
+#define MLM(b, t) (void *)b, (void *)t, ((t) - (b)) >> 20
+#define MLK_ROUNDUP(b, t) (void *)b, (void *)t, DIV_ROUND_UP(((t) - (b)), SZ_1K)
+#define MLM_ROUNDUP(b, t) (void *)b, (void *)t, DIV_ROUND_UP(((t) - (b)), SZ_1M)
+static void __init mem_print_kmap_info(void)
+{
+#ifdef CONFIG_DEBUG_KERNEL
+	pr_notice("Kernel virtual memory layout:\n"
+		  "    lowmem  : 0x%px - 0x%px  (%6td MB)\n"
+		  "      .text : 0x%px - 0x%px  (%6td KB)\n"
+		  "      .data : 0x%px - 0x%px  (%6td KB)\n"
+		  "      .init : 0x%px - 0x%px  (%6td KB)\n"
+		  "      .bss  : 0x%px - 0x%px  (%6td KB)\n"
+		  "    vmalloc : 0x%px - 0x%px  (%6ld MB)\n"
+#ifdef CONFIG_HIGHMEM
+		  "    pkmap   : 0x%px - 0x%px  (%6ld MB)\n"
+#endif
+		  "    fixmap  : 0x%px - 0x%px  (%6ld KB)\n",
+		  MLM_ROUNDUP((void *)PAGE_OFFSET, high_memory),
+		  MLK_ROUNDUP(_text, _etext),
+		  MLK_ROUNDUP(_sdata, _edata),
+		  MLK_ROUNDUP(__init_begin, __init_end),
+		  MLK_ROUNDUP(__bss_start, __bss_stop),
+		  MLM(VMALLOC_START, VMALLOC_END),
+#ifdef CONFIG_HIGHMEM
+		  MLM(PKMAP_BASE, (PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE)),
+#endif
+		  MLK(FIXADDR_START, FIXADDR_TOP));
+
+	/* Check some fundamental inconsistencies. May add something else? */
+#ifdef CONFIG_HIGHMEM
+	BUILD_BUG_ON(VMALLOC_END < PAGE_OFFSET);
+	BUG_ON(VMALLOC_END < (unsigned long)high_memory);
+	BUILD_BUG_ON((PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE) < PAGE_OFFSET);
+	BUG_ON((PKMAP_BASE) + (LAST_PKMAP)*(PAGE_SIZE) <
+		(unsigned long)high_memory);
+	BUILD_BUG_ON(FIXADDR_TOP < PAGE_OFFSET);
+	BUG_ON(FIXADDR_TOP < (unsigned long)high_memory);
+#endif
+#endif /* CONFIG_DEBUG_KERNEL */
+}
+#undef MLK
+#undef MLM
+#undef MLK_ROUNDUP
+#undef MLM_ROUNDUP
+
 /*
  * Not static inline because used by IP27 special magic initialization code
  */
@@ -479,6 +529,7 @@ void __init mem_init(void)
 	setup_zero_pages();	/* Setup zeroed pages.  */
 	mem_init_free_highmem();
 	mem_init_print_info(NULL);
+	mem_print_kmap_info();
 
 #ifdef CONFIG_64BIT
 	if ((unsigned long) &_text > (unsigned long) CKSEG0)
-- 
2.21.0

[PATCH v2 4/5] mips: Make sure dt memory regions are valid

[Serge Semin]

There are situations when memory regions coming from dts may be
too big for the platform physical address space. This especially
concerns XPA-capable systems. Bootloader may determine more than 4GB
memory available and pass it to the kernel over dts memory node, while
kernel is built without XPA/64BIT support. In this case the region
may either simply be truncated by add_memory_region() method
or by u64->phys_addr_t type casting. But in worst case the method
can even drop the memory region if it exceeds PHYS_ADDR_MAX size.
So lets make sure the retrieved from dts memory regions are valid,
and if some of them aren't, just manually truncate them with a warning
printed out.

Signed-off-by: Serge Semin <fancer.lancer@gmail.com>
---
 arch/mips/kernel/prom.c | 14 +++++++++++++-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
index 437a174e3ef9..28bf01961bb2 100644
--- a/arch/mips/kernel/prom.c
+++ b/arch/mips/kernel/prom.c
@@ -41,7 +41,19 @@ char *mips_get_machine_name(void)
 #ifdef CONFIG_USE_OF
 void __init early_init_dt_add_memory_arch(u64 base, u64 size)
 {
-	return add_memory_region(base, size, BOOT_MEM_RAM);
+	if (base >= PHYS_ADDR_MAX) {
+		pr_warn("Trying to add an invalid memory region, skipped\n");
+		return;
+	}
+
+	/* Truncate the passed memory region instead of type casting */
+	if (base + size - 1 >= PHYS_ADDR_MAX || base + size < base) {
+		pr_warn("Truncate memory region %llx @ %llx to size %llx\n",
+			size, base, PHYS_ADDR_MAX - base);
+		size = PHYS_ADDR_MAX - base;
+	}
+
+	add_memory_region(base, size, BOOT_MEM_RAM);
 }
 
 int __init early_init_dt_reserve_memory_arch(phys_addr_t base,
-- 
2.21.0

Re: [PATCH v2 4/5] mips: Make sure dt memory regions are valid

[Paul Burton]

Hello,

Serge Semin wrote:
> There are situations when memory regions coming from dts may be
> too big for the platform physical address space. This especially
> concerns XPA-capable systems. Bootloader may determine more than 4GB
> memory available and pass it to the kernel over dts memory node, while
> kernel is built without XPA/64BIT support. In this case the region
> may either simply be truncated by add_memory_region() method
> or by u64->phys_addr_t type casting. But in worst case the method
> can even drop the memory region if it exceeds PHYS_ADDR_MAX size.
> So lets make sure the retrieved from dts memory regions are valid,
> and if some of them aren't, just manually truncate them with a warning
> printed out.
> 
> Signed-off-by: Serge Semin <fancer.lancer@gmail.com>

Applied to mips-next.

Thanks,
    Paul

[ This message was auto-generated; if you believe anything is incorrect
  then please email paul.burton@mips.com to report it. ]

[PATCH v2 5/5] mips: Manually call fdt_init_reserved_mem() method

[Serge Semin]

Since memblock-patchset was introduced the reserved-memory nodes are
supported being declared in dt-files. So these nodes are actually parsed
during the arch setup procedure when the early_init_fdt_scan_reserved_mem()
method is called. But due to the arch-specific boot mem_map container
utilization we need to manually call the fdt_init_reserved_mem() method
after all the available and reserved memory has been moved to memblock.
The first function call performed before bootmem_init() by the
early_init_fdt_scan_reserved_mem() routine fails due to the lack of any
memblock memory regions to allocate from at that stage.

Signed-off-by: Serge Semin <fancer.lancer@gmail.com>

---
Changelog v2
- Discard forcible selection of OF_RESERVED_MEM config
---
 arch/mips/kernel/setup.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/mips/kernel/setup.c b/arch/mips/kernel/setup.c
index fbd216b4e929..ab349d2381c3 100644
--- a/arch/mips/kernel/setup.c
+++ b/arch/mips/kernel/setup.c
@@ -27,6 +27,7 @@
 #include <linux/dma-contiguous.h>
 #include <linux/decompress/generic.h>
 #include <linux/of_fdt.h>
+#include <linux/of_reserved_mem.h>
 
 #include <asm/addrspace.h>
 #include <asm/bootinfo.h>
@@ -825,6 +826,8 @@ static void __init arch_mem_init(char **cmdline_p)
 	memblock_reserve(__pa_symbol(&__nosave_begin),
 		__pa_symbol(&__nosave_end) - __pa_symbol(&__nosave_begin));
 
+	fdt_init_reserved_mem();
+
 	memblock_dump_all();
 
 	early_memtest(PFN_PHYS(min_low_pfn), PFN_PHYS(max_low_pfn));
-- 
2.21.0

Re: [PATCH v2 5/5] mips: Manually call fdt_init_reserved_mem() method

[Paul Burton]

Hello,

Serge Semin wrote:
> Since memblock-patchset was introduced the reserved-memory nodes are
> supported being declared in dt-files. So these nodes are actually parsed
> during the arch setup procedure when the early_init_fdt_scan_reserved_mem()
> method is called. But due to the arch-specific boot mem_map container
> utilization we need to manually call the fdt_init_reserved_mem() method
> after all the available and reserved memory has been moved to memblock.
> The first function call performed before bootmem_init() by the
> early_init_fdt_scan_reserved_mem() routine fails due to the lack of any
> memblock memory regions to allocate from at that stage.
> 
> Signed-off-by: Serge Semin <fancer.lancer@gmail.com>

Applied to mips-next.

Thanks,
    Paul

[ This message was auto-generated; if you believe anything is incorrect
  then please email paul.burton@mips.com to report it. ]