From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Jiri Slaby <jslaby@suse.cz>
Cc: mingo@redhat.com, linux-kernel@vger.kernel.org,
Thomas Gleixner <tglx@linutronix.de>,
"H. Peter Anvin" <hpa@zytor.com>,
x86@kernel.org
Subject: Re: [PATCH 1/2] x86/stacktrace: do not fail when regs on stack for ORC
Date: Wed, 20 Dec 2017 11:45:44 -0600 [thread overview]
Message-ID: <20171220174544.g34v2lkjrz2r6kh7@treble> (raw)
In-Reply-To: <20171218033749.ihpwkjh7qfnilj4s@treble>
On Sun, Dec 17, 2017 at 09:37:49PM -0600, Josh Poimboeuf wrote:
> >
> > So making it:
> > if (!(task->flags & (PF_KTHREAD | PF_IDLE)))
> > return -EINVAL;
> >
> > works, but is not reliable now. So I believe, we cannot live without
> > unwind->error to differentiate between "unwind_done() == true" because:
> > * full stack unwound and the stack type is set to UNKNOWN
> > * unwinding failed and the stack type is set to UNKNOWN
> >
> > Or perhaps introduce stack type BOTTOM, NONE, or NOMORE meaning the
> > bottom of the stacks reached?
>
> Yeah, we'll need something... I need to think about it a little more.
I can update the ORC unwinder to set unwind->error in case it runs into
an issue or it doesn't reach the "end", like the FP unwinder does.
It might not be until 2018 though. But in the meantime you can go ahead
and update your patches accordingly and then we can combine them for
testing next year.
--
Josh
next prev parent reply other threads:[~2017-12-20 17:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-30 8:03 Jiri Slaby
2017-11-30 8:03 ` [PATCH 2/2] x86/stacktrace: make sure reliable stack trace reached userspace Jiri Slaby
2017-11-30 19:57 ` [PATCH 1/2] x86/stacktrace: do not fail when regs on stack for ORC Josh Poimboeuf
2017-11-30 19:59 ` Josh Poimboeuf
2017-12-01 7:34 ` Jiri Slaby
2017-12-14 21:58 ` Jiri Slaby
2017-12-18 3:37 ` Josh Poimboeuf
2017-12-18 6:59 ` Jiri Slaby
2017-12-20 17:45 ` Josh Poimboeuf [this message]
2017-12-20 19:07 ` Jiri Slaby
2018-04-16 22:16 ` Josh Poimboeuf
2018-04-19 13:42 ` Josh Poimboeuf
2018-05-10 12:33 ` Jiri Slaby
2018-05-10 12:49 ` Josh Poimboeuf
2018-05-11 7:01 ` Jiri Slaby
2018-05-11 15:12 ` Josh Poimboeuf
2018-05-14 11:08 ` Jiri Slaby
2018-05-14 13:42 ` Josh Poimboeuf
2018-05-14 14:00 ` Jiri Slaby
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=20171220174544.g34v2lkjrz2r6kh7@treble \
--to=jpoimboe@redhat.com \
--cc=hpa@zytor.com \
--cc=jslaby@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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
all inboxes | Powered by JetHome®