All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 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.