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

[George Dunlap <george.dunlap@xxxxxxxxxxxxx>]

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

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