From: Rusty Russell <rusty@rustcorp.com.au>
To: mingo@redhat.com, hpa@zytor.com, linux-kernel@vger.kernel.org,
peterz@infradead.org, tglx@linutronix.de, mingo@elte.hu
Cc: linux-tip-commits@vger.kernel.org
Subject: Re: [tip:core/stacktrace] symbols, stacktrace: look up init symbols after module symbols
Date: Mon, 23 Mar 2009 16:01:50 +1030 [thread overview]
Message-ID: <200903231601.51648.rusty@rustcorp.com.au> (raw)
In-Reply-To: <tip-4a44bac1f98223ed77e47bf3b42fcfd10cddd85f@git.kernel.org>
On Thursday 19 March 2009 22:24:35 Ingo Molnar wrote:
> a2da405: module: Don't report discarded init pages as kernel text.
>
> The reason is this check added to core_kernel_text():
>
> - if (addr >= (unsigned long)_sinittext &&
> + if (system_state == SYSTEM_BOOTING &&
> + addr >= (unsigned long)_sinittext &&
> addr <= (unsigned long)_einittext)
> return 1;
>
> This will discard inittext symbols even though their symbol table
> is still present and even though stacktraces done while the system
> was booting up might still be relevant.
>
> To not reintroduce the (not well-specified) bug addressed in that
> commit, first do a module symbols lookup, then a final init-symbols
> lookup.
>
> This will work fine on architectures that have separate address
> spaces for modules (such as x86) - and should not crash any other
> architectures either.
Returning "1" all the time won't crash them either, AFAICT, but it's still
misleading if kernel_text_address() isn't reliable. It makes me
uncomfortable.
Does every kernel_text_address() caller want this behavior, or should we
have a was_ever_text_address()?
Rusty.
prev parent reply other threads:[~2009-03-23 5:32 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <new-discussion>
2009-03-19 11:54 ` [tip:core/stacktrace] symbols, stacktrace: look up init symbols after module symbols Ingo Molnar
2009-03-23 5:31 ` Rusty Russell [this message]
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=200903231601.51648.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
/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.