Message ID | 20230202151554.2310273-1-gregkh@linuxfoundation.org |
---|---|
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 s9csp300862wrn; Thu, 2 Feb 2023 07:23:15 -0800 (PST) X-Google-Smtp-Source: AK7set9XZuEDDyeClXIchcstOwF3BnfFs6ZUKerFqpOZp0UQA3UhKKZ4uAuZWoXa6xcnRdoNBdLI X-Received: by 2002:a17:902:f091:b0:194:62d9:9a86 with SMTP id p17-20020a170902f09100b0019462d99a86mr4985014pla.59.1675351395193; Thu, 02 Feb 2023 07:23:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675351395; cv=none; d=google.com; s=arc-20160816; b=WJ/Sc1R1DxTs2tg5ECxGW14xti5gCFhYyDqC8y58riEloo2d/03JjgUbPtcqY1ChlR Yt+taEm0NCAmYNi7690OMETF2Z1v7wSTyicWHwchLrfdu5/6EXQPYhLQMs6XY5leNQ5M M3LZcDs5ZJpl4qI3wHjaN6uMxohRUpyMpykWJO1KVqog1fqOHGKLbvEGvUlCOh1aWoTy 9vXqc1JFJYXaByRFBTizJK8dVb3TgT8zlxVv6fXw/h8uZwIGHAmNDPLbxkhLdZpFBaUY xRnLiMFhKa4coE4TngXlcTVUWhd4rAh2NfZZyOehwWYvcXUsZupoBJ7VPLjg1P2qFqUD ZL9A== 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=vW8nifnBajpV8goBlVHbQ2h5u5seTAEPDjAcqFTBrFk=; b=tVmKN4ryA1D42E0jp0SEYt5bf1PdtoPKRL/mxVUTZe++Hgy7T6Gk4CwDCQFHfOR3z/ NWwWatnoCL5RJI3redBz1KkuYd7fAu8fEWL6o+/SQRbKapfCuaOhCW9slvR7SB5jVOFa AZ4ISxG90pRBaOpG4kPH2z7965OG/lFtaYlWuQs2JRM9WqmNppkcC38yzCSS23GuEiPu D2hL7b67L3ukWSr/ebCOIeufk8c5bHP2zEiGURZslAFTyFbwBkOuDh2C7T/a+TxxCd4u dKtVuLOarboaYxWWkicKGGKF5u9Y2gEyz4QGZKCY1gCcN1VlA0UKDfJv3PPjDahrb86J FelQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=T9UJifDL; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p15-20020a1709028a8f00b001961e8b3a83si5357722plo.243.2023.02.02.07.23.03; Thu, 02 Feb 2023 07:23:15 -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=@linuxfoundation.org header.s=korg header.b=T9UJifDL; 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=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232089AbjBBPQF (ORCPT <rfc822;il.mystafa@gmail.com> + 99 others); Thu, 2 Feb 2023 10:16:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60122 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232305AbjBBPP7 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 2 Feb 2023 10:15:59 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF29A80FB6 for <linux-kernel@vger.kernel.org>; Thu, 2 Feb 2023 07:15:58 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8A2A761BCE for <linux-kernel@vger.kernel.org>; Thu, 2 Feb 2023 15:15:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6BA4BC433EF; Thu, 2 Feb 2023 15:15:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1675350958; bh=d2XBw40Rb8AxKHAimNs7K4RmZkV7XL+DsegnFjh7AAE=; h=From:To:Cc:Subject:Date:From; b=T9UJifDL74S8Dd1VjvaNyBPy5pllWMxeOl52Zrugg1whBH7JPnZZ6+HHphLb53nVs pluNnjy3yiaf2Ese25sGm5bXu4dk/0GBumaPbRg2knqCc5yLZ/qI8S50co4o+1AL0K IBuJlz5+lbJzQD+5c3YIY1EYoLirc6XdiK2Un80g= From: Greg Kroah-Hartman <gregkh@linuxfoundation.org> To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Marc Zyngier <maz@kernel.org>, Thomas Gleixner <tglx@linutronix.de> Subject: [PATCH] kernel/irq/irqdomain.c: fix memory leak with using debugfs_lookup() Date: Thu, 2 Feb 2023 16:15:54 +0100 Message-Id: <20230202151554.2310273-1-gregkh@linuxfoundation.org> X-Mailer: git-send-email 2.39.1 MIME-Version: 1.0 X-Developer-Signature: v=1; a=openpgp-sha256; l=991; i=gregkh@linuxfoundation.org; h=from:subject; bh=d2XBw40Rb8AxKHAimNs7K4RmZkV7XL+DsegnFjh7AAE=; b=owGbwMvMwCRo6H6F97bub03G02pJDMm3L6/68bM+Vnyu2aluni3XX5bLnXq/dun7h0xrOZJtLofc vzRzZkcsC4MgE4OsmCLLl208R/dXHFL0MrQ9DTOHlQlkCAMXpwBMpHoTw4Ljc9py1378cHP9uY0713 EIOzpxTvBmmJ/0iPNzrGyYop3T25OMTuH9zG8PnQYA X-Developer-Key: i=gregkh@linuxfoundation.org; a=openpgp; fpr=F4B60CC5BF78C2214A313DCB3147D40DDB2DFB29 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, 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?1756733264365007376?= X-GMAIL-MSGID: =?utf-8?q?1756733264365007376?= |
Series |
kernel/irq/irqdomain.c: fix memory leak with using debugfs_lookup()
|
|
Commit Message
Greg KH
Feb. 2, 2023, 3:15 p.m. UTC
When calling debugfs_lookup() the result must have dput() called on it,
otherwise the memory will leak over time. To make things simpler, just
call debugfs_lookup_and_remove() instead which handles all of the logic
at once.
Cc: Marc Zyngier <maz@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/irq/irqdomain.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Thu, 02 Feb 2023 15:15:54 +0000, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > When calling debugfs_lookup() the result must have dput() called on it, > otherwise the memory will leak over time. To make things simpler, just > call debugfs_lookup_and_remove() instead which handles all of the logic > at once. > > Cc: Marc Zyngier <maz@kernel.org> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: linux-kernel@vger.kernel.org > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > --- > kernel/irq/irqdomain.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c > index 8fe1da9614ee..e2096b51c004 100644 > --- a/kernel/irq/irqdomain.c > +++ b/kernel/irq/irqdomain.c > @@ -1915,7 +1915,7 @@ static void debugfs_add_domain_dir(struct irq_domain *d) > > static void debugfs_remove_domain_dir(struct irq_domain *d) > { > - debugfs_remove(debugfs_lookup(d->name, domain_dir)); > + debugfs_lookup_and_remove(d->name, domain_dir); > } > > void __init irq_domain_debugfs_init(struct dentry *root) Reviewed-by: Marc Zyngier <maz@kernel.org> Maybe add a Cc stable to get this in 6.1? Thanks, M.
On Thu, Feb 02, 2023 at 04:48:30PM +0000, Marc Zyngier wrote: > On Thu, 02 Feb 2023 15:15:54 +0000, > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > > > When calling debugfs_lookup() the result must have dput() called on it, > > otherwise the memory will leak over time. To make things simpler, just > > call debugfs_lookup_and_remove() instead which handles all of the logic > > at once. > > > > Cc: Marc Zyngier <maz@kernel.org> > > Cc: Thomas Gleixner <tglx@linutronix.de> > > Cc: linux-kernel@vger.kernel.org > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > --- > > kernel/irq/irqdomain.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c > > index 8fe1da9614ee..e2096b51c004 100644 > > --- a/kernel/irq/irqdomain.c > > +++ b/kernel/irq/irqdomain.c > > @@ -1915,7 +1915,7 @@ static void debugfs_add_domain_dir(struct irq_domain *d) > > > > static void debugfs_remove_domain_dir(struct irq_domain *d) > > { > > - debugfs_remove(debugfs_lookup(d->name, domain_dir)); > > + debugfs_lookup_and_remove(d->name, domain_dir); > > } > > > > void __init irq_domain_debugfs_init(struct dentry *root) > > Reviewed-by: Marc Zyngier <maz@kernel.org> > > Maybe add a Cc stable to get this in 6.1? Sure, I can, but how often are irq domains removed from the system under a normal operation? Or you can take it through your tree and add that? I too can take it through mine, which ever is easier for you. thanks, greg k-h
On Thu, 02 Feb 2023 16:51:50 +0000, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > On Thu, Feb 02, 2023 at 04:48:30PM +0000, Marc Zyngier wrote: > > On Thu, 02 Feb 2023 15:15:54 +0000, > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > > > > > When calling debugfs_lookup() the result must have dput() called on it, > > > otherwise the memory will leak over time. To make things simpler, just > > > call debugfs_lookup_and_remove() instead which handles all of the logic > > > at once. > > > > > > Cc: Marc Zyngier <maz@kernel.org> > > > Cc: Thomas Gleixner <tglx@linutronix.de> > > > Cc: linux-kernel@vger.kernel.org > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > --- > > > kernel/irq/irqdomain.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c > > > index 8fe1da9614ee..e2096b51c004 100644 > > > --- a/kernel/irq/irqdomain.c > > > +++ b/kernel/irq/irqdomain.c > > > @@ -1915,7 +1915,7 @@ static void debugfs_add_domain_dir(struct irq_domain *d) > > > > > > static void debugfs_remove_domain_dir(struct irq_domain *d) > > > { > > > - debugfs_remove(debugfs_lookup(d->name, domain_dir)); > > > + debugfs_lookup_and_remove(d->name, domain_dir); > > > } > > > > > > void __init irq_domain_debugfs_init(struct dentry *root) > > > > Reviewed-by: Marc Zyngier <maz@kernel.org> > > > > Maybe add a Cc stable to get this in 6.1? > > Sure, I can, but how often are irq domains removed from the system under > a normal operation? As many time as you want if you're doing virtualisation and have the right sort of HW (anything GICv4.x, for example, which will create per-VM irqdomains). > Or you can take it through your tree and add that? I too can take > it through mine, which ever is easier for you. Sure, I can queue that, although that will probably be next week. Thanks, M.
On Thu, Feb 02, 2023 at 04:56:50PM +0000, Marc Zyngier wrote: > On Thu, 02 Feb 2023 16:51:50 +0000, > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > > > On Thu, Feb 02, 2023 at 04:48:30PM +0000, Marc Zyngier wrote: > > > On Thu, 02 Feb 2023 15:15:54 +0000, > > > Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote: > > > > > > > > When calling debugfs_lookup() the result must have dput() called on it, > > > > otherwise the memory will leak over time. To make things simpler, just > > > > call debugfs_lookup_and_remove() instead which handles all of the logic > > > > at once. > > > > > > > > Cc: Marc Zyngier <maz@kernel.org> > > > > Cc: Thomas Gleixner <tglx@linutronix.de> > > > > Cc: linux-kernel@vger.kernel.org > > > > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> > > > > --- > > > > kernel/irq/irqdomain.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c > > > > index 8fe1da9614ee..e2096b51c004 100644 > > > > --- a/kernel/irq/irqdomain.c > > > > +++ b/kernel/irq/irqdomain.c > > > > @@ -1915,7 +1915,7 @@ static void debugfs_add_domain_dir(struct irq_domain *d) > > > > > > > > static void debugfs_remove_domain_dir(struct irq_domain *d) > > > > { > > > > - debugfs_remove(debugfs_lookup(d->name, domain_dir)); > > > > + debugfs_lookup_and_remove(d->name, domain_dir); > > > > } > > > > > > > > void __init irq_domain_debugfs_init(struct dentry *root) > > > > > > Reviewed-by: Marc Zyngier <maz@kernel.org> > > > > > > Maybe add a Cc stable to get this in 6.1? > > > > Sure, I can, but how often are irq domains removed from the system under > > a normal operation? > > As many time as you want if you're doing virtualisation and have the > right sort of HW (anything GICv4.x, for example, which will create > per-VM irqdomains). Ok, I'll queue this up now and get it to Linus for 6.2-final. thanks, greg k-h
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c index 8fe1da9614ee..e2096b51c004 100644 --- a/kernel/irq/irqdomain.c +++ b/kernel/irq/irqdomain.c @@ -1915,7 +1915,7 @@ static void debugfs_add_domain_dir(struct irq_domain *d) static void debugfs_remove_domain_dir(struct irq_domain *d) { - debugfs_remove(debugfs_lookup(d->name, domain_dir)); + debugfs_lookup_and_remove(d->name, domain_dir); } void __init irq_domain_debugfs_init(struct dentry *root)