[PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU configurations

[Will Deacon]

Hi Simon, Andrew,

Sorry for re-joining the thread late, I was sleeping :)

On Tue, Feb 28, 2012 at 01:35:27AM +0000, Simon Horman wrote:
> On Mon, Feb 27, 2012 at 05:25:55PM -0800, Andrew Morton wrote:
> > swapper_pg_dir is normally an array.  But on nommu it is a pointer. 
> > VMCOREINFO_SYMBOL() wants to take its address (unnecessary on an array)
> > and this blows up when fed a pointer.

Yup. It's a fairly dull pointer at that, which is why I chose to remove it in
the nommu case.

> > Still, you didn't answer my question!  What effect will the absence of
> > SYMBOL(swapper_pg_dir)= have upon downstream tools?  If "none" then
> > sure, let's remove it.  If "explosion" then we should emit a dummy
> > SYMBOL(swapper_pg_dir)=0 if CONFIG_NOMMU.
> 
> My thought was that the tools wouldn't be used in the CONFIG_NOMMU case (yet).
> But I take your point and I think the answer is that the fallout is unknown.
> Emitting a dummy value as you suggest seems reasonable.

The reason I didn't choose a dummy value to start with is because there are
plenty of other fields in the dump that are predicated on build-time CONFIG
options. Admittedly, some of these appear to be tagged with length
information, but consider these guys:

#ifndef CONFIG_NEED_MULTIPLE_NODES
        VMCOREINFO_SYMBOL(mem_map);
        VMCOREINFO_SYMBOL(contig_page_data);
#endif

Since the VMCOREINFO_SYMBOL macro stringifies the identifier, I guess userspace
has to treat the whole thing as a map, meaning that we *can* safely remove
elements from it.

So that's my speculation. Maybe somebody on the kexec list can confirm?

Cheers,

Will