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