Re: [Crash-utility] Question about ARM module address range
Hi Dave
I have taken a short look at modules_vaddr and module_end and I have both seen relevant
data:
crash> help -m
modules_vaddr: bf000000
modules_end: bfffffff
and data similar to what you see. What I also have seen is that when modules are loaded
then modules_vaddr and modules_end seems correct and when no modules have been loaded then
strange values are presented. I have looked at too few examples to be certain that this is
"always" true.
I assume (not checked in source code) that no vmalloc area is allocated for modules if no
modules are loaded. Then the function first_vmalloc_address() will return data which is
stored in modules_vaddr but has nothing to do with this.
So I think that the question is what values should modules_vaddr and modules_end have if
no modules are loaded. Does it matter, except that it might be confusing for a user?
Looking at arm.c where modules_vaddr and modules_end are used, I think the code will
behaves correctly (by luck?!), also in the case of no modules.
Jan
Jan Karlsson
Senior Software Engineer
MIB
Sony Mobile Communications
Tel: +46703062174
sonymobile.com
-----Original Message-----
From: Dave Anderson [mailto:anderson@redhat.com]
Sent: torsdag den 19 juli 2012 16:05
To: Discussion list for crash utility usage, maintenance and development
Cc: Karlsson, Jan; Fänge, Thomas; Mika Westerberg; per fransson ml
Subject: Question about ARM module address range
Hi guys,
While looking at the ARM per-cpu address range issue, I ran into something re: the ARM
module address range values that has me confused.
In arm_init(), POST_VM, you've got:
machdep->machspec->modules_end = machdep->kvbase - 1;
But it never gets used, because here in arm_is_module_addr() the local variable
"module_end" is used instead -- although it is set to the same value:
static int
arm_is_module_addr(ulong vaddr)
{
ulong modules_start;
ulong modules_end = machdep->kvbase - 1;
if (!MODULES_VADDR) {
/*
* In case we are still initializing, and vm_init() has not been
* called, we use defaults here which is 16MB below kernel start
* address.
*/
modules_start = machdep->kvbase - 16 * 1024 * 1024;
} else {
modules_start = MODULES_VADDR;
}
return (vaddr >= modules_start && vaddr <= modules_end);
}
and where MODULES_VADDR is #define'd as:
#define MODULES_VADDR (machdep->machspec->modules_vaddr)
So given that "modules_end" is set to "machdep->kvbase - 1", and
given the output from "help -m" on the 3 sample ARM dumps I have:
2.6.35:
crash> help -m
...
kvbase: c0000000
...
vmalloc_start_addr: d0000000
modules_vaddr: d0807000
modules_end: bfffffff
kernel_text_start: c0008000
...
2.6.36:
crash> help -m
...
kvbase: c0000000
...
vmalloc_start_addr: c5800000
modules_vaddr: c6024000
modules_end: bfffffff
kernel_text_start: c0008000
2.6.38:
crash> help -m
...
kvbase: c0000000
...
vmalloc_start_addr: d0000000
modules_vaddr: d0807000
modules_end: bfffffff
kernel_text_start: c0008000
...
So given that "modules_end" is always below the kvbase (bfffffff), then
arm_is_module_addr() will always return FALSE -- except maybe during pre-vm_init() time
when the range is temporarily set to be the "default range" between bf000000 and
bfffffff. (and would there *ever* be a module in that range?)
Anyway, although I don't think it's a problem, given that the only caller of
arm_is_module_addr() is arm_is_vmalloc_addr(), and that function will fall through and
still return TRUE if it is a module address.
But it just looks strange, and at least it would seem that:
(1) the machdep->machspec->modules_end version should be used, and
(2) it should be updated post-vm_init() so that the arm_is_module_addr()
function actually works?
Or am I missing something?
Dave