Message ID | 20231114143558.356259-1-herve.codina@bootlin.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b909:0:b0:403:3b70:6f57 with SMTP id t9csp1904451vqg; Tue, 14 Nov 2023 06:37:18 -0800 (PST) X-Google-Smtp-Source: AGHT+IEiGZrQq3rCKXSZSeZeIz4jrkfXbZV9lKjIBkYcmPQw/WJ2MD1wsCOtuhLR7hCjBtW3ShKy X-Received: by 2002:a17:902:b907:b0:1cc:29b5:a2b7 with SMTP id bf7-20020a170902b90700b001cc29b5a2b7mr2286389plb.51.1699972638463; Tue, 14 Nov 2023 06:37:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699972638; cv=none; d=google.com; s=arc-20160816; b=jEIXqUCpYrWjUp+qzt38ajGXQiRVP+B0ZZllK0od7ve57EEOC3aQxxVhONKisZJ9hH IbraJUaI2F+A2Cfrd9Dg64HfaP+Mg72eeWGnmU9uy9Dru+6SA3aeCcqZdjCe3BB+4WMg 3PbF2TAdcWaEEgkyaW30IFtRYO1yyvn+BpMayIBv+PWJR/vYqd70J0VzHM8e3/lnBdR2 +JUa54yuKVhxWFwV3D2xKwsS4zyRgUxS9ExFwQxriaYsxTLBrrRwJQFTMeavlK79/HId eOAU1nDPfP5IekTLWyxoL50KkBcTszkT34aUOgnQAmpMLiH2UClWeZmLSb3xQ2V6qD3S IaJQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=2K1mbcUA++OLwr4dR6O4Gp4Y1DTPQD4iQtrtg8iFg2o=; fh=inKJ5kKAsUU4c8hT0Ljb/CSuao2S4RjDzYxLdUfmU1Y=; b=J7304R/SitQn7J6wm+ds1i8+cwRN+vhwIxDneJSzhDJyKPLJoYW8PfvOEKPQ3CO7ih cpP1vv6w9BgZjyAFcvQePCo+dqBPwVB3yc4sDupf90IeMziRSU1TOuxVo+8h3Mt8A26U IeP6X85S86u1t3gvTqV6MXm62WivxF4qbsTBGHjDUKV3geWiVg0ZplS9cARBOvI2nOqt rD+QOqjW3jhqWdESuj+TFgy4hgkzywsshks3X15G7Jm6zjR9CUbp0PmBR7zeP8OoxNg3 N7s2vHQMAsji9H4jCpgWlVYo3/K8W+9D9tNMbKsrnAmiQEDYxrdHhA3QpVV1Et5uh62z 22gg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=GHqnYtg8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: from agentk.vger.email (agentk.vger.email. [23.128.96.32]) by mx.google.com with ESMTPS id b1-20020a170902d50100b001ca67f26f5esi8202793plg.283.2023.11.14.06.37.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Nov 2023 06:37:18 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) client-ip=23.128.96.32; Authentication-Results: mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=GHqnYtg8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.32 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by agentk.vger.email (Postfix) with ESMTP id 12F24803F975; Tue, 14 Nov 2023 06:37:11 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at agentk.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233629AbjKNOgz (ORCPT <rfc822;lhua1029@gmail.com> + 29 others); Tue, 14 Nov 2023 09:36:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57054 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233548AbjKNOgZ (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 14 Nov 2023 09:36:25 -0500 Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A31E310CE; Tue, 14 Nov 2023 06:36:02 -0800 (PST) Received: by mail.gandi.net (Postfix) with ESMTPA id C8742240002; Tue, 14 Nov 2023 14:35:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1699972561; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=2K1mbcUA++OLwr4dR6O4Gp4Y1DTPQD4iQtrtg8iFg2o=; b=GHqnYtg8T4cVJRnGe93qe/5ni27eMDmGi3R9vt9cWVZa2wwLeZArrgmiaUdSjF7YxSMLFt blMt+5d8D5y/hSViLw/CLj0GNEZhD0y3jHUOTl4saf2JmJlQV359BfIgu76pXnXVYzc+2S tT6A4XYIomBR34ZVVy9AnLF09FN77TUWCDrbqe1HhbADq+IFK59sw8WzybjVGHQXe82A4P u+B4lQ1z/2uPRCV1N+mzMz5RqL/bMov7PZ+WOylCaV++7+vFCFERMqGWO+4Q0Un2lMmwe9 ojjEkKCAyzK3D4SeDApVoa+BO19ZFHPNqIsHHzeEXtuavzbTHTq2YBxPdSkQ2A== From: Herve Codina <herve.codina@bootlin.com> To: Saravana Kannan <saravanak@google.com>, Petr Mladek <pmladek@suse.com>, Steven Rostedt <rostedt@goodmis.org>, Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Rasmus Villemoes <linux@rasmusvillemoes.dk>, Sergey Senozhatsky <senozhatsky@chromium.org>, Sakari Ailus <sakari.ailus@linux.intel.com>, "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: linux-kernel@vger.kernel.org, Allan Nielsen <allan.nielsen@microchip.com>, Horatiu Vultur <horatiu.vultur@microchip.com>, Steen Hegelund <steen.hegelund@microchip.com>, Thomas Petazzoni <thomas.petazzoni@bootlin.com>, Herve Codina <herve.codina@bootlin.com>, stable@vger.kernel.org Subject: [PATCH v2 1/1] lib/vsprintf: Fix %pfwf when current node refcount == 0 Date: Tue, 14 Nov 2023 15:35:58 +0100 Message-ID: <20231114143558.356259-1-herve.codina@bootlin.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-GND-Sasl: herve.codina@bootlin.com X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on agentk.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (agentk.vger.email [0.0.0.0]); Tue, 14 Nov 2023 06:37:11 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782550509176312298 X-GMAIL-MSGID: 1782550509176312298 |
Series |
[v2,1/1] lib/vsprintf: Fix %pfwf when current node refcount == 0
|
|
Commit Message
Herve Codina
Nov. 14, 2023, 2:35 p.m. UTC
A refcount issue can appeared in __fwnode_link_del() due to the
pr_debug() call:
WARNING: CPU: 0 PID: 901 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110
Call Trace:
<TASK>
...
of_node_get+0x1e/0x30
of_fwnode_get+0x28/0x40
fwnode_full_name_string+0x34/0x90
fwnode_string+0xdb/0x140
...
vsnprintf+0x17b/0x630
...
__fwnode_link_del+0x25/0xa0
fwnode_links_purge+0x39/0xb0
of_node_release+0xd9/0x180
...
Indeed, an fwnode (of_node) is being destroyed and so, of_node_release()
is called because the of_node refcount reached 0.
From of_node_release() several function calls are done and lead to
a pr_debug() calls with %pfwf to print the fwnode full name.
The issue is not present if we change %pfwf to %pfwP.
To print the full name, %pfwf iterates over the current node and its
parents and obtain/drop a reference to all nodes involved.
In order to allow to print the full name (%pfwf) of a node while it is
being destroyed, do not obtain/drop a reference to this current node.
Fixes: a92eb7621b9f ("lib/vsprintf: Make use of fwnode API to obtain node names and separators")
Cc: stable@vger.kernel.org
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
---
Changes v1 -> v2
- Avoid handling current node out of the loop. Instead obtain/drop references
in the loop based on the depth value.
- Remove some of the backtrace lines in the commit log.
lib/vsprintf.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
Comments
Hi Herve, On Tue, Nov 14, 2023 at 03:35:58PM +0100, Herve Codina wrote: > A refcount issue can appeared in __fwnode_link_del() due to the > pr_debug() call: > WARNING: CPU: 0 PID: 901 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 > Call Trace: > <TASK> > ... > of_node_get+0x1e/0x30 > of_fwnode_get+0x28/0x40 > fwnode_full_name_string+0x34/0x90 > fwnode_string+0xdb/0x140 > ... > vsnprintf+0x17b/0x630 > ... > __fwnode_link_del+0x25/0xa0 > fwnode_links_purge+0x39/0xb0 > of_node_release+0xd9/0x180 > ... > > Indeed, an fwnode (of_node) is being destroyed and so, of_node_release() > is called because the of_node refcount reached 0. > From of_node_release() several function calls are done and lead to > a pr_debug() calls with %pfwf to print the fwnode full name. > The issue is not present if we change %pfwf to %pfwP. > > To print the full name, %pfwf iterates over the current node and its > parents and obtain/drop a reference to all nodes involved. > > In order to allow to print the full name (%pfwf) of a node while it is > being destroyed, do not obtain/drop a reference to this current node. > > Fixes: a92eb7621b9f ("lib/vsprintf: Make use of fwnode API to obtain node names and separators") > Cc: stable@vger.kernel.org > Signed-off-by: Herve Codina <herve.codina@bootlin.com> > --- > Changes v1 -> v2 > - Avoid handling current node out of the loop. Instead obtain/drop references > in the loop based on the depth value. > - Remove some of the backtrace lines in the commit log. > > lib/vsprintf.c | 11 ++++++++--- > 1 file changed, 8 insertions(+), 3 deletions(-) > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c > index afb88b24fa74..633f5481ac17 100644 > --- a/lib/vsprintf.c > +++ b/lib/vsprintf.c > @@ -2110,15 +2110,20 @@ char *fwnode_full_name_string(struct fwnode_handle *fwnode, char *buf, > > /* Loop starting from the root node to the current node. */ > for (depth = fwnode_count_parents(fwnode); depth >= 0; depth--) { > - struct fwnode_handle *__fwnode = > - fwnode_get_nth_parent(fwnode, depth); > + /* > + * Only get a reference for other nodes (ie parents node). "i.e." With that, Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> > + * fwnode refcount may be 0 here. > + */ > + struct fwnode_handle *__fwnode = depth ? > + fwnode_get_nth_parent(fwnode, depth) : fwnode; > > buf = string(buf, end, fwnode_get_name_prefix(__fwnode), > default_str_spec); > buf = string(buf, end, fwnode_get_name(__fwnode), > default_str_spec); > > - fwnode_handle_put(__fwnode); > + if (depth) > + fwnode_handle_put(__fwnode); > } > > return buf;
On Tue, Nov 14, 2023 at 03:35:58PM +0100, Herve Codina wrote: > A refcount issue can appeared in __fwnode_link_del() due to the > pr_debug() call: > WARNING: CPU: 0 PID: 901 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 > Call Trace: > <TASK> > ... > of_node_get+0x1e/0x30 > of_fwnode_get+0x28/0x40 > fwnode_full_name_string+0x34/0x90 > fwnode_string+0xdb/0x140 > ... > vsnprintf+0x17b/0x630 > ... > __fwnode_link_del+0x25/0xa0 > fwnode_links_purge+0x39/0xb0 > of_node_release+0xd9/0x180 > ... > > Indeed, an fwnode (of_node) is being destroyed and so, of_node_release() > is called because the of_node refcount reached 0. > From of_node_release() several function calls are done and lead to > a pr_debug() calls with %pfwf to print the fwnode full name. > The issue is not present if we change %pfwf to %pfwP. > > To print the full name, %pfwf iterates over the current node and its > parents and obtain/drop a reference to all nodes involved. > > In order to allow to print the full name (%pfwf) of a node while it is > being destroyed, do not obtain/drop a reference to this current node. One nit-pick below, otherwise Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> ... > /* Loop starting from the root node to the current node. */ > for (depth = fwnode_count_parents(fwnode); depth >= 0; depth--) { > - struct fwnode_handle *__fwnode = > - fwnode_get_nth_parent(fwnode, depth); > + /* > + * Only get a reference for other nodes (ie parents node). "parent's node" (doesn't look right)? Or "parent nodes"? > + * fwnode refcount may be 0 here. > + */ > + struct fwnode_handle *__fwnode = depth ? > + fwnode_get_nth_parent(fwnode, depth) : fwnode; > > buf = string(buf, end, fwnode_get_name_prefix(__fwnode), > default_str_spec); > buf = string(buf, end, fwnode_get_name(__fwnode), > default_str_spec); > > - fwnode_handle_put(__fwnode); > + if (depth) > + fwnode_handle_put(__fwnode); > }
Hi Sakari, On Tue, 14 Nov 2023 14:47:25 +0000 Sakari Ailus <sakari.ailus@linux.intel.com> wrote: [...] > > + * Only get a reference for other nodes (ie parents node). > > "i.e." Will be changed in the next iteration. > > With that, > > Reviewed-by: Sakari Ailus <sakari.ailus@linux.intel.com> Best regards, Hervé
Hi Andy, On Tue, 14 Nov 2023 16:59:35 +0200 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: [...] > > One nit-pick below, otherwise > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > ... > > > /* Loop starting from the root node to the current node. */ > > for (depth = fwnode_count_parents(fwnode); depth >= 0; depth--) { > > - struct fwnode_handle *__fwnode = > > - fwnode_get_nth_parent(fwnode, depth); > > + /* > > + * Only get a reference for other nodes (ie parents node). > > "parent's node" (doesn't look right)? Or "parent nodes"? > Will be changed to "parent nodes" in the next iteration. Best regards, Hervé
diff --git a/lib/vsprintf.c b/lib/vsprintf.c index afb88b24fa74..633f5481ac17 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -2110,15 +2110,20 @@ char *fwnode_full_name_string(struct fwnode_handle *fwnode, char *buf, /* Loop starting from the root node to the current node. */ for (depth = fwnode_count_parents(fwnode); depth >= 0; depth--) { - struct fwnode_handle *__fwnode = - fwnode_get_nth_parent(fwnode, depth); + /* + * Only get a reference for other nodes (ie parents node). + * fwnode refcount may be 0 here. + */ + struct fwnode_handle *__fwnode = depth ? + fwnode_get_nth_parent(fwnode, depth) : fwnode; buf = string(buf, end, fwnode_get_name_prefix(__fwnode), default_str_spec); buf = string(buf, end, fwnode_get_name(__fwnode), default_str_spec); - fwnode_handle_put(__fwnode); + if (depth) + fwnode_handle_put(__fwnode); } return buf;