Patchwork sparc64: Fix array size reported by vmemmap_populate()

login
register
mail settings
Submitter Ben Hutchings
Date April 3, 2010, 8:41 p.m.
Message ID <1270327280.12516.368.camel@localhost>
Download mbox | patch
Permalink /patch/49336/
State Accepted
Delegated to: David Miller
Headers show

Comments

Ben Hutchings - April 3, 2010, 8:41 p.m.
vmemmap_populate() attempts to report the used index and total size of
vmemmap_table, but it wrongly shifts the total size so that it is
always shown as 0.

Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
 arch/sparc/mm/init_64.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)
David Miller - April 3, 2010, 8:50 p.m.
From: Ben Hutchings <ben@decadent.org.uk>
Date: Sat, 03 Apr 2010 21:41:20 +0100

> vmemmap_populate() attempts to report the used index and total size of
> vmemmap_table, but it wrongly shifts the total size so that it is
> always shown as 0.
> 
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>

It's not the total, size, it's the total number of chunks that
the area supports.

So it's trying to say:

	entry=${NUM_CHUNKS}/${MAX_CHUNKS}

So I think the printk statement is correct and if you check
you'll find that every other vmemmap supporting platform
has this same printk statement.
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
David Miller - April 3, 2010, 8:58 p.m.
From: David Miller <davem@davemloft.net>
Date: Sat, 03 Apr 2010 13:50:29 -0700 (PDT)

> From: Ben Hutchings <ben@decadent.org.uk>
> Date: Sat, 03 Apr 2010 21:41:20 +0100
> 
>> vmemmap_populate() attempts to report the used index and total size of
>> vmemmap_table, but it wrongly shifts the total size so that it is
>> always shown as 0.
>> 
>> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> 
> It's not the total, size, it's the total number of chunks that
> the area supports.

Nevermind, Ben's patch is right, I'll apply it.

VMEMMAP_SIZE is number of entries, not a size in bytes.

Further confusing things is that before the VMEMMAP_SIZE
bug fix the other month, the calculation was "correct"
:-)
--
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Patch

diff --git a/arch/sparc/mm/init_64.c b/arch/sparc/mm/init_64.c
index aaebc48..b2831dc 100644
--- a/arch/sparc/mm/init_64.c
+++ b/arch/sparc/mm/init_64.c
@@ -2117,7 +2117,7 @@  int __meminit vmemmap_populate(struct page *start, unsigned long nr, int node)
 			       "node=%d entry=%lu/%lu\n", start, block, nr,
 			       node,
 			       addr >> VMEMMAP_CHUNK_SHIFT,
-			       VMEMMAP_SIZE >> VMEMMAP_CHUNK_SHIFT);
+			       VMEMMAP_SIZE);
 		}
 	}
 	return 0;