Received: by 10.223.176.46 with SMTP id f43csp44552wra; Thu, 25 Jan 2018 17:09:51 -0800 (PST) X-Google-Smtp-Source: AH8x224gC7efM6w/5ZhitwRN9XMjqSIwSN8ASAL/0LeLwcfengcT88KQRhc9gxVm9Lmh26r97sMF X-Received: by 2002:a17:902:14d:: with SMTP id 71-v6mr13031706plb.42.1516928991151; Thu, 25 Jan 2018 17:09:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516928991; cv=none; d=google.com; s=arc-20160816; b=Wm+aq/jx42Za1F/1+rPdNFhapIQYMeV2r2PCpI4u4EDD6vun0dd8OyFjRVDQNP7Zpy VWKptBI7O0DwhXZW6mNNsHZjZHLfLepddLUNE6NjPkVYYBHCLdzm0h0aYzBbI+JKgQ86 xNP1hwwA7nIbvFTriWkkzTf3P1xUWI2UTAg7LjTxbzeXhE1muyJvSe+0Jpj6NAB2ePhA c7E+x91I6D5NNhroIOc9S5bPhYzXzMgMwkpNadApWb5/PJEVFxlxsiqgVSpgktsopY5b /X39LAX1SKo9ewSZI927F4t0amznWTo2JNFbckfO502VE7zxwCIy0muvEv/ebkrqUm3A vZrw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=c3pXLhBuejWS9ZdCwaW9DCf5UlTdZUPSMl8Bl6T/NBM=; b=GQyyfm9CX2epRKNjLfCsTJBluepedZyB+5JkJWQGGGi/hFZGviGW9xmZQwG1tFf1Wa +2WFBohhiOXdxGijvvJd0FKsOmEiI7eDmFJ18z+YOrO4cwaWY+H3XM6BEmgzQmR5T95l mmAQ5Osjs9vW+QnjuzV4hFpNhWgwfhVywSp/CGWmbrTCo+Od/iOo7hcuDpDzl8hNm2GX gsfeSHJzP4lJ0vnOrSuyDuDaxBXa4p/XY/wzpl9Qk2FgPbBJtOGqKXemxY93l/XC3aap Z1y+s6cig1d3HeyM7kzlPjCmdnOJews18k1cd3wu69h1X/gaIWyBLq8na5j7vUqyfh0Y sUAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=A7g8Hio8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id d12si2277585pgu.218.2018.01.25.17.09.25; Thu, 25 Jan 2018 17:09:51 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=A7g8Hio8; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751604AbeAZBJB (ORCPT + 99 others); Thu, 25 Jan 2018 20:09:01 -0500 Received: from mail-pf0-f196.google.com ([209.85.192.196]:35643 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751382AbeAZBI7 (ORCPT ); Thu, 25 Jan 2018 20:08:59 -0500 Received: by mail-pf0-f196.google.com with SMTP id t12so7113667pfg.2; Thu, 25 Jan 2018 17:08:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=c3pXLhBuejWS9ZdCwaW9DCf5UlTdZUPSMl8Bl6T/NBM=; b=A7g8Hio8P+sKFwDU4jVlm20hc8Yat5s2C40LAHd+Sc+ksfNI/WhMB0Rn5kkRzMD2Y4 mzlj/sWUXjeDZ/pc66s4QKzRhMxgQYTViv/28YJFeFwiQsRBdSjlk6flb8hMiEpO0M7p kBuaoMbH4ORoDCW3W28UdZuNV086546RCTbWcSTp+LstbCbEaddcYejtvvhB+752aPpi IsAXKvtDDYliTnll6/S9RmhPxvggCDZwyLHX2DVVFsxS8lkwch4mr3oYybLtpC/Yz+2i p4aZurTWpgwoqeE9Z9fraYFrfa0CUfGRJcwFtHN1joFGZc9P7GFsN4tSsWu63qctDEca jc+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=c3pXLhBuejWS9ZdCwaW9DCf5UlTdZUPSMl8Bl6T/NBM=; b=IOX+ngAuYfER9zZDSdTkZ9tEUWVcODDpiGXWitXBVhpXHbPMOqpa6GNDxQpP2ZuZYY RabhZcjCoV2XgzRcYHIK3oBQTz6G6UCNHGekiBr5xWVaspQLpJSLzXZ3SAy0AoSmwbcq rgVoc0TptrX7jur9iA0VmAhqETXDkJkeB3EwwsBZEZD7Pa24LLA9HVV0kek6uv+H7k4N esIjEp6e2BwRz7OiPtqIMgUskvGLu4RYvIh5TyOmrRS6szAtORnPfgywEot05G6kXGv7 LsWTqa13tnBXMvafhBWmhvQPlEPDWXtmr+rraqp3qxNCwKDLPsFrsDIsSAOhPBTrfTvB QmsQ== X-Gm-Message-State: AKwxytdjoY6U33kpuQKykWdEMMrT5JR9rKfESctZUnrIY+TDGBEkwZ6/ AwftsNgNMono65FX0/UneO8= X-Received: by 10.101.76.14 with SMTP id u14mr14104925pgq.363.1516928938900; Thu, 25 Jan 2018 17:08:58 -0800 (PST) Received: from [192.168.1.70] (c-73-93-215-6.hsd1.ca.comcast.net. [73.93.215.6]) by smtp.gmail.com with ESMTPSA id p20sm13492221pfh.100.2018.01.25.17.08.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jan 2018 17:08:58 -0800 (PST) Subject: Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues To: Tyrel Datwyler , Wolfram Sang Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, Steven Rostedt , linux-renesas-soc@vger.kernel.org, Rob Herring , Geert Uytterhoeven , linuxppc-dev@lists.ozlabs.org References: <20180121143117.19805-1-wsa+renesas@sang-engineering.com> <00fc90ee-de26-f819-9c81-27d06918564d@gmail.com> <20180125060330.781667e9@vmware.local.home> From: Frank Rowand Message-ID: <2f47d3ca-2533-62d3-9db1-6d16bbd64545@gmail.com> Date: Thu, 25 Jan 2018 17:08:56 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/25/18 15:53, Tyrel Datwyler wrote: > On 01/25/2018 01:49 PM, Frank Rowand wrote: >> Hi Wolfram, >> >> On 01/25/18 03:03, Steven Rostedt wrote: >>> On Wed, 24 Jan 2018 22:55:13 -0800 >>> Frank Rowand wrote: >>> >>>> Hi Steve, >>> >>>> >>>> Off the top of your head, can you tell me know early in the boot >>>> process a trace_event can be called and successfully provide the >>>> data to someone trying to debug early boot issues? >>> >>> The trace events are enabled by early_initcall(). >> >> < snip > >> >> This means that ftrace can not be used for the of_node_get(), >> of_node_put(), and of_node_release() debug info, because >> these functions are called before early_initcall(). Please >> use pr_debug() for these functions. > > I would argue that early boot debugging doesn't completely negate the > usefulness of this tracing infrastructure. I did not say or imply that it did. I am pointing out that this implementation does not meet the needs of other use cases. And potentially provides misleading information (or more precisely misleading lack of information) in some other use cases. > I get that no information > is available in the trace up until ftrace is setup by its > early_initcall, but I still found issues after early boot using this > patch and I would hope that it would be somewhat obvious if > references are out of whack once the ftrace data becomes available. > In the dynamic case on Power we often do reconfig well after boot on > live systems which produces a lot of reference put/gets. This patch > made it easy to identify several reference leaks and underflows in > our attach and detach logic with the added aid of being able to turn > on the stacktrace for each call in the ftrace data. Yes, you can get stacktraces relatively easily. This is the strongest argument for using ftrace. My assumption has been that the stack trace is useful for of_node_get() and of_node_put(). Is there _large_ value to the stack trace for of_reconfig_notify()? > Another thought is it would be nice if we could have the best of both > worlds such that the tracepoints were pr_debugs up until the ftrace > early_initcall. Or, I suppose we could ifdef it and make the ftrace > tracepoints a configuration option, such that if it wasn't configured > we implement the tracepoint functions as pr_debugs. This makes early > boot an option. Just spit balling ideas. An overly complex solution. This is just debug. Worst case alternative is that the patches live on, out of tree. So nope. > > -Tyrel > >> >> As far as I know, the of_reconfig_notify() could remain an >> ftrace instrumented function. But now that the only thing >> that would be ftrace instrumented is of_reconfig_notify(), >> I don't see a strong justification for changing the existing >> pr_debug() calls to an ftrace alternative. Though I suspect >> the original author of the patch still might desire to have >> the "#ifdef DEBUG" surrounding the pr_debug() calls removed >> since one of his issues was having to recompile his kernel >> to do his debugging. >> >> -Frank >> > >