From: Will Deacon <will.deacon@arm.com>
To: Simon Horman <horms@verge.net.au>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"kexec@lists.infradead.org" <kexec@lists.infradead.org>
Subject: Re: [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU configurations
Date: Tue, 28 Feb 2012 09:40:57 +0000 [thread overview]
Message-ID: <20120228094057.GC25625@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <20120228013526.GA7913@verge.net.au>
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
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2012-02-28 9:41 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-24 14:40 [PATCH] kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU configurations Will Deacon
2012-02-25 2:37 ` Simon Horman
2012-02-26 22:58 ` Will Deacon
2012-02-27 0:37 ` Simon Horman
2012-02-27 19:30 ` Will Deacon
2012-02-27 23:52 ` Simon Horman
2012-02-27 23:56 ` Andrew Morton
2012-02-28 0:19 ` Simon Horman
2012-02-28 0:26 ` Andrew Morton
2012-02-28 0:51 ` Simon Horman
2012-02-28 1:25 ` Andrew Morton
2012-02-28 1:35 ` Simon Horman
2012-02-28 9:40 ` Will Deacon [this message]
2012-02-28 20:45 ` Andrew Morton
2012-02-29 1:32 ` Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120228094057.GC25625@mudshark.cambridge.arm.com \
--to=will.deacon@arm.com \
--cc=akpm@linux-foundation.org \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.