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

[George Dunlap <george.dunlap@eu.citrix.com>]

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@citrix.com> 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).

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.

  -George