Kernel qs: finding kernel module global data address to be less than PAGE_OFFSET

Hi all,

I have an (older) Rev C BeagleBoard (OMAP 3530).
I wrote a small kernel module to print out various (kernel virtual) addresses:

*--snip--*

static unsigned long statgul;
u32 guinit;
u32 ginit=0x5;
static int statint=0x1000;

–snip–

void foo(void)
{
char c=‘x’;
printk("&c = 0x%08lx\n", &c);
printk("&statgul = 0x%08x\n&statint = 0x%08x\n&guinit = 0x%08x\n&ginit = 0x%08x\n",
&statgul, &statint, &guinit, &ginit);
}

–snip–

Output from the above on the board console:

&c = 0xc33ebeef
&statgul = 0xbf00c79c
&statint = 0xbf00c650
&guinit = 0xbf00c7a0
&ginit = 0xbf00c654

Also confirmed that PAGE_OFFSET is 0xc0000000.

Now the address of the local seems fine.
BUT the addresses of the globals (both initialized and uninitialized) in the kernel module are all below
PAGE_OFFSET !

My understanding is that all (virtual) kernel text & data is located above PAGE_OFFSET. That’s considered a pretty standard thing on any 32-bit platform right?

So, am just wondering what’s going on here!!??
Any help greatly appreciated!

Thanks,
kaiwan.

Looks like i may have found an answer to my own qs!

From Documentation/arm/memory.txt:

MODULES_VADDR	MODULES_END-1	Kernel module space
					Kernel modules inserted via insmod are
					placed here using dynamic mappings.
	
	00001000	TASK_SIZE-1	User space mappings
					Per-thread mappings are placed here via
					the mmap() system call.
...
So, kernel module memory starts at MODULE_VADDR.
Printed these out; found:
...
PAGE_OFFSET = 0xc0000000 **TASK_SIZE=0xbf000000**
VMALLOC_START = 0xbf000000 VMALLOC_END=0xc0000000
MODULES_VADDR = 0xd0800000 MODULES_END=0xf8000000

BUT max size of a user-mode process is till TASK_SIZE-1; this - TASK_SIZE - is 0xbf00 0000 which
is < PAGE_OFFSET !
So, perhaps that’s why some kernel module data is in that range.

But why didn’t everything in the module load at >= 0xd0800000 ???
Any opinions?

-kaiwan.

Follow-up to prev pos:

On the x86 arch, i found:

PAGE_OFFSET = 0xc0000000 TASK_SIZE=0xc0000000
[16822.619377] VMALLOC_START = 0xe0800000 VMALLOC_END=0xff7fe000
[16822.619380] MODULES_VADDR = 0xe0800000 MODULES_END=0xff7fe000

So TASK_SIZE here = PAGE_OFFSET , which is NOT the case on ARM!
Also makes sense then that therefore on x86 all kernel vaddr are > PAGE_OFFSET.

But why didn’t everything in the module load at >= 0xd0800000 ???

See dmesg o/p of kernel booting up:
–snip–

Memory: 256MB = 256MB total
[ 0.000000] Memory: 247548k/247548k available, 14596k reserved, 0K highmem
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
[ 0.000000] DMA : 0xffc00000 - 0xffe00000 ( 2 MB)
[ 0.000000] vmalloc : 0xd0800000 - 0xf8000000 ( 632 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
[ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB) <---- modules loaded here!!
[ 0.000000] .init : 0xc0008000 - 0xc0051000 ( 292 kB)
[ 0.000000] .text : 0xc0051000 - 0xc062bdc8 (5996 kB)
[ 0.000000] .data : 0xc062c000 - 0xc06ad360 ( 517 kB)
[ 0.000000] .bss : 0xc06ad384 - 0xc0c024a4 (5461 kB)
[ 0.000000] Hierarchical RCU implementation.

–snip–

(And FYI, as of this writing, this is the latest and greatest Linux kernel 3.0 booting off the BeagleBoard!)