From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>,
xen-devel <xen-devel@lists.xenproject.org>
Cc: WeiLiu <wl@xen.org>, Roger Pau Monne <roger.pau@citrix.com>
Subject: Re: [Xen-devel] [PATCH 2/2] x86/traps: widen condition for logging top-of-stack
Date: Fri, 7 Jun 2019 19:01:11 +0100 [thread overview]
Message-ID: <691e7133-4a75-0ca9-c347-5a37aa59a30f@citrix.com> (raw)
In-Reply-To: <5CF0F2440200007800233D84@prv1-mh.provo.novell.com>
On 31/05/2019 10:22, Jan Beulich wrote:
> 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.
I very specifically didn't do that before, because it give the false
impression that when a question mark isn't present, the logging line is
accurate.
This is not true for %rbp corruption, asm blocks which don't respect the
frame pointer ABI (arguably also corruption), any fault raised from
within an EFI call.
Porting Xen to use objtool would be a definite improvement, but cannot
guard against unexpected %rbp corruption and the EFI case.
~Andrew
_______________________________________________
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-07 18:01 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 [this message]
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 ` [Xen-devel] [PATCH v2 2/2] x86/traps: widen condition for logging top-of-stack Jan Beulich
2019-07-03 10:21 ` 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=691e7133-4a75-0ca9-c347-5a37aa59a30f@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.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.