linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ccross@android.com (Colin Cross)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 0/3] ARM: enable dumping stacks for CONFIG_SMP
Date: Thu, 29 Nov 2012 15:00:24 -0800	[thread overview]
Message-ID: <1354230027-2204-1-git-send-email-ccross@android.com> (raw)

This topic has come up before, see
http://comments.gmane.org/gmane.linux.ports.arm.kernel/102458
for the previous discussion.

SMP is now the norm for new ARM systems, and the limitation that
CONFIG_STACKTRACE doesn't work for tasks besides 'current' causes
problems.  The particular case I'm dealing with is automated
debugging information collected from /proc/<pid>/stack when
userspace detects a process is not responding.

Dumping stacktraces is currently disabled due to the worry that the
task may be running on another CPU and that the unwinder may be
unstable when presented with a stack that is being modified.  I have
attempted to harden the frame pointer based unwinder and the unwind
table based unwinder against invalid stacks.  I separated the two
into individual patches, as I expect the patch to the table unwinder
to be more controversial than the frame pointer unwinder.

Even without the hardening, unwinding a stack for a running process
is not completely untested.  When CONFIG_ARM_UNWIND is enabled,
sysrq-t calls unwind_backtrace for all tasks including running ones.
In addition, any callers to unwind_frame with preemption enabled,
including proc_pid_stack, could see a modified stack even on a UP
system (pointed out by Rabin Vincent the last time this topic came
up).

v2 of the patchset adds additional checks to avoid starting the
stacktrace in an unmapped region or looping forever when unwinding
a bad stack.

v2:
   add depth parameter to unwind_frame
   verify that sp changes for non-leaf frames
   verify that initial sp value is in mapped lowmem
   verify that stack offsets are in the range
      [sizeof(struct thread_info), THREAD_START_SP)

 arch/arm/include/asm/stacktrace.h |    6 ++-
 arch/arm/kernel/process.c         |    2 +-
 arch/arm/kernel/stacktrace.c      |  122 +++++++++++++++++++++++++++++++------
 arch/arm/kernel/time.c            |    3 +-
 arch/arm/kernel/unwind.c          |   46 ++++++++++----
 5 files changed, 145 insertions(+), 34 deletions(-)

             reply	other threads:[~2012-11-29 23:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-29 23:00 Colin Cross [this message]
2012-11-29 23:00 ` [PATCH v2 1/3] ARM: stacktrace: harden FP stacktraces against invalid stacks Colin Cross
2013-01-24 21:07   ` Laura Abbott
2013-01-24 22:53     ` Colin Cross
2012-11-29 23:00 ` [PATCH v2 2/3] ARM: unwind: harden unwinding " Colin Cross
2012-11-29 23:00 ` [PATCH v2 3/3] ARM: stacktrace: enable save_stack_trace_tsk for CONFIG_SMP Colin Cross

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=1354230027-2204-1-git-send-email-ccross@android.com \
    --to=ccross@android.com \
    --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).