From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [Patch v3 0/4] Xen stack trace printing improvements Date: Tue, 19 Nov 2013 11:01:52 +0000 Message-ID: <528B4520.1060905@eu.citrix.com> References: <1384803264-1093-1-git-send-email-andrew.cooper3@citrix.com> <528B4268.3060403@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <528B4268.3060403@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: Tim Deegan , Keir Fraser , Jan Beulich , Xen-devel List-Id: xen-devel@lists.xenproject.org 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 >> 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