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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

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?
>
>  -George

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

Risks:
* 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).

~Andrew

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