[PATCH] ARM: Fix virtual kernel memory printing for sparsemem

[PATCH] ARM: Fix virtual kernel memory printing for sparsemem

[Catalin Marinas]

Commit db9ef1a introduced information printing for the virtual kernel
memory map but page/end calculation using the pfn goes wrong and
page_count() generates a data abort or alignment fault (possibly because
it gets to an uninitialised page structure that looks like a compound
page).

This patch adds page/end calculation using pfn_to_page().

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <Will.Deacon@arm.com>
Cc: Andreas Fenkart <andreas.fenkart@streamunlimited.com>
---
 arch/arm/mm/init.c |    7 ++-----
 1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index b69ac3a..8a48634 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -600,9 +600,6 @@ void __init mem_init(void)
 	reserved_pages = free_pages = 0;
 
 	for_each_online_node(node) {
-		pg_data_t *n = NODE_DATA(node);
-		struct page *map = pgdat_page_nr(n, 0) - n->node_start_pfn;
-
 		for_each_nodebank(i, &meminfo, node) {
 			struct membank *bank = &meminfo.bank[i];
 			unsigned int pfn1, pfn2;
@@ -611,8 +608,8 @@ void __init mem_init(void)
 			pfn1 = bank_pfn_start(bank);
 			pfn2 = bank_pfn_end(bank);
 
-			page = map + pfn1;
-			end  = map + pfn2;
+			page = pfn_to_page(pfn1);
+			end  = pfn_to_page(pfn2 - 1) + 1;
 
 			do {
 				if (PageReserved(page))

[PATCH] ARM: Fix virtual kernel memory printing for sparsemem

[Russell King - ARM Linux]

On Thu, Mar 25, 2010 at 02:53:24PM +0000, Catalin Marinas wrote:
> Commit db9ef1a introduced information printing for the virtual kernel
> memory map but page/end calculation using the pfn goes wrong and
> page_count() generates a data abort or alignment fault (possibly because
> it gets to an uninitialised page structure that looks like a compound
> page).

While this looks fine, I'd like to see a lot of Tested-by's against
this before it's merged - we've had similar code in show_mem()
which has proven to be quite problematical to get right for all the
various different combinations we have.

However, we also have the same method in show_mem() which we know
works fine, so I'd also like to see the problem with using it in
mem_init() fully analysed - rather than a "possibly because".

[PATCH] ARM: Fix virtual kernel memory printing for sparsemem

[Catalin Marinas]

On Thu, 2010-03-25 at 15:10 +0000, Russell King - ARM Linux wrote:
> On Thu, Mar 25, 2010 at 02:53:24PM +0000, Catalin Marinas wrote:
> > Commit db9ef1a introduced information printing for the virtual kernel
> > memory map but page/end calculation using the pfn goes wrong and
> > page_count() generates a data abort or alignment fault (possibly because
> > it gets to an uninitialised page structure that looks like a compound
> > page).
> 
> While this looks fine, I'd like to see a lot of Tested-by's against
> this before it's merged - we've had similar code in show_mem()
> which has proven to be quite problematical to get right for all the
> various different combinations we have.
> 
> However, we also have the same method in show_mem() which we know
> works fine, so I'd also like to see the problem with using it in
> mem_init() fully analysed - rather than a "possibly because".

I can remove the "possibly" part :). The page_count() is given a page
with some random flags and it thinks it's a compound page. It than tries
to access page->first which isn't set, hence the error.

The original code assumes that for a given node the map is contiguous
and it calculates the page as (map + pfn). This is only true for
flatmem. With sparsemem the page calculation is a bit more complicated
but handled by pfn_to_page().

-- 
Catalin

[PATCH] ARM: Fix virtual kernel memory printing for sparsemem

[Russell King - ARM Linux]

On Thu, Mar 25, 2010 at 03:24:29PM +0000, Catalin Marinas wrote:
> On Thu, 2010-03-25 at 15:10 +0000, Russell King - ARM Linux wrote:
> > While this looks fine, I'd like to see a lot of Tested-by's against
> > this before it's merged - we've had similar code in show_mem()
> > which has proven to be quite problematical to get right for all the
> > various different combinations we have.
> > 
> > However, we also have the same method in show_mem() which we know
> > works fine, so I'd also like to see the problem with using it in
> > mem_init() fully analysed - rather than a "possibly because".
> 
> I can remove the "possibly" part :). The page_count() is given a page
> with some random flags and it thinks it's a compound page. It than tries
> to access page->first which isn't set, hence the error.
> 
> The original code assumes that for a given node the map is contiguous
> and it calculates the page as (map + pfn). This is only true for
> flatmem. With sparsemem the page calculation is a bit more complicated
> but handled by pfn_to_page().

And show_mem() ?  It seems to suffer from the same problem.

[PATCH] ARM: Fix virtual kernel memory printing for sparsemem

[Will Deacon]

Hi Russell,

* Russell King wrote:
> On Thu, Mar 25, 2010 at 03:24:29PM +0000, Catalin Marinas wrote:
> > On Thu, 2010-03-25 at 15:10 +0000, Russell King - ARM Linux wrote:
> > > While this looks fine, I'd like to see a lot of Tested-by's against
> > > this before it's merged - we've had similar code in show_mem()
> > > which has proven to be quite problematical to get right for all the
> > > various different combinations we have.
> > >
> > > However, we also have the same method in show_mem() which we know
> > > works fine, so I'd also like to see the problem with using it in
> > > mem_init() fully analysed - rather than a "possibly because".
> >
> > I can remove the "possibly" part :). The page_count() is given a page
> > with some random flags and it thinks it's a compound page. It than tries
> > to access page->first which isn't set, hence the error.
> >
> > The original code assumes that for a given node the map is contiguous
> > and it calculates the page as (map + pfn). This is only true for
> > flatmem. With sparsemem the page calculation is a bit more complicated
> > but handled by pfn_to_page().
> 
> And show_mem() ?  It seems to suffer from the same problem.

Well if the page flags are being set randomly, there's a good chance that show_mem()
won't get as far as calling page_count(). Even then, if the _count field that ends up
being read happens to be aligned, it won't fail. If this is what is happening, I'd
expect show_mem to give incorrect results on platforms with SPARSEMEM enabled. Has this
been observed by anybody?

Will

[PATCH] ARM: Fix virtual kernel memory printing for sparsemem

[Catalin Marinas]

On Thu, 2010-03-25 at 15:30 +0000, Russell King - ARM Linux wrote:
> On Thu, Mar 25, 2010 at 03:24:29PM +0000, Catalin Marinas wrote:
> > On Thu, 2010-03-25 at 15:10 +0000, Russell King - ARM Linux wrote:
> > > While this looks fine, I'd like to see a lot of Tested-by's against
> > > this before it's merged - we've had similar code in show_mem()
> > > which has proven to be quite problematical to get right for all the
> > > various different combinations we have.
> > >
> > > However, we also have the same method in show_mem() which we know
> > > works fine, so I'd also like to see the problem with using it in
> > > mem_init() fully analysed - rather than a "possibly because".
> >
> > I can remove the "possibly" part :). The page_count() is given a page
> > with some random flags and it thinks it's a compound page. It than tries
> > to access page->first which isn't set, hence the error.
> >
> > The original code assumes that for a given node the map is contiguous
> > and it calculates the page as (map + pfn). This is only true for
> > flatmem. With sparsemem the page calculation is a bit more complicated
> > but handled by pfn_to_page().
> 
> And show_mem() ?  It seems to suffer from the same problem.

And that's a patch which fixes both (but as you said, it would be good
if more people test it on various platforms).


ARM: Fix kernel memory printing for sparsemem

From: Catalin Marinas <catalin.marinas@arm.com>

The show_mem() and mem_init() function are assuming that the page map is
contiguous and calculates the start and end page of a bank using (map +
pfn). This fails with SPARSEMEM where pfn_to_page() must be used.

Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <Will.Deacon@arm.com>
Cc: Andreas Fenkart <andreas.fenkart@streamunlimited.com>
---
 arch/arm/mm/init.c |   14 ++++----------
 1 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index b69ac3a..4ee740a 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -83,9 +83,6 @@ void show_mem(void)
 	printk("Mem-info:\n");
 	show_free_areas();
 	for_each_online_node(node) {
-		pg_data_t *n = NODE_DATA(node);
-		struct page *map = pgdat_page_nr(n, 0) - n->node_start_pfn;
-
 		for_each_nodebank (i,mi,node) {
 			struct membank *bank = &mi->bank[i];
 			unsigned int pfn1, pfn2;
@@ -94,8 +91,8 @@ void show_mem(void)
 			pfn1 = bank_pfn_start(bank);
 			pfn2 = bank_pfn_end(bank);
 
-			page = map + pfn1;
-			end  = map + pfn2;
+			page = pfn_to_page(pfn1);
+			end  = pfn_to_page(pfn2 - 1) + 1;
 
 			do {
 				total++;
@@ -600,9 +597,6 @@ void __init mem_init(void)
 	reserved_pages = free_pages = 0;
 
 	for_each_online_node(node) {
-		pg_data_t *n = NODE_DATA(node);
-		struct page *map = pgdat_page_nr(n, 0) - n->node_start_pfn;
-
 		for_each_nodebank(i, &meminfo, node) {
 			struct membank *bank = &meminfo.bank[i];
 			unsigned int pfn1, pfn2;
@@ -611,8 +605,8 @@ void __init mem_init(void)
 			pfn1 = bank_pfn_start(bank);
 			pfn2 = bank_pfn_end(bank);
 
-			page = map + pfn1;
-			end  = map + pfn2;
+			page = pfn_to_page(pfn1);
+			end  = pfn_to_page(pfn2 - 1) + 1;
 
 			do {
 				if (PageReserved(page))


-- 
Catalin

[PATCH] ARM: Fix virtual kernel memory printing for sparsemem

[Will Deacon]

> > And show_mem() ?  It seems to suffer from the same problem.
> 
> And that's a patch which fixes both (but as you said, it would be good
> if more people test it on various platforms).
> 
> 
> ARM: Fix kernel memory printing for sparsemem
> 
> From: Catalin Marinas <catalin.marinas@arm.com>
> 
> The show_mem() and mem_init() function are assuming that the page map is
> contiguous and calculates the start and end page of a bank using (map +
> pfn). This fails with SPARSEMEM where pfn_to_page() must be used.
> 
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <Will.Deacon@arm.com>
> Cc: Andreas Fenkart <andreas.fenkart@streamunlimited.com>

Right - I tried calling show_mem() after the Kernel has booted up [I hacked
c_show() so that it calls show_mem() at the end then I executed cat /proc/cpuinfo].
This causes a page fault from an unaligned address [see bottom of email].

This was on a dual core Realview PBX-A9 with SPARSEMEM enabled. Catalin's patch
for mem_init() and show_mem() fixed the problem for me.

Tested-by: Will Deacon <will.deacon@arm.com>

Will


dhcp-dualA9:~# cat /proc/cpuinfo
[  118.928349] Mem-info:
[  118.935545] DMA per-cpu:
[  118.943316] CPU    0: hi:   90, btch:  15 usd:  85
[  118.957840] CPU    1: hi:   90, btch:  15 usd:   0
[  118.972374] Normal per-cpu:
[  118.980895] CPU    0: hi:  186, btch:  31 usd:  82
[  118.995414] CPU    1: hi:  186, btch:  31 usd:  62
[  119.010071] active_anon:494 inactive_anon:0 isolated_anon:0
[  119.010132]  active_file:930 inactive_file:1205 isolated_file:0
[  119.010191]  unevictable:0 dirty:21 writeback:0 unstable:0
[  119.010245]  free:254401 slab_reclaimable:111 slab_unreclaimable:323
[  119.010304]  mapped:646 shmem:0 pagetables:47 bounce:0
[  119.095992] DMA free:256512kB min:1024kB low:1280kB high:1536kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:260096kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[  119.205958] lowmem_reserve[]: 0 752 752
[  119.217943] Normal free:761092kB min:3028kB low:3784kB high:4540kB active_anon:1976kB inactive_anon:0kB active_file:3720kB inactive_file:4820kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:770048kB mlocked:0kB dirty:84kB writeback:0kB mapped:2584kB shmem:0kB slab_reclaimable:444kB slab_unreclaimable:1292kB kernel_stack:400kB pagetables:188kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[  119.334480] lowmem_reserve[]: 0 0 0
[  119.345253] DMA: 2*4kB 1*8kB 1*16kB 3*32kB 2*64kB 2*128kB 0*256kB 0*512kB 0*1024kB 1*2048kB 62*4096kB = 256512kB
[  119.376667] Normal: 1*4kB 1*8kB 1*16kB 1*32kB 1*64kB 1*128kB 2*256kB 1*512kB 2*1024kB 2*2048kB 184*4096kB = 761084kB
[  119.409122] 2136 total pagecache pages
[  119.592380] Unable to handle kernel paging request at virtual address dc6e6be9
[  119.614377] pgd = bf484000
[  119.622723] [dc6e6be9] *pgd=00000000
[  119.633705] Internal error: Oops: 5 [#1] SMP
[  119.646557] last sysfs file: 
[  119.655487] Modules linked in:
[  119.664736] CPU: 0    Not tainted  (2.6.34-rc2 #4)
[  119.679291] PC is at show_mem+0xc0/0x174
[  119.691106] LR is at 0x24000
[  119.699825] pc : [<80031fe0>]    lr : [<00024000>]    psr: 60000013
[  119.699888] sp : bf491ec0  ip : 90002000  fp : 00000001
[  119.734386] r10: 00000003  r9 : 91202000  r8 : dc6e6be5
[  119.750127] r7 : 0002eefd  r6 : 000003b2  r5 : 0000010f  r4 : 00000149
[  119.769785] r3 : 91002160  r2 : 00000002  r1 : 0003000c  r0 : 803aed64
[  119.789457] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[  119.810950] Control: 10c53c7d  Table: 8f48404a  DAC: 00000015
[  119.828256] Process cat (pid: 790, stack limit = 0xbf4902f8)
[  119.845303] Stack: (0xbf491ec0 to 0xbf492000)
[  119.858487] 1ec0: bff2a060 803aeae0 802b1340 000aa000 0000008b 00000001 bffd9c80 8002b680
[  119.883152] 1ee0: 803aeaf0 00000001 bff2a060 00015000 00000400 bf491f80 00000000 800c55ec
[  119.907816] 1f00: 00014030 bff2a088 2abf5034 800284d4 00000000 00000000 f000010e bfc1f4e0
[  119.932480] 1f20: bffd9c80 bf491f80 00000400 00015000 bf490000 bfc1f528 00000000 800e7e98
[  119.957146] 1f40: bf491f80 00000400 bffd9c80 00015000 bf491f80 00000400 00000000 800accc0
[  119.981806] 1f60: bffd9c80 00015000 bffd9c80 00015000 00000000 00000000 00000400 800ace14
[  120.006464] 1f80: 00000000 00000000 00000400 00000000 00000400 00015000 00015000 00000003
[  120.031129] 1fa0: 800292a8 80029100 00000400 00015000 00000003 00015000 00000400 00015000
[  120.055788] 1fc0: 00000400 00015000 00015000 00000003 7fffe000 00000000 2aad0000 00000000
[  120.080457] 1fe0: 00000003 7e8e8ba8 0000ad20 2ab84c0c 60000010 00000003 e7911103 e1a00008
[  120.105197] [<80031fe0>] (show_mem+0xc0/0x174) from [<8002b680>] (c_show+0x1cc/0x22c)
[  120.128879] [<8002b680>] (c_show+0x1cc/0x22c) from [<800c55ec>] (seq_read+0x1bc/0x428)
[  120.152869] [<800c55ec>] (seq_read+0x1bc/0x428) from [<800e7e98>] (proc_reg_read+0x94/0xa8)
[  120.178112] [<800e7e98>] (proc_reg_read+0x94/0xa8) from [<800accc0>] (vfs_read+0xa8/0x150)
[  120.203052] [<800accc0>] (vfs_read+0xa8/0x150) from [<800ace14>] (sys_read+0x3c/0x68)
[  120.226772] [<800ace14>] (sys_read+0x3c/0x68) from [<80029100>] (ret_fast_syscall+0x0/0x30)
[  120.251964] Code: e20ee909 e35e0909 0593800c 11a08003 (e5988004) 
[  120.270706] ---[ end trace 8e8702d3596a05ac ]---

[PATCH] ARM: Fix virtual kernel memory printing for sparsemem

[Marek Vasut]

Dne ?t 25. b?ezna 2010 15:53:24 Catalin Marinas napsal(a):
> Commit db9ef1a introduced information printing for the virtual kernel
> memory map but page/end calculation using the pfn goes wrong and
> page_count() generates a data abort or alignment fault (possibly because
> it gets to an uninitialised page structure that looks like a compound
> page).
> 
> This patch adds page/end calculation using pfn_to_page().
> 

I observed this as well. Came to similar conclusion. I wish I just saw this a 
little earlier, it'd save me two nights without sleep. Ok, I'll test it right 
away.

> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <Will.Deacon@arm.com>
> Cc: Andreas Fenkart <andreas.fenkart@streamunlimited.com>
> ---
>  arch/arm/mm/init.c |    7 ++-----
>  1 files changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index b69ac3a..8a48634 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -600,9 +600,6 @@ void __init mem_init(void)
>  	reserved_pages = free_pages = 0;
> 
>  	for_each_online_node(node) {
> -		pg_data_t *n = NODE_DATA(node);
> -		struct page *map = pgdat_page_nr(n, 0) - n->node_start_pfn;
> -
>  		for_each_nodebank(i, &meminfo, node) {
>  			struct membank *bank = &meminfo.bank[i];
>  			unsigned int pfn1, pfn2;
> @@ -611,8 +608,8 @@ void __init mem_init(void)
>  			pfn1 = bank_pfn_start(bank);
>  			pfn2 = bank_pfn_end(bank);
> 
> -			page = map + pfn1;
> -			end  = map + pfn2;
> +			page = pfn_to_page(pfn1);
> +			end  = pfn_to_page(pfn2 - 1) + 1;
> 
>  			do {
>  				if (PageReserved(page))
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] ARM: Fix virtual kernel memory printing for sparsemem

[Marek Vasut]

Dne ?t 25. b?ezna 2010 17:01:26 Catalin Marinas napsal(a):
> On Thu, 2010-03-25 at 15:30 +0000, Russell King - ARM Linux wrote:
> > On Thu, Mar 25, 2010 at 03:24:29PM +0000, Catalin Marinas wrote:
> > > On Thu, 2010-03-25 at 15:10 +0000, Russell King - ARM Linux wrote:
> > > > While this looks fine, I'd like to see a lot of Tested-by's against
> > > > this before it's merged - we've had similar code in show_mem()
> > > > which has proven to be quite problematical to get right for all the
> > > > various different combinations we have.
> > > > 
> > > > However, we also have the same method in show_mem() which we know
> > > > works fine, so I'd also like to see the problem with using it in
> > > > mem_init() fully analysed - rather than a "possibly because".
> > > 
> > > I can remove the "possibly" part :). The page_count() is given a page
> > > with some random flags and it thinks it's a compound page. It than
> > > tries to access page->first which isn't set, hence the error.
> > > 
> > > The original code assumes that for a given node the map is contiguous
> > > and it calculates the page as (map + pfn). This is only true for
> > > flatmem. With sparsemem the page calculation is a bit more complicated
> > > but handled by pfn_to_page().
> > 
> > And show_mem() ?  It seems to suffer from the same problem.
> 
> And that's a patch which fixes both (but as you said, it would be good
> if more people test it on various platforms).
> 
> 
> ARM: Fix kernel memory printing for sparsemem
> 
> From: Catalin Marinas <catalin.marinas@arm.com>
> 
> The show_mem() and mem_init() function are assuming that the page map is
> contiguous and calculates the start and end page of a bank using (map +
> pfn). This fails with SPARSEMEM where pfn_to_page() must be used.
> 
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <Will.Deacon@arm.com>
> Cc: Andreas Fenkart <andreas.fenkart@streamunlimited.com>

Works perfectly on my machine. I have a PXA270 based device where I have to use 
sparsemem. Thanks, you can add my:

Tested-by: Marek Vasut <marek.vasut@gmail.com>

Russell, the patch looks fine, please apply, the stuff is really broken.

Linux version 2.6.34-rc5 (root at rin) (gcc version 4.4.2 (GCC) ) #98 PREEMPT Tue 
May 4 18:09:29 CEST 2010
CPU: XScale-PXA270 [69054117] revision 7 (ARMv5TE), cr=0000397f
CPU: VIVT data cache, VIVT instruction cache
Machine: Voipac PXA270
Ignoring unrecognised tag 0x54410008
Memory policy: ECC disabled, Data cache writeback
Run Mode clock: 208.00MHz (*16)
Turbo Mode clock: 312.00MHz (*1.5, inactive)
Memory clock: 104.00MHz (/2)
System bus clock: 104.00MHz 
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 64256
Kernel command line: console=tty0 console=ttyS0,115200
PID hash table entries: 1024 (order: 0, 4096 bytes)
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 128MB 128MB = 256MB total
Memory: 256472k/256472k available, 5672k reserved, 0K highmem
Virtual kernel memory layout:
    vector  : 0xffff0000 - 0xffff1000   (   4 kB)
    fixmap  : 0xfff00000 - 0xfffe0000   ( 896 kB)
    DMA     : 0xffc00000 - 0xffe00000   (   2 MB)
    vmalloc : 0xc8800000 - 0xe8000000   ( 504 MB)
    lowmem  : 0xc0000000 - 0xc8000000   ( 128 MB)
    modules : 0xbf000000 - 0xc0000000   (  16 MB)
      .init : 0xc0008000 - 0xc00b4000   ( 688 kB)
      .text : 0xc00b4000 - 0xc020e000   (1384 kB)
      .data : 0xc0218000 - 0xc022ba80   (  79 kB)
Hierarchical RCU implementation.
NR_IRQS:288
Console: colour dummy device 80x30
console [tty0] enabled
Calibrating delay loop... 207.66 BogoMIPS (lpj=1038336)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
bio: create slab <bio-0> at 0
Switching to clocksource oscr0
NetWinder Floating Point Emulator V0.97 (double precision)
msgmni has been set to 500
io scheduler noop registered (default)
pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 22) is a FFUART
console [ttyS0] enabled
pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 21) is a BTUART
pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 20) is a STUART
mice: PS/2 mouse device common for all mice
XScale iWMMXt coprocessor detected.
Freeing init memory: 688K

[PATCH] ARM: Fix virtual kernel memory printing for sparsemem

[Russell King - ARM Linux]

On Tue, May 04, 2010 at 06:13:28PM +0200, Marek Vasut wrote:
> Dne ?t 25. b?ezna 2010 17:01:26 Catalin Marinas napsal(a):
> > On Thu, 2010-03-25 at 15:30 +0000, Russell King - ARM Linux wrote:
> > > On Thu, Mar 25, 2010 at 03:24:29PM +0000, Catalin Marinas wrote:
> > > > On Thu, 2010-03-25 at 15:10 +0000, Russell King - ARM Linux wrote:
> > > > > While this looks fine, I'd like to see a lot of Tested-by's against
> > > > > this before it's merged - we've had similar code in show_mem()
> > > > > which has proven to be quite problematical to get right for all the
> > > > > various different combinations we have.
> > > > > 
> > > > > However, we also have the same method in show_mem() which we know
> > > > > works fine, so I'd also like to see the problem with using it in
> > > > > mem_init() fully analysed - rather than a "possibly because".
> > > > 
> > > > I can remove the "possibly" part :). The page_count() is given a page
> > > > with some random flags and it thinks it's a compound page. It than
> > > > tries to access page->first which isn't set, hence the error.
> > > > 
> > > > The original code assumes that for a given node the map is contiguous
> > > > and it calculates the page as (map + pfn). This is only true for
> > > > flatmem. With sparsemem the page calculation is a bit more complicated
> > > > but handled by pfn_to_page().
> > > 
> > > And show_mem() ?  It seems to suffer from the same problem.
> > 
> > And that's a patch which fixes both (but as you said, it would be good
> > if more people test it on various platforms).
> > 
> > 
> > ARM: Fix kernel memory printing for sparsemem
> > 
> > From: Catalin Marinas <catalin.marinas@arm.com>
> > 
> > The show_mem() and mem_init() function are assuming that the page map is
> > contiguous and calculates the start and end page of a bank using (map +
> > pfn). This fails with SPARSEMEM where pfn_to_page() must be used.
> > 
> > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > Cc: Will Deacon <Will.Deacon@arm.com>
> > Cc: Andreas Fenkart <andreas.fenkart@streamunlimited.com>
> 
> Works perfectly on my machine. I have a PXA270 based device where I have to use 
> sparsemem. Thanks, you can add my:
> 
> Tested-by: Marek Vasut <marek.vasut@gmail.com>
> 
> Russell, the patch looks fine, please apply, the stuff is really broken.

It's great to see patches getting tested by others ;)

Catalin - mind submitting this with Marek's tested-by please?

[PATCH] ARM: Fix virtual kernel memory printing for sparsemem

[Catalin Marinas]

On Tue, 2010-05-04 at 17:18 +0100, Russell King - ARM Linux wrote:
> On Tue, May 04, 2010 at 06:13:28PM +0200, Marek Vasut wrote:
> > Dne ?t 25. b?ezna 2010 17:01:26 Catalin Marinas napsal(a):
> > > On Thu, 2010-03-25 at 15:30 +0000, Russell King - ARM Linux wrote:
> > > > On Thu, Mar 25, 2010 at 03:24:29PM +0000, Catalin Marinas wrote:
> > > > > On Thu, 2010-03-25 at 15:10 +0000, Russell King - ARM Linux wrote:
> > > > > > While this looks fine, I'd like to see a lot of Tested-by's against
> > > > > > this before it's merged - we've had similar code in show_mem()
> > > > > > which has proven to be quite problematical to get right for all the
> > > > > > various different combinations we have.
> > > > > >
> > > > > > However, we also have the same method in show_mem() which we know
> > > > > > works fine, so I'd also like to see the problem with using it in
> > > > > > mem_init() fully analysed - rather than a "possibly because".
> > > > >
> > > > > I can remove the "possibly" part :). The page_count() is given a page
> > > > > with some random flags and it thinks it's a compound page. It than
> > > > > tries to access page->first which isn't set, hence the error.
> > > > >
> > > > > The original code assumes that for a given node the map is contiguous
> > > > > and it calculates the page as (map + pfn). This is only true for
> > > > > flatmem. With sparsemem the page calculation is a bit more complicated
> > > > > but handled by pfn_to_page().
> > > >
> > > > And show_mem() ?  It seems to suffer from the same problem.
> > >
> > > And that's a patch which fixes both (but as you said, it would be good
> > > if more people test it on various platforms).
> > >
> > >
> > > ARM: Fix kernel memory printing for sparsemem
> > >
> > > From: Catalin Marinas <catalin.marinas@arm.com>
> > >
> > > The show_mem() and mem_init() function are assuming that the page map is
> > > contiguous and calculates the start and end page of a bank using (map +
> > > pfn). This fails with SPARSEMEM where pfn_to_page() must be used.
> > >
> > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > Cc: Will Deacon <Will.Deacon@arm.com>
> > > Cc: Andreas Fenkart <andreas.fenkart@streamunlimited.com>
> >
> > Works perfectly on my machine. I have a PXA270 based device where I have to use
> > sparsemem. Thanks, you can add my:
> >
> > Tested-by: Marek Vasut <marek.vasut@gmail.com>
> >
> > Russell, the patch looks fine, please apply, the stuff is really broken.
> 
> It's great to see patches getting tested by others ;)
> 
> Catalin - mind submitting this with Marek's tested-by please?

Done (patch 6093/1).

-- 
Catalin

[PATCH] ARM: Fix virtual kernel memory printing for sparsemem

[Marek Vasut]

Dne ?t 4. kv?tna 2010 18:28:56 Catalin Marinas napsal(a):
> On Tue, 2010-05-04 at 17:18 +0100, Russell King - ARM Linux wrote:
> > On Tue, May 04, 2010 at 06:13:28PM +0200, Marek Vasut wrote:
> > > Dne ?t 25. b?ezna 2010 17:01:26 Catalin Marinas napsal(a):
> > > > On Thu, 2010-03-25 at 15:30 +0000, Russell King - ARM Linux wrote:
> > > > > On Thu, Mar 25, 2010 at 03:24:29PM +0000, Catalin Marinas wrote:
> > > > > > On Thu, 2010-03-25 at 15:10 +0000, Russell King - ARM Linux wrote:
> > > > > > > While this looks fine, I'd like to see a lot of Tested-by's
> > > > > > > against this before it's merged - we've had similar code in
> > > > > > > show_mem() which has proven to be quite problematical to get
> > > > > > > right for all the various different combinations we have.
> > > > > > > 
> > > > > > > However, we also have the same method in show_mem() which we
> > > > > > > know works fine, so I'd also like to see the problem with
> > > > > > > using it in mem_init() fully analysed - rather than a
> > > > > > > "possibly because".
> > > > > > 
> > > > > > I can remove the "possibly" part :). The page_count() is given a
> > > > > > page with some random flags and it thinks it's a compound page.
> > > > > > It than tries to access page->first which isn't set, hence the
> > > > > > error.
> > > > > > 
> > > > > > The original code assumes that for a given node the map is
> > > > > > contiguous and it calculates the page as (map + pfn). This is
> > > > > > only true for flatmem. With sparsemem the page calculation is a
> > > > > > bit more complicated but handled by pfn_to_page().
> > > > > 
> > > > > And show_mem() ?  It seems to suffer from the same problem.
> > > > 
> > > > And that's a patch which fixes both (but as you said, it would be
> > > > good if more people test it on various platforms).
> > > > 
> > > > 
> > > > ARM: Fix kernel memory printing for sparsemem
> > > > 
> > > > From: Catalin Marinas <catalin.marinas@arm.com>
> > > > 
> > > > The show_mem() and mem_init() function are assuming that the page map
> > > > is contiguous and calculates the start and end page of a bank using
> > > > (map + pfn). This fails with SPARSEMEM where pfn_to_page() must be
> > > > used.
> > > > 
> > > > Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> > > > Cc: Will Deacon <Will.Deacon@arm.com>
> > > > Cc: Andreas Fenkart <andreas.fenkart@streamunlimited.com>
> > > 
> > > Works perfectly on my machine. I have a PXA270 based device where I
> > > have to use sparsemem. Thanks, you can add my:
> > > 
> > > Tested-by: Marek Vasut <marek.vasut@gmail.com>
> > > 
> > > Russell, the patch looks fine, please apply, the stuff is really
> > > broken.
> > 
> > It's great to see patches getting tested by others ;)
> > 
> > Catalin - mind submitting this with Marek's tested-by please?
> 
> Done (patch 6093/1).

Thanks for the fast response. Catalin, thanks for the patch.

Cheers