From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755308AbcHXT00 (ORCPT ); Wed, 24 Aug 2016 15:26:26 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41198 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753874AbcHXT0Z (ORCPT ); Wed, 24 Aug 2016 15:26:25 -0400 Date: Wed, 24 Aug 2016 14:24:45 -0500 From: Josh Poimboeuf To: Joe Perches Cc: Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , x86@kernel.org, linux-kernel@vger.kernel.org, Andy Lutomirski , Linus Torvalds , Steven Rostedt , Brian Gerst , Kees Cook , Peter Zijlstra , Frederic Weisbecker , Byungchul Park , Nilay Vaish Subject: Re: [PATCH 3/6] x86/dumpstack: make printk_stack_address() more generally useful Message-ID: <20160824192445.tiftvwceupuixays@treble> References: <9fbe0db05bacf66d337c162edbf61450d0cff1e2.1472057064.git.jpoimboe@redhat.com> <1472059718.3746.154.camel@perches.com> <20160824184327.ta3u3dckjmmc7dkx@treble> <1472065626.3746.164.camel@perches.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1472065626.3746.164.camel@perches.com> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 24 Aug 2016 19:24:48 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 24, 2016 at 12:07:06PM -0700, Joe Perches wrote: > On Wed, 2016-08-24 at 13:43 -0500, Josh Poimboeuf wrote: > > On Wed, Aug 24, 2016 at 10:28:38AM -0700, Joe Perches wrote: > > > On Wed, 2016-08-24 at 11:50 -0500, Josh Poimboeuf wrote: > > > > Change printk_stack_address() to be useful when called by an unwinder > > > > outside the context of dump_trace(). > > > > > > > > Specifically: > > > > > > > > - printk_stack_address()'s 'data' argument is always used as the log > > > >   level string.  Make that explicit. > [] > > > If this is true, and I'm not sure it is as I believe > > > there are static strings emitted like EOE and IRQ, > > > shouldn't this bubble up through the calling tree? > > > [] > > This function needs to keep its 'void *data' argument because it's a > > callback for stacktrace_ops, so it has to conform to the callback > > interface.  'data' is used for passing a pointer to an opaque data > > structure to the callback. > > > > Also this is the only caller of printk_stack_address(), so there's > > nowhere else to bubble it up to. > > And that shows that print_stack_address(data is not always a log level. > ie: walk_stack uses it to print a string not a log level. Hm, can you be more specific? As far as I can tell, here's the only possible call path to print_trace_address() and printk_stack_address(): show_trace_log_lvl() dump_trace() // ops is print_trace_op print_context_stack() // ops->walk_stack print_trace_address() // ops->address printk_stack_address() So 'data' is a sneaky way to pass 'log_lvl' from show_trace_log_lvl() to print_trace_address(), without dump_trace() and print_context_stack() knowing what it is, because they're used in other places where 'data' means something else. -- Josh