From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 3qxFhr4Y5SzDvdQ for ; Sat, 30 Apr 2016 00:00:44 +1000 (AEST) Date: Fri, 29 Apr 2016 09:00:39 -0500 From: Josh Poimboeuf To: Minfei Huang Cc: Jessica Yu , Jiri Kosina , Miroslav Benes , Ingo Molnar , Peter Zijlstra , Michael Ellerman , Heiko Carstens , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, x86@kernel.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, Vojtech Pavlik , Jiri Slaby , Petr Mladek , Chris J Arges , Andy Lutomirski Subject: Re: [RFC PATCH v2 06/18] x86: dump_trace() error handling Message-ID: <20160429140039.w7nykasabm5kzhns@treble> References: <20160429134558.GA17476@dhcp-128-44.nay.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 In-Reply-To: <20160429134558.GA17476@dhcp-128-44.nay.redhat.com> List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Fri, Apr 29, 2016 at 09:45:58PM +0800, Minfei Huang wrote: > On 04/28/16 at 03:44P, Josh Poimboeuf wrote: > > In preparation for being able to determine whether a given stack trace > > is reliable, allow the stacktrace_ops functions to propagate errors to > > dump_trace(). > > Hi, Josh. > > Have you considered to make walk_stack function as non-return function, > since there is no obvious error during detecting the frame points? If you look at the next patch 07/18, there are several cases where walk_stack (print_context_stack_reliable) returns an error. For example, if a function gets preempted before it gets a chance to save the frame pointer, the function's caller would get skipped on the stack trace. So for preempted tasks, we always have to consider their stacks unreliable. -- Josh