Received: by 10.223.176.46 with SMTP id f43csp2796813wra; Thu, 25 Jan 2018 15:32:28 -0800 (PST) X-Google-Smtp-Source: AH8x225H3uJ+N9ZoCdcC9fYCmz68n1OiPz5Yvp2uDMIDmKn/rfGOUOgmowtCnfVXzsxOyCrHtAd0 X-Received: by 10.101.100.19 with SMTP id a19mr14361084pgv.203.1516923148178; Thu, 25 Jan 2018 15:32:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516923148; cv=none; d=google.com; s=arc-20160816; b=yZzm4vA93JWFzJEQXIkd/0/Yx4Ui7bFN82YAV11NyHQlaG9lPQPINS7/V5anK1JYhI sBMIBEX6Hi7Abeh7xdPmDNRSpRGmxthk6HfmULkYW+X49w8gOLYvhIUBro/KZgnQvHuV B62YSSlVzZqFnHCENj3v57r0G1K30zOQqdBZLngsTFZJS0MOMPVuXLTABrfnAD9UXjpA 3UBxBTET85cSGZZfBzfNhL8tibBFREtbbNPjpk8CtwDPV+MavMu6ucJy2q+K6yyDt2WI 0MpueIzUrYnlD1uUNEhJf6T8iAEFtB/VLta98mDlEeXBXkgqCQ6sBNDawfcijO/9CX3j Tfew== 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=qdhzjuk6spWO2T+umO+RzM+XWPh1W/Y3ErktbvSiuSM=; b=MP+UEPAUvOub1EixoWmMp1du+1qA9ekUhJq0WZp+X5b2fCCu4+MXkwJCgFrIgrOrQ6 CODs6zLjyda0hBclglxpTl974P2BevZ65G3XYFOWSib3pBPzJytcfgm9D8RfO9qpWZIj FODYMJVqT3Eu2ixp94mBz6D4MJQwjNj2u3broxEJoqbNfxjJwE6tPUVknTco6pia33sH Sb0WhjoEPLB5PbK4SmFSTv0YtDPX28k6saYthRn6JVo6YmhR96gWZQ5UmQoF8sMZYvPu 4ki0ag5qXlwldMqAt81KjV7Q0cnL/w920bH7EXTuYRwVMR5Av9aqP/WEWjkrYh310hdb FTfQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=gu5oTJeZ; 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 f15si2171912pgv.204.2018.01.25.15.32.13; Thu, 25 Jan 2018 15:32:28 -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=gu5oTJeZ; 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 S1751496AbeAYXbi (ORCPT + 99 others); Thu, 25 Jan 2018 18:31:38 -0500 Received: from mail-pf0-f196.google.com ([209.85.192.196]:41365 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751187AbeAYXbg (ORCPT ); Thu, 25 Jan 2018 18:31:36 -0500 Received: by mail-pf0-f196.google.com with SMTP id c6so6952661pfi.8; Thu, 25 Jan 2018 15:31:36 -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=qdhzjuk6spWO2T+umO+RzM+XWPh1W/Y3ErktbvSiuSM=; b=gu5oTJeZ2ci6gleReoaeW6OlH5afKoClfD41qH+01KIMZv3QvF5DyFxWotCwHt3dag 764H0KyEsZg17HgdHwzUCtLdU/gCJSkyGSRmmmI4giEMZUludU43Scgsnr63IZs/MlPp m05LgZ38iTTtgWtw5+jr9kTPSp3We6j9+L0VugEuSoXmt2LSRfUCxjX1PUNAv986gwHV ThEVfz68sKCx+flHbfAmNK3fpGgDXTSBaVT1rd+bhbMXN/h4aH01ncPGxYPN+TDt015w cn+C+lrwambAUbIQ04YKrsrngLWbE6814x6HLHZTcCqf41THgU+3Op6tXztww7D2Jl0C B8EQ== 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=qdhzjuk6spWO2T+umO+RzM+XWPh1W/Y3ErktbvSiuSM=; b=BUAncB3pEgDLfZh/MK4aGerFwA3Ai8mkz7Yaewz05MAcvp85fLx1nhEU31E+YrUL/Z gIbVEBZ3O8iEimNYNKG88ivOwupowTIScX5FWvXYx45PY1MU7TfqymFszhniqeHzxetH zSIgXyWZrckx88Vvac6NMOnnZjeRx6EZdZd+kY2N4YqA8PNAviARWT+7ANnnWidTMZYo RvCgC/h1E8SY6E4XiPF1zA/KK/c5pvYyqAp1bBfswqK8sCTaZehI5Eb2AADTZp/afD6k p6S2s3Dtw4Cwic12wjSs12L1ihcaool+S67zLVPTwFJjGeyrh6nqvkx0QrSu0bSXRyXN hKIg== X-Gm-Message-State: AKwxytez270tuif+5XXRvR2FwTb7UDauiBffGckAByDgdVr93BlyDByF UV4L17e9BcpZy+vCAesud2c= X-Received: by 2002:a17:902:bc85:: with SMTP id bb5-v6mr12981577plb.425.1516923095513; Thu, 25 Jan 2018 15:31:35 -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 z186sm6343093pgb.70.2018.01.25.15.31.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Jan 2018 15:31:34 -0800 (PST) Subject: Re: [RFC PATCH v2 1/1] of: introduce event tracepoints for dynamic device_node lifecyle To: Tyrel Datwyler , Wolfram Sang , devicetree@vger.kernel.org Cc: 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> <20180121143117.19805-2-wsa+renesas@sang-engineering.com> <4cc627c4-1aaf-b8d5-5a26-eea7e596743f@gmail.com> <25f83d0d-bc67-f1b5-cadb-838987fd846d@linux.vnet.ibm.com> From: Frank Rowand Message-ID: Date: Thu, 25 Jan 2018 15:31:33 -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: <25f83d0d-bc67-f1b5-cadb-838987fd846d@linux.vnet.ibm.com> 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 14:40, Tyrel Datwyler wrote: > On 01/24/2018 10:48 PM, Frank Rowand wrote: >> On 01/21/18 06:31, Wolfram Sang wrote: >>> From: Tyrel Datwyler >>> >>> This patch introduces event tracepoints for tracking a device_nodes >>> reference cycle as well as reconfig notifications generated in response >>> to node/property manipulations. >>> >>> With the recent upstreaming of the refcount API several device_node >>> underflows and leaks have come to my attention in the pseries (DLPAR) >>> dynamic logical partitioning code (ie. POWER speak for hotplugging >>> virtual and physcial resources at runtime such as cpus or IOAs). These >>> tracepoints provide a easy and quick mechanism for validating the >>> reference counting of device_nodes during their lifetime. >>> >>> Further, when pseries lpars are migrated to a different machine we >>> perform a live update of our device tree to bring it into alignment with >>> the configuration of the new machine. The of_reconfig_notify trace point >>> provides a mechanism that can be turned for debuging the device tree >>> modifications with out having to build a custom kernel to get at the >>> DEBUG code introduced by commit 00aa37206e1a54 ("of/reconfig: Add debug >>> output for OF_RECONFIG notifiers"). >>> >>> The following trace events are provided: of_node_get, of_node_put, >>> of_node_release, and of_reconfig_notify. These trace points require a >> >> Please add a note that the of_reconfig_notify trace event is not an >> added bit of debug info, but is instead replacing information that >> was previously available via pr_debug() when DEBUG was defined. >> >> >>> kernel built with ftrace support to be enabled. In a typical environment >>> where debugfs is mounted at /sys/kernel/debug the entire set of >>> tracepoints can be set with the following: >>> >>> echo "of:*" > /sys/kernel/debug/tracing/set_event >>> >>> or >>> >>> echo 1 > /sys/kernel/debug/tracing/events/of/enable >>> >>> The following shows the trace point data from a DLPAR remove of a cpu >>> from a pseries lpar: >>> >>> cat /sys/kernel/debug/tracing/trace | grep "POWER8@10" >>> >>> cpuhp/23-147 [023] .... 128.324827: >>> of_node_put: refcount=5, dn->full_name=/cpus/PowerPC,POWER8@10 >>> cpuhp/23-147 [023] .... 128.324829: >>> of_node_put: refcount=4, dn->full_name=/cpus/PowerPC,POWER8@10 >>> cpuhp/23-147 [023] .... 128.324829: >>> of_node_put: refcount=3, dn->full_name=/cpus/PowerPC,POWER8@10 >>> cpuhp/23-147 [023] .... 128.324831: >>> of_node_put: refcount=2, dn->full_name=/cpus/PowerPC,POWER8@10 >>> drmgr-7284 [009] .... 128.439000: >>> of_node_put: refcount=1, dn->full_name=/cpus/PowerPC,POWER8@10 >>> drmgr-7284 [009] .... 128.439002: >>> of_reconfig_notify: action=DETACH_NODE, dn->full_name=/cpus/PowerPC,POWER8@10, >>> prop->name=null, old_prop->name=null >>> drmgr-7284 [009] .... 128.439015: >>> of_node_put: refcount=0, dn->full_name=/cpus/PowerPC,POWER8@10 >>> drmgr-7284 [009] .... 128.439016: >>> of_node_release: dn->full_name=/cpus/PowerPC,POWER8@10, dn->_flags=4 >>> >>> Signed-off-by: Tyrel Datwyler >> >> The following belongs in a list of version 2 changes, below the "---" line: >> >>> [wsa: fixed commit abbrev and one of the sysfs paths in commit desc, >>> removed trailing space and fixed pointer declaration in code] >> >>> Signed-off-by: Wolfram Sang >>> --- >>> drivers/of/dynamic.c | 32 ++++++---------- >>> include/trace/events/of.h | 93 +++++++++++++++++++++++++++++++++++++++++++++++ >>> 2 files changed, 105 insertions(+), 20 deletions(-) >>> create mode 100644 include/trace/events/of.h >> >> mode looks incorrect. Existing files in include/trace/events/ are -rw-rw---- >> >> >>> diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c >>> index ab988d88704da0..b0d6ab5a35b8c6 100644 >>> --- a/drivers/of/dynamic.c >>> +++ b/drivers/of/dynamic.c >>> @@ -21,6 +21,9 @@ static struct device_node *kobj_to_device_node(struct kobject *kobj) >>> return container_of(kobj, struct device_node, kobj); >>> } >>> >>> +#define CREATE_TRACE_POINTS >>> +#include >>> + >>> /** >>> * of_node_get() - Increment refcount of a node >>> * @node: Node to inc refcount, NULL is supported to simplify writing of >>> @@ -30,8 +33,10 @@ static struct device_node *kobj_to_device_node(struct kobject *kobj) >>> */ >>> struct device_node *of_node_get(struct device_node *node) >>> { >>> - if (node) >>> + if (node) { >>> kobject_get(&node->kobj); >>> + trace_of_node_get(refcount_read(&node->kobj.kref.refcount), node->full_name); >> >> See the comment from Ron that I mentioned in my previous email. >> >> Also, the path has been removed from node->full_name. Does using it here >> still give all of the information that is desired? Same for all others uses >> of full_name in this patch. >> >> The trace point should have a single argument, node. Accessing the two >> fields can be done in the tracepoint assignment. Or is there some >> reason that can't be done? Same for the trace_of_node_put() tracepoint. > > I originally was just passing the node, but added the refcount as an argument to deal with trace_of_node_put(). See my comment there for the reasoning. In that case I would remove the "- 1" in of_node_put() (which I'll talk about in general terms below -- and I wrote the comment below before writing this paragraph) or change the of_node_get and of_node_put trace events to not depend upon the common of_node_ref_template. Anyway, this is somewhat academic, since I noted in another email in a different part of this thread that there is a need to be able to debug of_node_get(), of_node_put(), and of_node_release() earlier in the boot than ftrace is available, so trace points are not the answer in those functions. >> >> >>> + } >>> return node; >>> } >>> EXPORT_SYMBOL(of_node_get); >>> @@ -43,8 +48,10 @@ EXPORT_SYMBOL(of_node_get); >>> */ >>> void of_node_put(struct device_node *node) >>> { >>> - if (node) >>> + if (node) { >>> + trace_of_node_put(refcount_read(&node->kobj.kref.refcount) - 1, node->full_name); >> >> If this is moved down one line to after kobject_put(), then no need >> to subtract 1. > > So, the problem here is that if this is the last put then the node structure will be destroyed by of_node_release before we trace the of_node_put and we get no useful tracing information about the device node. Further, you see an out of order trace with the of_node_release preceding the final of_node_put. So, I opted for the somewhat ugly implementation you see where we do the subtraction ahead of time to yield what the refcount is about to be, and pass both the refcount and the node. Excellent point. The tracepoint does need to be before the kobject_put(). I don't normally like in function comments, but this would be an exception - there should be a comment noting that the node might be freed by the kobject_put(), so trace first. I could argue with myself as to whether the count value should be before or after it is decremented. I understand why both ways are valid. I would get rid of the "- 1", even if traced before the kobject_put(), but I won't insist on the change. >> >> >>> kobject_put(&node->kobj); >>> + } >>> } >>> EXPORT_SYMBOL(of_node_put); >>> >>> @@ -75,24 +82,7 @@ const char *action_names[] = { >>> int of_reconfig_notify(unsigned long action, struct of_reconfig_data *p) >>> { >>> int rc; >>> -#ifdef DEBUG >>> - struct of_reconfig_data *pr = p; >>> - >>> - switch (action) { >>> - case OF_RECONFIG_ATTACH_NODE: >>> - case OF_RECONFIG_DETACH_NODE: >>> - pr_debug("notify %-15s %pOF\n", action_names[action], >>> - pr->dn); >>> - break; >>> - case OF_RECONFIG_ADD_PROPERTY: >>> - case OF_RECONFIG_REMOVE_PROPERTY: >>> - case OF_RECONFIG_UPDATE_PROPERTY: >>> - pr_debug("notify %-15s %pOF:%s\n", action_names[action], >>> - pr->dn, pr->prop->name); >>> - break; >>> - >>> - } >>> -#endif >>> + trace_of_reconfig_notify(action, p); >>> rc = blocking_notifier_call_chain(&of_reconfig_chain, action, p); >>> return notifier_to_errno(rc); >>> } >>> @@ -320,6 +310,8 @@ void of_node_release(struct kobject *kobj) >>> { >>> struct device_node *node = kobj_to_device_node(kobj); >>> >>> + trace_of_node_release(node); >>> + >>> /* We should never be releasing nodes that haven't been detached. */ >>> if (!of_node_check_flag(node, OF_DETACHED)) { >>> pr_err("ERROR: Bad of_node_put() on %pOF\n", node); >>> diff --git a/include/trace/events/of.h b/include/trace/events/of.h >>> new file mode 100644 >>> index 00000000000000..e8b1302a6f0129 >>> --- /dev/null >>> +++ b/include/trace/events/of.h >>> @@ -0,0 +1,93 @@ >>> +#undef TRACE_SYSTEM >>> +#define TRACE_SYSTEM of >>> + >>> +#if !defined(_TRACE_OF_H) || defined(TRACE_HEADER_MULTI_READ) >>> +#define _TRACE_OF_H >>> + >>> +#include >>> +#include >>> + >>> +DECLARE_EVENT_CLASS(of_node_ref_template, >>> + >>> + TP_PROTO(int refcount, const char *dn_name), >>> + >>> + TP_ARGS(refcount, dn_name), >>> + >>> + TP_STRUCT__entry( >>> + __string(dn_name, dn_name) >>> + __field(int, refcount) >>> + ), >>> + >>> + TP_fast_assign( >>> + __assign_str(dn_name, dn_name); >>> + __entry->refcount = refcount; >>> + ), >>> + >>> + TP_printk("refcount=%d, dn->full_name=%s", >> >> For version 1 of the patch, the example trace output was reformatted >> by hand because the lines were so long. it seems that it is easy to >> create long lines and trace output, so extra effort on keeping the >> lines shorter is well spent. > > It was mostly due to my desire to keep commit logs under 80 columns wide. :) My issue has nothing to do with the commit log. The commit log simply helped point a finger at the issue. My issue has to do with the length of the line in the trace data. Longer lines and extraneous text in the data make data analysis messier. Both for humans looking at the data and for tools parsing the data. >> >> A little verbose. I would prefer to get rid of "refcount=", ",", >> and "dn->full_name=" entirely >> >> >>> + __entry->refcount, __get_str(dn_name)) >>> +); >>> + >>> +DEFINE_EVENT(of_node_ref_template, of_node_get, >>> + TP_PROTO(int refcount, const char *dn_name), >>> + TP_ARGS(refcount, dn_name)); >>> + >>> +DEFINE_EVENT(of_node_ref_template, of_node_put, >>> + TP_PROTO(int refcount, const char *dn_name), >>> + TP_ARGS(refcount, dn_name)); >>> + >>> +TRACE_EVENT(of_node_release, >>> + >>> + TP_PROTO(struct device_node *dn), >>> + >>> + TP_ARGS(dn), >>> + >>> + TP_STRUCT__entry( >>> + __string(dn_name, dn->full_name) >>> + __field(unsigned long, flags) >> >> Does not follow the alignment conventions for files in this directory. >> >> Steve: have you dropped the conventions or are they still relevant? >> >> >>> + ), >>> + >>> + TP_fast_assign( >>> + __assign_str(dn_name, dn->full_name); >>> + __entry->flags = dn->_flags; >>> + ), >>> + >>> + TP_printk("dn->full_name=%s, dn->_flags=%lu", >>> + __get_str(dn_name), __entry->flags) >> >> That the first field is the node name should be obvious to the >> person reading the trace, so ditch "dn->full_name=". One >> could argue that _flags is not so obvious, but if someone >> is looking at why of_node_release() is being called, they >> will either care about flag, in which case it will be obvious >> that the flag value is being printed, or they won't care >> about the flag value and will be ignoring it anyway. So >> I would ditch "dn->-flags=" also> >> >>> +); >>> + >>> +#define of_reconfig_action_names \ >>> + {OF_RECONFIG_ATTACH_NODE, "ATTACH_NODE"}, \ >>> + {OF_RECONFIG_DETACH_NODE, "DETACH_NODE"}, \ >>> + {OF_RECONFIG_ADD_PROPERTY, "ADD_PROPERTY"}, \ >>> + {OF_RECONFIG_REMOVE_PROPERTY, "REMOVE_PROPERTY"}, \ >>> + {OF_RECONFIG_UPDATE_PROPERTY, "UPDATE_PROPERTY"} >>> + >>> +TRACE_EVENT(of_reconfig_notify, >>> + >>> + TP_PROTO(unsigned long action, struct of_reconfig_data *ord), >>> + >>> + TP_ARGS(action, ord), >>> + >>> + TP_STRUCT__entry( >>> + __field(unsigned long, action) >>> + __string(dn_name, ord->dn->full_name) >>> + __string(prop_name, ord->prop ? ord->prop->name : "null") >>> + __string(oldprop_name, ord->old_prop ? ord->old_prop->name : "null") >> >> Does not follow the alignment conventions for files in this directory. >> >> >>> + ), >>> + >>> + TP_fast_assign( >>> + __entry->action = action; >>> + __assign_str(dn_name, ord->dn->full_name); >>> + __assign_str(prop_name, ord->prop ? ord->prop->name : "null"); >>> + __assign_str(oldprop_name, ord->old_prop ? ord->old_prop->name : "null"); >>> + ), >>> + >>> + TP_printk("action=%s, dn->full_name=%s, prop->name=%s, old_prop->name=%s", >> >> Isn't old_prop->name the same as prop->name, if old_prop exists? If so, drop >> it. >> >> This is more verbose than the pr_debug() that is being replaced. Please make >> it more compact. >> >> >>> + __print_symbolic(__entry->action, of_reconfig_action_names), >>> + __get_str(dn_name), __get_str(prop_name), __get_str(oldprop_name)) >>> +); >>> + >>> +#endif /* _TRACE_OF_H */ >>> + >>> +/* This part must be outside protection */ >>> +#include >>> >> > >