Message ID | 20231110170121.769221-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:b129:0:b0:403:3b70:6f57 with SMTP id q9csp1282487vqs; Fri, 10 Nov 2023 09:55:44 -0800 (PST) X-Google-Smtp-Source: AGHT+IHSluhg6KqIYrG6J54gRsli5w55xTyfVl0uMQtC+iB5Eesa6sjr5l/2ujWta+5FpqUtYTMM X-Received: by 2002:a17:902:c403:b0:1cc:4fbe:9278 with SMTP id k3-20020a170902c40300b001cc4fbe9278mr9412plk.50.1699638944290; Fri, 10 Nov 2023 09:55:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1699638944; cv=none; d=google.com; s=arc-20160816; b=ktzyvxFhFH90fc1q2qKHIMHk+cCLY8AXG32GhMbhR5TFD1K1usYHCGzfbGnQPxV8hj vN3N/yUmo/XWxUs02SQoyzZTPSjczo4RdSUekLWeWqw/whcoNdkGmFH9xRMF8dpWl/LQ isQ9a6Pj7PsfyJtegzxKuY2j+XMH2zvd8JuZn1i+Y6HBHwCbEemKun+iotHlH2j0sY9T +bQj+JYi/y46/ttvGLzmw5WdSUuMuJ4FadpRFqBZRKcB3TwShYDcb4mOodXeb1ATGLzh eh2Ww5xJBs3mTimB5rqY4tf7u860ClbwP5S5VSaYqgO4kP8yEqM7P3sU8ddev//uZOT+ XVYw== 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=xEm3o8VU+39ALGHyQKeorPBmsousXOC90k2SfHr6l+8=; fh=3x0ITj2ynPmATxnczv095CmTJ3swMU71h50I4z+ObSE=; b=xaybtMUPVm+MIrs4XpbDYGL+8E4qILDW7UBw7RM49AjNR+R3Eh3EoL4a9/2tIRVcc1 UjiOc8iV4RM1cG3RqNFzdXGtJNiE+VknI/UH60PZcxHy91YQrkIS72EledpbYvI+GGBK OgHIaNS3YXZMXrj9ZZh/hcHrcAAq0zVhenpjiyoDtwx1klBeVnNznYx5Gj/H90MWHN5j oVw8ONjxvGmIIeMmnS8kaJY5gyY/ad974DhHEV6QfDqegmUvwswoHlwfs5y455c6ClWG YhvDmxVa8sGrNj/v3d+ZU6fEWbLBykorX9hXxTzNLAOW6nP9008qgo+C4uBAKrjUK8vH +0Aw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=akEddODt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 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 fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id b3-20020a170902d30300b001c76b4c349esi7697151plc.218.2023.11.10.09.55.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Nov 2023 09:55:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=akEddODt; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 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 fry.vger.email (Postfix) with ESMTP id 1838281CA67E; Fri, 10 Nov 2023 09:55:23 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231908AbjKJRyU (ORCPT <rfc822;lhua1029@gmail.com> + 30 others); Fri, 10 Nov 2023 12:54:20 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59782 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230119AbjKJRxT (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 10 Nov 2023 12:53:19 -0500 Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1E77742C22; Fri, 10 Nov 2023 09:01:27 -0800 (PST) Received: by mail.gandi.net (Postfix) with ESMTPA id C14F360005; Fri, 10 Nov 2023 17:01:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1699635686; 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=xEm3o8VU+39ALGHyQKeorPBmsousXOC90k2SfHr6l+8=; b=akEddODtZEANlh32ZjSuOqfH9OK2OytJ70Ew/Ly8Ab5NURRRE4ozxB0zfFCHCcZ7wuloAO 5XVpuDCbWUHw41I5C0TYDWV1e/cTXvG8jxDVqUMuEBnePr96w8Vrm5bMLAwhVooARZ/vEd rDfqqXPNDLxEXcaLHDkmJf+4mCesbVL1xmEx+jc2ZRBU1E7a8k6yMtJi9qnJuSGXi7jOL4 ka3EMTDWJGjasU4jtE03UiaQWb0hAma7qFqL6OLBWSP5DWPcScArcPnSuNCdobgYVrklqG 43PH6RASlV6flnurH5hzK7/5gk9GL1hseswLHho4YDPcDpD6wU573tpPfxpC4g== From: Herve Codina <herve.codina@bootlin.com> To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, "Rafael J. Wysocki" <rafael@kernel.org>, Saravana Kannan <saravanak@google.com>, Geert Uytterhoeven <geert+renesas@glider.be> 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] driver core: Avoid using fwnode in __fwnode_link_del() Date: Fri, 10 Nov 2023 18:01:20 +0100 Message-ID: <20231110170121.769221-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 fry.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 (fry.vger.email [0.0.0.0]); Fri, 10 Nov 2023 09:55:23 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782200606010263745 X-GMAIL-MSGID: 1782200606010263745 |
Series |
[1/1] driver core: Avoid using fwnode in __fwnode_link_del()
|
|
Commit Message
Herve Codina
Nov. 10, 2023, 5:01 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>
? 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 of_node is destroyed and so, of_node_release() is called
because the of_node refcount reached 0.
of_node_release() calls fwnode_links_purge() to purge the links and
ended with __fwnode_link_del() calls.
__fwnode_link_del calls pr_debug() to print the fwnodes (of_nodes)
involved in the link and so this call is done while one of them is no
more available (ie the one related to the of_node_release() call)
Remove the pr_debug() call to avoid the use of the links fwnode while
destroying the fwnode itself.
Fixes: ebd6823af378 ("driver core: Add debug logs when fwnode links are added/deleted")
Cc: stable@vger.kernel.org
Signed-off-by: Herve Codina <herve.codina@bootlin.com>
---
drivers/base/core.c | 2 --
1 file changed, 2 deletions(-)
Comments
On Fri, Nov 10, 2023 at 9:01 AM Herve Codina <herve.codina@bootlin.com> 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 of_node is destroyed and so, of_node_release() is called > because the of_node refcount reached 0. > of_node_release() calls fwnode_links_purge() to purge the links and > ended with __fwnode_link_del() calls. > __fwnode_link_del calls pr_debug() to print the fwnodes (of_nodes) > involved in the link and so this call is done while one of them is no > more available (ie the one related to the of_node_release() call) > > Remove the pr_debug() call to avoid the use of the links fwnode while > destroying the fwnode itself. > > Fixes: ebd6823af378 ("driver core: Add debug logs when fwnode links are added/deleted") > Cc: stable@vger.kernel.org > Signed-off-by: Herve Codina <herve.codina@bootlin.com> > --- > drivers/base/core.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/base/core.c b/drivers/base/core.c > index f4b09691998e..62088c663014 100644 > --- a/drivers/base/core.c > +++ b/drivers/base/core.c > @@ -109,8 +109,6 @@ int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup) > */ > static void __fwnode_link_del(struct fwnode_link *link) > { > - pr_debug("%pfwf Dropping the fwnode link to %pfwf\n", > - link->consumer, link->supplier); Valid issue, but a NACK for the patch. The pr_debug has been very handy, so I don't want to delete it. Also, the fwnode link can't get deleted before the supplier/consumer. If it is, I need to take a closer look as I'd expect the list_del() to cause corruption. My guess is that the %pfwf is traversing stuff that's causing an issue. But let me take a closer look next week when I'll be at LPC. -Saravana > list_del(&link->s_hook); > list_del(&link->c_hook); > kfree(link); > -- > 2.41.0 >
Hi Saravan, On Fri, 10 Nov 2023 12:09:02 -0800 Saravana Kannan <saravanak@google.com> wrote: > On Fri, Nov 10, 2023 at 9:01 AM Herve Codina <herve.codina@bootlin.com> 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 of_node is destroyed and so, of_node_release() is called > > because the of_node refcount reached 0. > > of_node_release() calls fwnode_links_purge() to purge the links and > > ended with __fwnode_link_del() calls. > > __fwnode_link_del calls pr_debug() to print the fwnodes (of_nodes) > > involved in the link and so this call is done while one of them is no > > more available (ie the one related to the of_node_release() call) > > > > Remove the pr_debug() call to avoid the use of the links fwnode while > > destroying the fwnode itself. > > > > Fixes: ebd6823af378 ("driver core: Add debug logs when fwnode links are added/deleted") > > Cc: stable@vger.kernel.org > > Signed-off-by: Herve Codina <herve.codina@bootlin.com> > > --- > > drivers/base/core.c | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/drivers/base/core.c b/drivers/base/core.c > > index f4b09691998e..62088c663014 100644 > > --- a/drivers/base/core.c > > +++ b/drivers/base/core.c > > @@ -109,8 +109,6 @@ int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup) > > */ > > static void __fwnode_link_del(struct fwnode_link *link) > > { > > - pr_debug("%pfwf Dropping the fwnode link to %pfwf\n", > > - link->consumer, link->supplier); > > Valid issue, but a NACK for the patch. > > The pr_debug has been very handy, so I don't want to delete it. Also, > the fwnode link can't get deleted before the supplier/consumer. If it > is, I need to take a closer look as I'd expect the list_del() to cause > corruption. My guess is that the %pfwf is traversing stuff that's > causing an issue. But let me take a closer look next week when I'll be > at LPC. > The issue is really related to print the full name (%pfwf) of the node been destroyed by of_node_release() due to refcount == 0. The issue does not appear with %pfwP. Looked at printk(). On %pfwf fwnode_handle_{get,put}() is called for current node and its parents whereas %pfwP does not call fwnode_handle_{get,put}() on the current node. A fix can probably be done at printk() level to avoid the fwnode_handle_{get,put}() calls for the current node in case of %pfwf. I will do a patch in this way instead of removing the pr_debug() call in __fwnode_link_del(). Best regards, Hervé
diff --git a/drivers/base/core.c b/drivers/base/core.c index f4b09691998e..62088c663014 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -109,8 +109,6 @@ int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup) */ static void __fwnode_link_del(struct fwnode_link *link) { - pr_debug("%pfwf Dropping the fwnode link to %pfwf\n", - link->consumer, link->supplier); list_del(&link->s_hook); list_del(&link->c_hook); kfree(link);