[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [Patch v3 0/4] Xen stack trace printing improvements

On 11/19/2013 10:50 AM, Andrew Cooper wrote:
On 19/11/2013 10:10, George Dunlap wrote:
On Mon, Nov 18, 2013 at 7:34 PM, Andrew Cooper
<andrew.cooper3@xxxxxxxxxx> wrote:
This series consists of improvements to Xen's ability to print traces of its
own stack, and specifically for the stack overflow case to be able to use
frame pointers in a debug build.

I have dev tested the series in debug and non-debug cases, with and without
memory guards, and I believe that all the stack traces look correct (given the
available information Xen has), and that the boundaries are now correct. This
series has had a substantial rebase on top of the %pS series.

George: Regarding the 4.4 code, I would like to argue this as a bugfix rather
than feature, therefore being exempt from the freeze at the moment.
Well that argument is BS.  It's not a bug fix; it's clearly exactly
what the series summary describes it as -- an improvement.

The questions you need to answer are:
* What are the benefits to 4.4 of accepting this patch?
* What are the risks in accepting this patch if it turned out to be
not quite correct?

Re the benefits, I'm guessing the main one is to be able to use frame
pointers in an extra case, making the stack more readable on a crash.

The risk, it seems to me, would be if there were other crashes that
might have garbled stacks that are no longer useful; or, more
importantly, that if someone was using a debug key to print out the
hypervisor stack, that, it might cause the whole host to crash.

I'm kind of on the fence on this one -- Jan / Keir, any thoughts?


* Use frame pointers in the stack overflow case
* Correct boundaries for frame pointer traces
* Wild function pointer semantics in the common case now

* Issues with printing stack traces (although if you notice, I haven't
actually changed either of the printing algorithms)

This series seemed accepted-in-principle at v1 ages ago, pending me
confirming the boundaries. (which have admittedly be tweaked in this
latest series).

That makes more sense, thanks. If Jan and/or Keir see it that way, then the series is fine with me f/ a release perspective.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.