From: linux@arm.linux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: BUG: spinlock recursion (sys_chdir, user_path_at, do_path_lookup ...)
Date: Wed, 12 Jan 2011 12:48:44 +0000 [thread overview]
Message-ID: <20110112124844.GA4415@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <20110112123508.GZ11039@n2100.arm.linux.org.uk>
On Wed, Jan 12, 2011 at 12:35:08PM +0000, Russell King - ARM Linux wrote:
> ARM doesn't implement save_stack_trace_regs() nor save_stack_trace_bp()
> so if the compiler referenced these, you'd have a kernel which doesn't
> link. The only places that this symbol appears is:
>
> arch/x86/kernel/stacktrace.c:void save_stack_trace_regs(struct stack_trace *trac
> arch/x86/mm/kmemcheck/error.c: save_stack_trace_regs(&e->trace, regs);
> include/linux/stacktrace.h:extern void save_stack_trace_regs(struct stack_trace
>
> So, if this is where your bisect decided was the problem, your bisect
> was faulty.
BTW, a useful thing to do after a bisect is to return to the point in
the history where you first noticed the regression (so Linus' tip,
your tip, or whatever). Then try reverting the commit which git bisect
_thinks_ is the cause of your problem and re-test that.
If the problem is fixed, you have greater confidence that the commit is
the problem.
If it made no difference, then you know that something else (maybe in
combination) is causing the problem.
If you couldn't revert it because of other dependencies then you have
to rely on analysis (such as what I did) and maybe try again with a
slightly different strategy - maybe the problem only _occasionally_
occurs, making the 'git bisect good' points unreliable, so maybe you
need to do more testing when the problem doesn't immediately appear?
Lastly, it is worth bearing in mind that GCC is really finicky with its
optimization. It may be hard to believe, but unrelated function
definitions in headers can (and do) affect the code generation in
completely unrelated functions causing them to be optimized
differently [*]. Maybe this applies to prototypes too?
So it _could_ be that the prototype change in include/linux/stacktrace.h
is tickling a GCC code generation bug.
* - ISTR, this behaviour was raised as a bug with GCC folk, which I
believe was closed down as wontfix as its a result of the way the
optimizer works.
next prev parent reply other threads:[~2011-01-12 12:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-11 11:05 BUG: spinlock recursion (sys_chdir, user_path_at, do_path_lookup ...) Uwe Kleine-König
2011-01-12 7:52 ` Uwe Kleine-König
2011-01-12 10:57 ` Thomas Gleixner
2011-01-12 12:03 ` Uwe Kleine-König
2011-01-12 12:35 ` Russell King - ARM Linux
2011-01-12 12:48 ` Russell King - ARM Linux [this message]
2011-01-12 12:56 ` Thomas Gleixner
2011-01-18 16:59 ` Maciej Rutecki
2011-01-18 22:19 ` Nick Piggin
2011-01-19 7:43 ` Uwe Kleine-König
-- strict thread matches above, loose matches on Subject: below --
2011-01-12 20:59 Ramirez Luna, Omar
2011-01-12 21:02 ` Uwe Kleine-König
2011-01-12 21:16 ` Ramirez Luna, Omar
2011-01-12 22:52 ` Thomas Gleixner
2011-01-13 8:09 ` Uwe Kleine-König
2011-01-13 11:01 ` Peter Zijlstra
2011-01-13 11:17 ` Peter Zijlstra
2011-01-13 11:21 ` Thomas Gleixner
2011-01-13 11:37 ` Peter Zijlstra
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=20110112124844.GA4415@n2100.arm.linux.org.uk \
--to=linux@arm.linux.org.uk \
--cc=linux-arm-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).