[Crash-utility] Why module's global symbol cannot be displayed in crash? [ARM]

Mika Westerberg mika.westerberg at iki.fi
Sun Mar 24 17:33:53 UTC 2013


On Sat, Mar 23, 2013 at 08:44:21PM +0100, Per Fransson wrote:
> Hi all,
> 
> >
> > This is actually a known issue on ARM (just remembered that). When the crash
> > happens it identity maps the whole address space of the running process. This
> > has been fixed by upstream commit:
> >
> > commit 2c8951ab0c337cb198236df07ad55f9dd4892c26
> > Author: Will Deacon <will.deacon at arm.com>
> > Date:   Wed Jun 8 15:53:34 2011 +0100
> >
> >     ARM: idmap: use idmap_pgd when setting up mm for reboot
> >
> >     For soft-rebooting a system, it is necessary to map the MMU-off code
> >     with an identity mapping so that execution can continue safely once the
> >     MMU has been switched off.
> >
> >     Currently, switch_mm_for_reboot takes out a 1:1 mapping from 0x0 to
> >     TASK_SIZE during reboot in the hope that the reset code lives at a
> >     physical address corresponding to a userspace virtual address.
> >
> >     This patch modifies the code so that we switch to the idmap_pgd tables,
> >     which contain a 1:1 mapping of the cpu_reset code. This has the
> >     advantage of only remapping the code that we need and also means we
> >     don't need to worry about allocating a pgd from an atomic context in the
> >     case that the physical address of the cpu_reset code aliases with the
> >     virtual space used by the kernel.
> >
> 
> So, it actually allocates a 16k L1 page table just for this? But why
> be so picky about which code is identity mapped by using the
> .idmap.text section? Couldn't we just identity map all the kernel code
> in that case?
> 
> I suggested a more selective and temporary modification of the current
> mapping at one point:
> 
> http://thread.gmane.org/gmane.linux.kernel.kexec/4612

Yeah, I remember that one :-)

> I guess 16k isn't worth making a fuzz about, but it just seems a
> little bit wasteful...
> 
> By the way, as far as I can tell, there's no identity mapping of
> 'relocate_new_kernel'. Does the 'isb' instruction in cpu_v7_reset
> guarantee that we're in the realm of physical addresses by then?

I have no idea. I think a better forum for this question is linux-arm-kernel
list.




More information about the Crash-utility mailing list