[Crash-utility] Question about ARM module address range

[Karlsson, Jan]

This is what I see using kmem -v
crash> kmem -v
VM_STRUCT     ADDRESS RANGE       SIZE
c0042f80   bf000000 - bf022000  139264
de045b00   e1806000 - e1808000    8192
e09bbb40   e1808000 - e180a000    8192
e09f53c0   e180a000 - e180c000    8192
e09f5440   e180c000 - e180e000    8192
e09f58c0   e180e000 - e1810000    8192
e09f5940   e1810000 - e1812000    8192
e09f5f00   e1812000 - e1814000    8192
e09f5f80   e1814000 - e1816000    8192
......

This is the case with modules. In an example without modules the first range is not present, so your assumption how it works is correct. One thing that could be done to get the printout less confusing is to put 0xffffffff in modules_vaddr if no modules exist (and potentially put 0 in modules_end).

In arm_init in arm.c:
.....
  case POST_VM:
    machdep->machspec->vmalloc_start_addr = vt->high_memory;
    /*
     * Modules are placed in first vmalloc'd area. This is 16MB
     * below PAGE_OFFSET.
     */
    machdep->machspec->modules_vaddr = first_vmalloc_address();
    machdep->machspec->modules_end = machdep->kvbase - 1;
    if (machdep->machspec->modules_vaddr >= machdep->kvbase) {
      /* no modules */
      /* important that modules_end < modules_vaddr to get range test right */
      machdep->machspec->modules_vaddr = 0xffffffff;
      machdep->machspec->modules_end = 0;
    }

To get some nicer code you can also make same changes in arm_is_module_addr.
Remove local variable modules_end and use the macro MODULES_END in the return statement.

Jan

Jan Karlsson
Senior Software Engineer
MIB
 
Sony Mobile Communications
Tel: +46703062174
sonymobile.com
 


-----Original Message-----
From: crash-utility-bounces at redhat.com [mailto:crash-utility-bounces at redhat.com] On Behalf Of anderson at prospeed.net
Sent: torsdag den 26 juli 2012 01:31
To: crash-utility at redhat.com
Subject: 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

I don't have access to my sample ARM vmcores (on vacation), but none of them have any modules loaded.  So in those 3 cases, the vmalloc range starts at either d0807000 or c6024000, and so the hardwired modules_end is confusing.  But it appears from your description that modules are put in a their own virtual address region from bf00000 to bffffff, whereas other vmalloc() calls generate virtual addresses above c000000?
(as shown by kmem -v).  In that case, you're right, the code would work as is.  Anyway, it did confuse me a bit -- perhaps arm_cmd_mach() should show different "KERNEL VMALLOC BASE" and "KERNEL MODULES BASE"
addresses, i.e., similar to x86_64?

Dave

Dave


--
Crash-utility mailing list
Crash-utility at redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility