Message ID | 20231114110456.273844-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 t9csp1782038vqg; Tue, 14 Nov 2023 03:06:09 -0800 (PST) X-Google-Smtp-Source: AGHT+IFyfEIcw2a2y+DQ3FEKdPRQ9wNlIWfdkiFsKVdmOgGlVslIcdZbcN5/V9ZfhYAc31poh0QW X-Received: by 2002:a17:90b:38c8:b0:280:15a3:89c3 with SMTP id nn8-20020a17090b38c800b0028015a389c3mr7113075pjb.27.1699959968839; Tue, 14 Nov 2023 03:06:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699959968; cv=none; d=google.com; s=arc-20160816; b=tucNuLUTj0wdoF1KNNDSa+23io8QSNMhlS7r2uwprTKh66Kp4OO0D2J45wUmtufJFb LpKDfwPUOVOzv4DchX4qjjTc6V0XhBbHTpwZXAAdkirTxjGxcLisb1q+7tOS7PC50/+J XwSKlZyG7rVlyA40yMzUuGauqJKxDD2v0QPEl8KHT5YbzKAk5IOqWI8WaIkUTBFv2Yj8 3pl1pNfcYVSEp/VUTU5mzGIT7p+pgiZxaee9OjGK12IVPNU5Vb+QABGlT9RbCpcaCBkH hBRbS4QpyKsw6LF5ZTOHKurWFOXcb4H6uXcnpHbwtx2nR3nWu0EhLkYY704CFnNHvL/G 0N7w== 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=Kd3NZ8a4zLSdrVW2pyTXkblkfiqMqtu4eWyUiU4OKDc=; fh=inKJ5kKAsUU4c8hT0Ljb/CSuao2S4RjDzYxLdUfmU1Y=; b=jL2KHf+NgHe9heVx6zFGpGsFDj4epuOF/0slLwEnw8jkPGb3P62aqdliIrrjY5bdhg YaSX258BWDAZmIbc5ODv6TKrwVCPleBhnvpX4d0I1pbecTrsEYpbIJqcfwQgb+WVmsBL WK2BqCDmYzPrhejBE9aNasTVZnRo4KR8AsoTZdbh1Pnrg2fQZV6VV3eVf3gHAeiugPE6 N3dJUPRAAmK5U68VqDR/RiyhYy4hoeWiw3P8wVQmIrGg9wz0wZXvf+zrZF6Hg/yC/95J gJdHIQ4pXKVr+Ru43NHKxstGGMsIs9KjAuFyqDPB5oZeVxlVNPeMOUbbpyK+LqLES+Ze ePMA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=WNF3rj0K; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 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 groat.vger.email (groat.vger.email. [2620:137:e000::3:5]) by mx.google.com with ESMTPS id mp6-20020a17090b190600b002801b7112f5si12442844pjb.86.2023.11.14.03.06.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 Nov 2023 03:06:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5; Authentication-Results: mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=WNF3rj0K; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 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 groat.vger.email (Postfix) with ESMTP id D77568070706; Tue, 14 Nov 2023 03:05:23 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at groat.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232767AbjKNLFI (ORCPT <rfc822;lhua1029@gmail.com> + 29 others); Tue, 14 Nov 2023 06:05:08 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230434AbjKNLFG (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 14 Nov 2023 06:05:06 -0500 Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 11BA1D9; Tue, 14 Nov 2023 03:05:01 -0800 (PST) Received: by mail.gandi.net (Postfix) with ESMTPA id 77B05FF806; Tue, 14 Nov 2023 11:04:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1699959900; 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=Kd3NZ8a4zLSdrVW2pyTXkblkfiqMqtu4eWyUiU4OKDc=; b=WNF3rj0KHC0t0bMTi+avu+bqHhgub6Djlh3UWFLgEmH1Vzcw3MPp1WraG3RvCxBJqHq995 +mV7YRfvrh8R+GDj2+VW/MIa4OOPC5lfdNPWr9RHpkSwvMtbdYGby25fHikv667bMzvroU 6RgFCVJAxmmk5i61mJ48++aeEobralqjLN6s3/33Bxi0Iyr510/UJnbJKQomk7+AbGwt1E jc9QTCGkJVygVTgFD/zGHm2qe1eFlG9FzFmXsPXjLLPQ4FqF4cSnAU6NFHi+PNHH9W+ZKu vdfEQn1vGTbC1IeHtqay8i12kigbz5zlGQGwoj8Avho46ltDS4+KKld9wGlZXw== 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 1/1] lib/vsprintf: Fix %pfwf when current node refcount == 0 Date: Tue, 14 Nov 2023 12:04:56 +0100 Message-ID: <20231114110456.273844-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 groat.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 (groat.vger.email [0.0.0.0]); Tue, 14 Nov 2023 03:05:23 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782537224586484262 X-GMAIL-MSGID: 1782537224586484262 |
Series |
[1/1] lib/vsprintf: Fix %pfwf when current node refcount == 0
|
|
Commit Message
Herve Codina
Nov. 14, 2023, 11:04 a.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>
? refcount_warn_saturate+0xe5/0x110
? __warn+0x81/0x130
? refcount_warn_saturate+0xe5/0x110
? report_bug+0x191/0x1c0
? srso_alias_return_thunk+0x5/0x7f
? prb_read_valid+0x1b/0x30
? handle_bug+0x3c/0x80
? exc_invalid_op+0x17/0x70
? asm_exc_invalid_op+0x1a/0x20
? refcount_warn_saturate+0xe5/0x110
kobject_get+0x68/0x70
of_node_get+0x1e/0x30
of_fwnode_get+0x28/0x40
fwnode_full_name_string+0x34/0x90
fwnode_string+0xdb/0x140
vsnprintf+0x17b/0x630
va_format.isra.0+0x71/0x130
vsnprintf+0x17b/0x630
vprintk_store+0x162/0x4d0
? srso_alias_return_thunk+0x5/0x7f
? srso_alias_return_thunk+0x5/0x7f
? srso_alias_return_thunk+0x5/0x7f
? try_to_wake_up+0x9c/0x620
? rwsem_mark_wake+0x1b2/0x310
vprintk_emit+0xe4/0x2b0
_printk+0x5c/0x80
__dynamic_pr_debug+0x131/0x160
? srso_alias_return_thunk+0x5/0x7f
__fwnode_link_del+0x25/0xa0
fwnode_links_purge+0x39/0xb0
of_node_release+0xd9/0x180
kobject_put+0x7b/0x190
...
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>
---
lib/vsprintf.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
Comments
Hi Herve, Thanks for the patch. On Tue, Nov 14, 2023 at 12:04:56PM +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> > ? refcount_warn_saturate+0xe5/0x110 > ? __warn+0x81/0x130 > ? refcount_warn_saturate+0xe5/0x110 > ? report_bug+0x191/0x1c0 > ? srso_alias_return_thunk+0x5/0x7f > ? prb_read_valid+0x1b/0x30 > ? handle_bug+0x3c/0x80 > ? exc_invalid_op+0x17/0x70 > ? asm_exc_invalid_op+0x1a/0x20 > ? refcount_warn_saturate+0xe5/0x110 > kobject_get+0x68/0x70 > of_node_get+0x1e/0x30 > of_fwnode_get+0x28/0x40 > fwnode_full_name_string+0x34/0x90 > fwnode_string+0xdb/0x140 > vsnprintf+0x17b/0x630 > va_format.isra.0+0x71/0x130 > vsnprintf+0x17b/0x630 > vprintk_store+0x162/0x4d0 > ? srso_alias_return_thunk+0x5/0x7f > ? srso_alias_return_thunk+0x5/0x7f > ? srso_alias_return_thunk+0x5/0x7f > ? try_to_wake_up+0x9c/0x620 > ? rwsem_mark_wake+0x1b2/0x310 > vprintk_emit+0xe4/0x2b0 > _printk+0x5c/0x80 > __dynamic_pr_debug+0x131/0x160 > ? srso_alias_return_thunk+0x5/0x7f > __fwnode_link_del+0x25/0xa0 > fwnode_links_purge+0x39/0xb0 > of_node_release+0xd9/0x180 > kobject_put+0x7b/0x190 > ... > > 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> > --- > lib/vsprintf.c | 14 ++++++++++++-- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/lib/vsprintf.c b/lib/vsprintf.c > index afb88b24fa74..74ef229c2783 100644 > --- a/lib/vsprintf.c > +++ b/lib/vsprintf.c > @@ -2108,8 +2108,8 @@ char *fwnode_full_name_string(struct fwnode_handle *fwnode, char *buf, > { > int depth; > > - /* Loop starting from the root node to the current node. */ > - for (depth = fwnode_count_parents(fwnode); depth >= 0; depth--) { > + /* Loop starting from the root node to the parent of current node. */ > + for (depth = fwnode_count_parents(fwnode); depth > 0; depth--) { > struct fwnode_handle *__fwnode = > fwnode_get_nth_parent(fwnode, depth); How about, without changing the loop: /* * Only get a reference for other nodes, fwnode refcount * may be 0 here. */ struct fwnode_handle *__fwnode = depth ? fwnode_get_nth_parent(fwnode, depth) : fwnode; > > @@ -2121,6 +2121,16 @@ char *fwnode_full_name_string(struct fwnode_handle *fwnode, char *buf, > fwnode_handle_put(__fwnode); And: if (__fwnode != fwnode) fwnode_handle_put(__fwnode); > } > > + /* Handle current node without calling fwnode_handle_{get,put}(). > + * This allows to print the full node name while the current node is > + * being destroyed (ie print from a function called because of > + * refcount == 0) without any refcount issues. > + */ > + buf = string(buf, end, fwnode_get_name_prefix(fwnode), > + default_str_spec); > + buf = string(buf, end, fwnode_get_name(fwnode), > + default_str_spec); It'd avoid duplicating this part, too, which I find worth the while. > + > return buf; > } >
Hi Sakari, On Tue, 14 Nov 2023 11:28:43 +0000 Sakari Ailus <sakari.ailus@linux.intel.com> wrote: > > --- a/lib/vsprintf.c > > +++ b/lib/vsprintf.c > > @@ -2108,8 +2108,8 @@ char *fwnode_full_name_string(struct fwnode_handle *fwnode, char *buf, > > { > > int depth; > > > > - /* Loop starting from the root node to the current node. */ > > - for (depth = fwnode_count_parents(fwnode); depth >= 0; depth--) { > > + /* Loop starting from the root node to the parent of current node. */ > > + for (depth = fwnode_count_parents(fwnode); depth > 0; depth--) { > > struct fwnode_handle *__fwnode = > > fwnode_get_nth_parent(fwnode, depth); > > How about, without changing the loop: > > /* > * Only get a reference for other nodes, fwnode refcount > * may be 0 here. > */ > struct fwnode_handle *__fwnode = > depth ? fwnode_get_nth_parent(fwnode, depth) : fwnode; > > > > > @@ -2121,6 +2121,16 @@ char *fwnode_full_name_string(struct fwnode_handle *fwnode, char *buf, > > fwnode_handle_put(__fwnode); > > And: > > if (__fwnode != fwnode) > fwnode_handle_put(__fwnode); > Sure. I will just change to keep the both tests consistent. I mean test with depth or test with __fwnode != fwnode but avoid mixing them. What do you think about testing using depth in all cases and so: if (depth) fwnode_handle_put(__fwnode); Best regards, Hervé
Hi Herve, On Tue, Nov 14, 2023 at 12:48:32PM +0100, Herve Codina wrote: > Hi Sakari, > > On Tue, 14 Nov 2023 11:28:43 +0000 > Sakari Ailus <sakari.ailus@linux.intel.com> wrote: > > > > --- a/lib/vsprintf.c > > > +++ b/lib/vsprintf.c > > > @@ -2108,8 +2108,8 @@ char *fwnode_full_name_string(struct fwnode_handle *fwnode, char *buf, > > > { > > > int depth; > > > > > > - /* Loop starting from the root node to the current node. */ > > > - for (depth = fwnode_count_parents(fwnode); depth >= 0; depth--) { > > > + /* Loop starting from the root node to the parent of current node. */ > > > + for (depth = fwnode_count_parents(fwnode); depth > 0; depth--) { > > > struct fwnode_handle *__fwnode = > > > fwnode_get_nth_parent(fwnode, depth); > > > > How about, without changing the loop: > > > > /* > > * Only get a reference for other nodes, fwnode refcount > > * may be 0 here. > > */ > > struct fwnode_handle *__fwnode = > > depth ? fwnode_get_nth_parent(fwnode, depth) : fwnode; > > > > > > > > @@ -2121,6 +2121,16 @@ char *fwnode_full_name_string(struct fwnode_handle *fwnode, char *buf, > > > fwnode_handle_put(__fwnode); > > > > And: > > > > if (__fwnode != fwnode) > > fwnode_handle_put(__fwnode); > > > > Sure. > I will just change to keep the both tests consistent. > I mean test with depth or test with __fwnode != fwnode but avoid > mixing them. > > What do you think about testing using depth in all cases and so: > if (depth) > fwnode_handle_put(__fwnode); I'd compare fwnodes as we're putting __fwnode since we've gotten a reference to fwnodes different from fwnode. I don't have a strong opinion on this though, up to you.
On Tue, Nov 14, 2023 at 12:04:56PM +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> > ? refcount_warn_saturate+0xe5/0x110 > ? __warn+0x81/0x130 > ? refcount_warn_saturate+0xe5/0x110 > ? report_bug+0x191/0x1c0 > ? srso_alias_return_thunk+0x5/0x7f > ? prb_read_valid+0x1b/0x30 > ? handle_bug+0x3c/0x80 > ? exc_invalid_op+0x17/0x70 > ? asm_exc_invalid_op+0x1a/0x20 > ? refcount_warn_saturate+0xe5/0x110 > kobject_get+0x68/0x70 > of_node_get+0x1e/0x30 > of_fwnode_get+0x28/0x40 > fwnode_full_name_string+0x34/0x90 > fwnode_string+0xdb/0x140 > vsnprintf+0x17b/0x630 > va_format.isra.0+0x71/0x130 > vsnprintf+0x17b/0x630 > vprintk_store+0x162/0x4d0 > ? srso_alias_return_thunk+0x5/0x7f > ? srso_alias_return_thunk+0x5/0x7f > ? srso_alias_return_thunk+0x5/0x7f > ? try_to_wake_up+0x9c/0x620 > ? rwsem_mark_wake+0x1b2/0x310 > vprintk_emit+0xe4/0x2b0 > _printk+0x5c/0x80 > __dynamic_pr_debug+0x131/0x160 > ? srso_alias_return_thunk+0x5/0x7f > __fwnode_link_del+0x25/0xa0 > fwnode_links_purge+0x39/0xb0 > of_node_release+0xd9/0x180 > kobject_put+0x7b/0x190 > ... Please, do not put so many unrelated lines of backtrace in the commit message. Leave only the important ones (the Submitting Patches document suggests some like ~3-5 lines only). > 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.
On Tue, 14 Nov 2023 15:12:47 +0200 Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > On Tue, Nov 14, 2023 at 12:04:56PM +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> > > ? refcount_warn_saturate+0xe5/0x110 > > ? __warn+0x81/0x130 > > ? refcount_warn_saturate+0xe5/0x110 > > ? report_bug+0x191/0x1c0 > > ? srso_alias_return_thunk+0x5/0x7f > > ? prb_read_valid+0x1b/0x30 > > ? handle_bug+0x3c/0x80 > > ? exc_invalid_op+0x17/0x70 > > ? asm_exc_invalid_op+0x1a/0x20 > > ? refcount_warn_saturate+0xe5/0x110 > > kobject_get+0x68/0x70 > > of_node_get+0x1e/0x30 > > of_fwnode_get+0x28/0x40 > > fwnode_full_name_string+0x34/0x90 > > fwnode_string+0xdb/0x140 > > vsnprintf+0x17b/0x630 > > va_format.isra.0+0x71/0x130 > > vsnprintf+0x17b/0x630 > > vprintk_store+0x162/0x4d0 > > ? srso_alias_return_thunk+0x5/0x7f > > ? srso_alias_return_thunk+0x5/0x7f > > ? srso_alias_return_thunk+0x5/0x7f > > ? try_to_wake_up+0x9c/0x620 > > ? rwsem_mark_wake+0x1b2/0x310 > > vprintk_emit+0xe4/0x2b0 > > _printk+0x5c/0x80 > > __dynamic_pr_debug+0x131/0x160 > > ? srso_alias_return_thunk+0x5/0x7f > > __fwnode_link_del+0x25/0xa0 > > fwnode_links_purge+0x39/0xb0 > > of_node_release+0xd9/0x180 > > kobject_put+0x7b/0x190 > > ... > > Please, do not put so many unrelated lines of backtrace in the commit message. > Leave only the important ones (the Submitting Patches document suggests some > like ~3-5 lines only). Ok, I will remove some of them. Best regards, Hervé
On Tue, Nov 14, 2023 at 02:19:34PM +0100, Herve Codina wrote: > On Tue, 14 Nov 2023 15:12:47 +0200 > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > On Tue, Nov 14, 2023 at 12:04:56PM +0100, Herve Codina wrote: > > > A refcount issue can appeared in __fwnode_link_del() due to the > > > pr_debug() call: ---8<--- > > > WARNING: CPU: 0 PID: 901 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 > > > Call Trace: > > > ? refcount_warn_saturate+0xe5/0x110 ... > > > 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 ... ---8<--- > > Please, do not put so many unrelated lines of backtrace in the commit message. > > Leave only the important ones (the Submitting Patches document suggests some > > like ~3-5 lines only). > > Ok, I will remove some of them. Thanks (my suggestion is above).
On Tue, Nov 14, 2023 at 03:27:43PM +0200, Andy Shevchenko wrote: > On Tue, Nov 14, 2023 at 02:19:34PM +0100, Herve Codina wrote: > > On Tue, 14 Nov 2023 15:12:47 +0200 > > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote: > > > On Tue, Nov 14, 2023 at 12:04:56PM +0100, Herve Codina wrote: > > > > A refcount issue can appeared in __fwnode_link_del() due to the > > > > pr_debug() call: ---8<--- > > > > WARNING: CPU: 0 PID: 901 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110 > > > > Call Trace: > > > > ? refcount_warn_saturate+0xe5/0x110 > > ... These are actually not needed as duplicating WARNING above. > > > > 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 > ... ---8<--- > > > Please, do not put so many unrelated lines of backtrace in the commit message. > > > Leave only the important ones (the Submitting Patches document suggests some > > > like ~3-5 lines only). > > > > Ok, I will remove some of them. > > Thanks (my suggestion is above).
diff --git a/lib/vsprintf.c b/lib/vsprintf.c index afb88b24fa74..74ef229c2783 100644 --- a/lib/vsprintf.c +++ b/lib/vsprintf.c @@ -2108,8 +2108,8 @@ char *fwnode_full_name_string(struct fwnode_handle *fwnode, char *buf, { int depth; - /* Loop starting from the root node to the current node. */ - for (depth = fwnode_count_parents(fwnode); depth >= 0; depth--) { + /* Loop starting from the root node to the parent of current node. */ + for (depth = fwnode_count_parents(fwnode); depth > 0; depth--) { struct fwnode_handle *__fwnode = fwnode_get_nth_parent(fwnode, depth); @@ -2121,6 +2121,16 @@ char *fwnode_full_name_string(struct fwnode_handle *fwnode, char *buf, fwnode_handle_put(__fwnode); } + /* Handle current node without calling fwnode_handle_{get,put}(). + * This allows to print the full node name while the current node is + * being destroyed (ie print from a function called because of + * refcount == 0) without any refcount issues. + */ + buf = string(buf, end, fwnode_get_name_prefix(fwnode), + default_str_spec); + buf = string(buf, end, fwnode_get_name(fwnode), + default_str_spec); + return buf; }