From: johlstei@codeaurora.org (Jeff Ohlstein)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM stacktrace and SMP
Date: Thu, 04 Nov 2010 21:08:35 -0700 [thread overview]
Message-ID: <4CD38343.8080406@codeaurora.org> (raw)
I am looking at the stacktrace support on arm, namely with respect to its
support for SMP. I'm curious as to what is different between the ARM support
and the support on other platforms.
I found this quote from Russell:
>This is unsafe on SMP - 'tsk == current' has no meaning where SMP systems
>are concerned - the fact that tsk is not current does not mean that it
>isn't running on another CPU.
>
>Basically, if a thread is running on a CPU, thread_saved_fp() is invalid.
>
>So, the question is: what guarantees do we have here that 'tsk' is not
>running on another CPU?
What harm can come from using an invalid thread_saved_fp()? Is there any
possibility that attempting to unwind a process stack with an invalid frame
pointer could cause a system crash, or will it just return garbage stack
frames? Do other platforms simply ignore this issue? We are interested in
dumping stack trace data for all processes when our target crashes, so
even potentially inaccurate data is better than nothing.
As far as actually fixing it is concerned, is there a way to stop a given
task from being scheduled, or wait until it is descheduled if it is running?
I didn't see anything like that at first glance, other than stop_machine
which is rather heavy-handed.
-Jeff
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next reply other threads:[~2010-11-05 4:08 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-05 4:08 Jeff Ohlstein [this message]
2010-11-07 17:12 ` ARM stacktrace and SMP Russell King - ARM Linux
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=4CD38343.8080406@codeaurora.org \
--to=johlstei@codeaurora.org \
--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 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.