[PATCH v2 0/8] Initial implementation of kdump for ARM

Simon Horman horms at verge.net.au
Thu Jul 8 23:38:02 EDT 2010


On Mon, Jul 05, 2010 at 02:55:52PM +0100, Russell King - ARM Linux wrote:
> On Mon, Jul 05, 2010 at 12:34:15PM +0200, Per Fransson wrote:
> > On 07/05/2010 12:18 PM, Russell King - ARM Linux wrote:
> >> On Mon, Jul 05, 2010 at 12:01:06PM +0200, Per Fransson wrote:
> >>> In machine_kexec an identity mapping is set up for the user space part
> >>> of the virtual address space, through a call to setup_mm_for_reboot(). I
> >>> believe this mapping is only necessary because the MMU is kept on and if
> >>> the kexec is done to facilitate the collection of a dump it would be
> >>> nice if a large part of the page table for the crashing context has not
> >>> been corrupted. Don't you agree?
> >>
> >> No.  The identity mapping is there so that we can safely disable the MMU
> >> and jump to the intended address.
> >>
> >> There is an implementation defined delay between writing the control
> >> register and the point in the instruction stream that the effect of that
> >> write is seen.
> >>
> >
> > But the identity mapping is only set up for user space part.
> 
> That's because we're normally calling back into the boot loader.
> 
> > It needs to  
> > be set up around the code which turns off the MMU for the case when  
> > there is no delay at all.
> 
> There is always a delay as the ARM architecture is pipelined.  By the
> time the instruction which writes to the control register has got to
> the writeback stage, the following instruction has long since been
> fetched from memory, and has probably been decoded and partially
> executed.
> 
> > And it would still be nice to not corrupt the page table of the
> > crashing context.
> 
> What you're then asking for is the crashing kernel to allocate 16K of
> memory to setup some page tables, and then context switch to that table
> so that the MMU can be turned off.
> 
> That's never going to be anywhere near reliable.

Can this be addresses by allocating the memory at the time that kdump
is loaded rather than when it is executed (because of a crash)?

IIRC, x86 uses a double page table approach and it is done reliably.




More information about the linux-arm-kernel mailing list