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

[George Dunlap <George.Dunlap@xxxxxxxxxxxxx>]

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?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel