[Crash-utility] Question about ARM module address range

[anderson at prospeed.net]

> 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