On Mon, Feb 27, 2012 at 07:30:54PM +0000, Will Deacon wrote: > On Mon, Feb 27, 2012 at 12:37:30AM +0000, Simon Horman wrote: > > On Sun, Feb 26, 2012 at 10:58:42PM +0000, Will Deacon wrote: > > > On Sat, Feb 25, 2012 at 02:37:49AM +0000, Simon Horman wrote: > > > > > > > might this cover cases where swapper_pg_dir is interesting? > > > > > > The only case where it's interesting is when you have CONFIG_MMU enabled - > > > otherwise it's always NULL. If it's #defined as NULL, the current code will > > > fail at build time so simply omitting it from the dump seems like the best > > > bet to me (the alternative being to add a NULL entry explicitly, but I don't > > > see what the gains us). > > > > Hi Will, > > > > thanks for the clarification. FWIW I am happy with your patch. > > > > Reviewed-by: Simon Horman <horms at verge.net.au> > > Cheers, Simon. What's the usual path for generic kexec code getting into > mainline? Do I need to get this queued somewhere? I think that Andrew Morton often picks up these kind of patches. Andrew, can you pick this up if its reposted with you CCed? For reference the patch is as follows: From: Will Deacon <will.deacon@xxxxxxx> kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU configurations nommu platforms don't have very interesting swapper_pg_dir pointers and usually just #define them to NULL, meaning that we can't include them in the vmcoreinfo on the kexec crash path. This patch only saves the swapper_pg_dir if we have an MMU. Signed-off-by: Will Deacon <will.deacon at arm.com> Reviewed-by: Simon Horman <horms at verge.net.au> --- kernel/kexec.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/kernel/kexec.c b/kernel/kexec.c index 7b08867..cb5d13c 100644 --- a/kernel/kexec.c +++ b/kernel/kexec.c @@ -1462,7 +1462,9 @@ static int __init crash_save_vmcoreinfo_init(void) VMCOREINFO_SYMBOL(init_uts_ns); VMCOREINFO_SYMBOL(node_online_map); +#ifdef CONFIG_MMU VMCOREINFO_SYMBOL(swapper_pg_dir); +#endif VMCOREINFO_SYMBOL(_stext); VMCOREINFO_SYMBOL(vmlist); -- 1.7.4.1
