From: "Jan Beulich" <JBeulich@suse.com>
To: "xen-devel" <xen-devel@lists.xenproject.org>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>, WeiLiu <wl@xen.org>,
Roger Pau Monne <roger.pau@citrix.com>
Subject: [Xen-devel] [PATCH v2 2/2] x86/traps: widen condition for logging top-of-stack
Date: Mon, 17 Jun 2019 02:13:23 -0600 [thread overview]
Message-ID: <5D074BA30200007800238B6C@prv1-mh.provo.novell.com> (raw)
In-Reply-To: <5D074AE60200007800238B5E@prv1-mh.provo.novell.com>
Despite -fno-omit-frame-pointer the compiler may omit the frame pointer,
often for relatively simple leaf functions. (To give a specific example,
the case I've run into this with is _pci_hide_device() and gcc 8.
Interestingly the even more simple neighboring iommu_has_feature() does
get a frame pointer set up, around just a single instruction. But this
may be a result of the size-of-asm() effects discussed elsewhere.)
Log the top-of-stack value if it looks valid _or_ if RIP looks invalid.
Also annotate non-frame-pointer-based stack trace entries with a
question mark, to signal clearly that any one of them may not actually
be part of the call stack.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
---
v2: Re-base over changes to earlier patch.
--- a/xen/arch/x86/traps.c
+++ b/xen/arch/x86/traps.c
@@ -431,7 +431,7 @@ static void _show_trace(unsigned long sp
{
addr = *stack++;
if ( is_active_kernel_text(addr) )
- printk(" [<%p>] %pS\n", _p(addr), _p(addr));
+ printk(" [<%p>] ? %pS\n", _p(addr), _p(addr));
}
}
@@ -504,20 +504,25 @@ static void show_trace(const struct cpu_
if ( is_active_kernel_text(regs->rip) ||
!is_active_kernel_text(tos) )
printk(" [<%p>] %pS\n", _p(regs->rip), _p(regs->rip));
- else if ( fault )
+
+ if ( fault )
{
printk(" [Fault on access]\n");
return;
}
+
/*
- * Else RIP looks bad but the top of the stack looks good. Perhaps we
- * followed a wild function pointer? Lets assume the top of the stack is a
+ * If RIP looks bad or the top of the stack looks good, log the top of
+ * stack as well. Perhaps we followed a wild function pointer, or we're
+ * in a function without frame pointer, or in a function prologue before
+ * the frame pointer gets set up? Let's assume the top of the stack is a
* return address; print it and skip past so _show_trace() doesn't print
* it again.
*/
- else
+ if ( !is_active_kernel_text(regs->rip) ||
+ is_active_kernel_text(tos) )
{
- printk(" [<%p>] %pS\n", _p(tos), _p(tos));
+ printk(" [<%p>] ? %pS\n", _p(tos), _p(tos));
sp++;
}
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-06-17 8:13 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-31 8:59 [PATCH 0/2]: x86/traps: improve show_trace()'s top-of-stack handling Jan Beulich
2019-05-31 8:59 ` [Xen-devel] " Jan Beulich
2019-05-31 9:17 ` [PATCH 1/2] x86/traps: guard top-of-stack reads Jan Beulich
2019-05-31 9:17 ` [Xen-devel] " Jan Beulich
2019-06-07 17:51 ` Andrew Cooper
2019-06-11 9:57 ` Jan Beulich
2019-05-31 9:22 ` [PATCH 2/2] x86/traps: widen condition for logging top-of-stack Jan Beulich
2019-05-31 9:22 ` [Xen-devel] " Jan Beulich
2019-06-07 18:01 ` Andrew Cooper
2019-06-11 9:46 ` Jan Beulich
2019-06-17 8:10 ` [Xen-devel] [PATCH v2 0/2]: x86/traps: improve show_trace()'s top-of-stack handling Jan Beulich
2019-06-17 8:12 ` [Xen-devel] [PATCH v2 1/2] x86/traps: guard top-of-stack reads Jan Beulich
2019-07-02 17:47 ` Andrew Cooper
2019-07-03 7:10 ` Jan Beulich
2019-06-17 8:13 ` Jan Beulich [this message]
2019-07-03 10:21 ` [Xen-devel] [PATCH v2 2/2] x86/traps: widen condition for logging top-of-stack Andrew Cooper
2019-07-03 10:34 ` Jan Beulich
2019-07-03 19:47 ` Andrew Cooper
2019-07-04 9:09 ` Jan Beulich
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=5D074BA30200007800238B6C@prv1-mh.provo.novell.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=roger.pau@citrix.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.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).