Message ID | 20230117144929.423089-1-clement.leger@bootlin.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp1800802wrn; Tue, 17 Jan 2023 06:59:59 -0800 (PST) X-Google-Smtp-Source: AMrXdXtembkEZ4DJkuMwgve9T5T+WcLn9cBOTW3X8uY8HptN4TQhcqZb/A0fZXgSKa6J+t7mpilR X-Received: by 2002:a17:906:80d8:b0:871:e9a0:ebab with SMTP id a24-20020a17090680d800b00871e9a0ebabmr3207674ejx.31.1673967599411; Tue, 17 Jan 2023 06:59:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673967599; cv=none; d=google.com; s=arc-20160816; b=YU/sgRP026pZR0XivSAciHXbQ9QgKmH2uXSi3xLNcxdxxBqz/3rWp6g1Lyq61dG6c0 4HvsXP6HIBOZSVxA1mG3srGxbcvx30NPOtcZ5PfrQXoAAZSigXLVyeNLKhYvuFxwnBqL TLb6vRd/Y15/cVVREgIaKw4c1ffkXWlRhg7sCPE0ahLlSQUFVwqApTpFJxLiMTjTacbn BTX7rSvxYrH1xCMS2XkfTWBebXwC+dMRFTHAOxvxHoL/puOViNLDRx+o5e6ktUn6T1WD b/N4wO7G3bhdWUbQtCCvy4PhZIb4MhrTjdZpQbP7Ba1JK2BP1Kspl2h5l0WKpGh4naQ/ OCXg== 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=/cUfcf/QAMo2QYFX45p/y6/QB8475Ld6Zy/Yz1xqXFw=; b=qvgNpQ9C2C27jbrJJ9u0ABbX2+Q0ow/K3A47jN12LDndQsEQA+Y/oXH54ejttgihLz N5EiSnLHlosxNDXGIK9D2FV6MSumKpTL5dsdDLM1nhHjgFA4EFYgKJ6LfTgyPtzTwenk Z4rI4nGN60TuGhIq4BUn2GQyA0rlvaiDEAe+3KtolXYU55DqiVTD5sec+ykTzi8X5kLQ DOEgbg+kvgEiJ9b73X30nawEmcxMpmCzhBxLoyvYR83L65lD8IXqyPv7kBnhf4wruWRZ 6pZA6g9Qu1DZiDJ7vi7okJYq7Rp73gmxVIRwS7QDpnbHWKmCdoTiBU3FGLgUD3y9rBq0 /OwQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=Mq+6Fxmj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ae10-20020a17090725ca00b007ae09db5f4esi34600427ejc.657.2023.01.17.06.59.35; Tue, 17 Jan 2023 06:59:59 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@bootlin.com header.s=gm1 header.b=Mq+6Fxmj; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=bootlin.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232680AbjAQOrh (ORCPT <rfc822;pfffrao@gmail.com> + 99 others); Tue, 17 Jan 2023 09:47:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34314 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231955AbjAQOrb (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 17 Jan 2023 09:47:31 -0500 Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9A6B534C1B; Tue, 17 Jan 2023 06:47:29 -0800 (PST) Received: (Authenticated sender: clement.leger@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id B1FCF240013; Tue, 17 Jan 2023 14:47:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1673966848; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=/cUfcf/QAMo2QYFX45p/y6/QB8475Ld6Zy/Yz1xqXFw=; b=Mq+6FxmjcHlOqY5XywZGT2jCVdK0oUcGNv5QalgRxYRvmbE6w2Kc+pKimT7Uv5+BHEyWXG LwwpgTBRPexNHsKUcdYcw4BVQwT9YROK2IiYG2ji6L93rm52wPxNBUfBl5sk8+GcyRPzez LzIXBHOji8Uo9UgFR32ZRo2OxVHwFFeUF4ShSDr362vkHN+IqgS7XT+F+9U/0oVjJCorTh R/clqcpuUDTjwH9evgegoBIpkdElW2ORr3KgRhC61Jg0eJo57rsDgB38QGavBd+HVTFEYO mXdMe2NS2oewxs8zVUWpOSy9HynfxycbKJSqcvys5fIccy7Hnh8zcMg2x53fCA== From: =?utf-8?b?Q2zDqW1lbnQgTMOpZ2Vy?= <clement.leger@bootlin.com> To: Rob Herring <robh+dt@kernel.org>, Frank Rowand <frowand.list@gmail.com> Cc: =?utf-8?b?Q2zDqW1lbnQgTMOpZ2Vy?= <clement.leger@bootlin.com>, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH] of/irq: add missing of_node_put() for interrupt parent node Date: Tue, 17 Jan 2023 15:49:29 +0100 Message-Id: <20230117144929.423089-1-clement.leger@bootlin.com> X-Mailer: git-send-email 2.39.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1755282249277072116?= X-GMAIL-MSGID: =?utf-8?q?1755282249277072116?= |
Series |
of/irq: add missing of_node_put() for interrupt parent node
|
|
Commit Message
Clément Léger
Jan. 17, 2023, 2:49 p.m. UTC
After calling of_irq_parse_one(), the node provided in the of_phandle_args
has a refcount increment by one. Add missing of_node_put in of_irq_get()
to decrement the refcount once used.
Signed-off-by: Clément Léger <clement.leger@bootlin.com>
---
While debugging a refcount problem with OF_DYNAMIC enabled (which is
actually the only case were node refcount are really used), I noticed that
platform_get_irq() was actually incrementing the refcount of an interrupt
controller node. Digging into that function shows that it calls
of_irq_get() which calls of_irq_parse_one() and finally of_irq_parse_raw().
Since it seems sane that the node returned in the of_phandle_args has a
refcount incremented, I thought it is better to put the of_node_put() in
the user even though it was hard to find any user doing so.
drivers/of/irq.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
Comments
On Tue, 17 Jan 2023 15:49:29 +0100, Clément Léger wrote: > After calling of_irq_parse_one(), the node provided in the of_phandle_args > has a refcount increment by one. Add missing of_node_put in of_irq_get() > to decrement the refcount once used. > > Signed-off-by: Clément Léger <clement.leger@bootlin.com> > --- > > While debugging a refcount problem with OF_DYNAMIC enabled (which is > actually the only case were node refcount are really used), I noticed that > platform_get_irq() was actually incrementing the refcount of an interrupt > controller node. Digging into that function shows that it calls > of_irq_get() which calls of_irq_parse_one() and finally of_irq_parse_raw(). > Since it seems sane that the node returned in the of_phandle_args has a > refcount incremented, I thought it is better to put the of_node_put() in > the user even though it was hard to find any user doing so. > > drivers/of/irq.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > Applied, thanks!
+Saravana, Jean On Tue, Jan 17, 2023 at 8:47 AM Clément Léger <clement.leger@bootlin.com> wrote: > > After calling of_irq_parse_one(), the node provided in the of_phandle_args > has a refcount increment by one. Add missing of_node_put in of_irq_get() > to decrement the refcount once used. > > Signed-off-by: Clément Léger <clement.leger@bootlin.com> > --- > > While debugging a refcount problem with OF_DYNAMIC enabled (which is > actually the only case were node refcount are really used), I noticed that > platform_get_irq() was actually incrementing the refcount of an interrupt > controller node. Digging into that function shows that it calls > of_irq_get() which calls of_irq_parse_one() and finally of_irq_parse_raw(). > Since it seems sane that the node returned in the of_phandle_args has a > refcount incremented, I thought it is better to put the of_node_put() in > the user even though it was hard to find any user doing so. While investigating [1], I stumbled back on this. Was the failing case you had using interrupts-extended? It looks to me like that path has a get, but the 'interrupts' path does not. If so, this change is wrong. Rob [1] https://lore.kernel.org/all/20230228174019.4004581-1-jjhiblot@traphandler.com/ > > drivers/of/irq.c | 12 +++++++++--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/drivers/of/irq.c b/drivers/of/irq.c > index e9bf5236ed89..174900072c18 100644 > --- a/drivers/of/irq.c > +++ b/drivers/of/irq.c > @@ -438,10 +438,16 @@ int of_irq_get(struct device_node *dev, int index) > return rc; > > domain = irq_find_host(oirq.np); > - if (!domain) > - return -EPROBE_DEFER; > + if (!domain) { > + rc = -EPROBE_DEFER; > + goto out; > + } > > - return irq_create_of_mapping(&oirq); > + rc = irq_create_of_mapping(&oirq); > +out: > + of_node_put(oirq.np); > + > + return rc; > } > EXPORT_SYMBOL_GPL(of_irq_get); > > -- > 2.39.0 >
Le Tue, 28 Feb 2023 17:14:18 -0600, Rob Herring <robh+dt@kernel.org> a écrit : > +Saravana, Jean > > On Tue, Jan 17, 2023 at 8:47 AM Clément Léger <clement.leger@bootlin.com> wrote: > > > > After calling of_irq_parse_one(), the node provided in the of_phandle_args > > has a refcount increment by one. Add missing of_node_put in of_irq_get() > > to decrement the refcount once used. > > > > Signed-off-by: Clément Léger <clement.leger@bootlin.com> > > --- > > > > While debugging a refcount problem with OF_DYNAMIC enabled (which is > > actually the only case were node refcount are really used), I noticed that > > platform_get_irq() was actually incrementing the refcount of an interrupt > > controller node. Digging into that function shows that it calls > > of_irq_get() which calls of_irq_parse_one() and finally of_irq_parse_raw(). > > Since it seems sane that the node returned in the of_phandle_args has a > > refcount incremented, I thought it is better to put the of_node_put() in > > the user even though it was hard to find any user doing so. > > While investigating [1], I stumbled back on this. Was the failing case > you had using interrupts-extended? It looks to me like that path has a > get, but the 'interrupts' path does not. If so, this change is wrong. In my case, it was with a classic "interrupts" property. I can take another look at the internal code to be sure this fix is correct. Clément > > Rob > > [1] https://lore.kernel.org/all/20230228174019.4004581-1-jjhiblot@traphandler.com/ > > > > > > drivers/of/irq.c | 12 +++++++++--- > > 1 file changed, 9 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/of/irq.c b/drivers/of/irq.c > > index e9bf5236ed89..174900072c18 100644 > > --- a/drivers/of/irq.c > > +++ b/drivers/of/irq.c > > @@ -438,10 +438,16 @@ int of_irq_get(struct device_node *dev, int index) > > return rc; > > > > domain = irq_find_host(oirq.np); > > - if (!domain) > > - return -EPROBE_DEFER; > > + if (!domain) { > > + rc = -EPROBE_DEFER; > > + goto out; > > + } > > > > - return irq_create_of_mapping(&oirq); > > + rc = irq_create_of_mapping(&oirq); > > +out: > > + of_node_put(oirq.np); > > + > > + return rc; > > } > > EXPORT_SYMBOL_GPL(of_irq_get); > > > > -- > > 2.39.0 > >
diff --git a/drivers/of/irq.c b/drivers/of/irq.c index e9bf5236ed89..174900072c18 100644 --- a/drivers/of/irq.c +++ b/drivers/of/irq.c @@ -438,10 +438,16 @@ int of_irq_get(struct device_node *dev, int index) return rc; domain = irq_find_host(oirq.np); - if (!domain) - return -EPROBE_DEFER; + if (!domain) { + rc = -EPROBE_DEFER; + goto out; + } - return irq_create_of_mapping(&oirq); + rc = irq_create_of_mapping(&oirq); +out: + of_node_put(oirq.np); + + return rc; } EXPORT_SYMBOL_GPL(of_irq_get);