From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759238AbdDSCaz (ORCPT ); Tue, 18 Apr 2017 22:30:55 -0400 Received: from mail-qk0-f176.google.com ([209.85.220.176]:36798 "EHLO mail-qk0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759219AbdDSCav (ORCPT ); Tue, 18 Apr 2017 22:30:51 -0400 MIME-Version: 1.0 In-Reply-To: References: <1492475525-10827-1-git-send-email-tyreld@linux.vnet.ibm.com> From: "Oliver O'Halloran" Date: Wed, 19 Apr 2017 12:30:50 +1000 Message-ID: Subject: Re: [PATCH] of: introduce event tracepoints for dynamic device_node lifecyle To: Rob Herring Cc: Tyrel Datwyler , "devicetree@vger.kernel.org" , Frank Rowand , "linux-kernel@vger.kernel.org" , rostedt@goodmis.org, Ingo Molnar , Nathan Fontenot , linuxppc-dev Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 19, 2017 at 2:46 AM, Rob Herring wrote: > On Mon, Apr 17, 2017 at 7:32 PM, Tyrel Datwyler > wrote: >> 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. > > Not really relevant for this patch, but since you are looking at > pseries and refcounting, the refcounting largely exists for pseries. > It's also hard to get right as this type of fix is fairly common. It's > now used for overlays, but we really probably only need to refcount > the overlays or changesets as a whole, not at a node level. If you > have any thoughts on how a different model of refcounting could work > for pseries, I'd like to discuss it. One idea I've been kicking around is differentiating short and long term references to a node. I figure most leaks are due to a missing of_node_put() within a stack frame so it might be possible to use the ftrace infrastructure to detect and emit warnings if a short term reference is leaked. Long term references are slightly harder to deal with, but they're less common so we can add more detailed reference tracking there (devm_of_get_node?). Oliver