Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp1250139imw; Tue, 5 Jul 2022 06:25:59 -0700 (PDT) X-Google-Smtp-Source: AGRyM1td00eO2XN3OJslkrtqTnvmOiSv8kXTzS1eRCH/bPZM1NXRSFnapOkNLKeW24cs5e5IBO4y X-Received: by 2002:a17:902:d701:b0:16a:2206:9ba8 with SMTP id w1-20020a170902d70100b0016a22069ba8mr40839815ply.168.1657027559526; Tue, 05 Jul 2022 06:25:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657027559; cv=none; d=google.com; s=arc-20160816; b=C8zroTldBXwgbt4fzm3DRYCWofxR63JIfU6abL12OZ+/9JKKIQVVcYXVcAPuDw6FT9 TWWriGd14b4mrMuLO5sd3sjHRdzPITWjgAbNMhltXKlo/a2nBhGhUFX7w3zrQOa1tHCr XW+TWEKNmFVUCSx1bg2EZC2is7F3P5KFTKp6LQ64bbV0gdYlOC2z8vl4HGvxNZGKl9K+ FdS4c6Vv6rIsIQwD4WH694+DpAxd9xbzZPY6Xz5gTHmIuPyzYf3CjwMzJN2buGYZot+L FOZGjfr1DNhecwh1ucOJUFrtjpS/sERJ4Ea81TZIinRxjaSohtJ9RDybm3koxoBOD75Q wgAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=NR3seSlkt5zi2w8Qf0V1Lvd7oRVGyvT0bPlSc6TQCf0=; b=cJIBbBOl4F2ASDF9BdoAng+voMAKybL1pE/DBugTo99q+gDZhG1R123ibfOLA8y9ZR tJqzYw6NyUbs3N/H/yz8GImvg5OdP6/ZfR2q7cqkuMRLl5fsQbcg5D7w/GNYuDr6q/99 71WomKYvWrRpue0iFluQwXjtpjTccBjyjJMP2PRewLXwXT9jM18CeVHuJx2kzNoNUa5t zyShoE4YXLA95jchZwQoo0KLOfpGXHFGleUEJft/q+0QhCzd61O7heHdkQQk4HXUN+CD 7TwTvTkWTkhrQdTBnIMlKA9MA55fZuD6UedibP3lwOmzY3OmhA2QZCfqZ2jLAc3JBz35 pfAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=YHFAOi08; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j13-20020a17090aeb0d00b001ef900e9d84si4543003pjz.17.2022.07.05.06.25.48; Tue, 05 Jul 2022 06:25:59 -0700 (PDT) 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=YHFAOi08; 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 S231289AbiGELv1 (ORCPT + 99 others); Tue, 5 Jul 2022 07:51:27 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60832 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229457AbiGELv0 (ORCPT ); Tue, 5 Jul 2022 07:51:26 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50548175B8; Tue, 5 Jul 2022 04:51:25 -0700 (PDT) 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 ams.source.kernel.org (Postfix) with ESMTPS id F0A62B817CC; Tue, 5 Jul 2022 11:51:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 60438C341C7; Tue, 5 Jul 2022 11:51:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1657021882; bh=8HX0q1v4bVW7EEm1S8O24u/Z8pt58GWOB4V5BuNmPrg=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YHFAOi08AvKpokYgI7PUKYQL3d4jofoBstvbDMDuHPYPjciMiOjPArwXYNs7QgjQe Rjhb82AypMx/6SpCaxNLvjEgsXBkBzlUz/rvyWFXd3hHNDqiB8ccnTeFNzSt+aE9uV 92rp21qwVy4hAuLsy560Wdhceicv0Jo/DGaAcr7o= Date: Tue, 5 Jul 2022 13:51:20 +0200 From: Greg Kroah-Hartman To: Hsin-Yi Wang Cc: "Rafael J . Wysocki" , Kevin Hilman , Ulf Hansson , Len Brown , Pavel Machek , Thierry Strudel , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, AngeloGioacchino Del Regno , Pin-yen Lin Subject: Re: [PATCH] PM: domains: Ensure genpd_debugfs_dir exists before remove Message-ID: References: <20220705094946.827697-1-hsinyi@chromium.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-7.8 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,T_SCC_BODY_TEXT_LINE 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: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 05, 2022 at 07:06:41PM +0800, Hsin-Yi Wang wrote: > On Tue, Jul 5, 2022 at 6:38 PM Greg Kroah-Hartman > wrote: > > > > On Tue, Jul 05, 2022 at 05:49:47PM +0800, Hsin-Yi Wang wrote: > > > genpd_debug_remove() may be indirectly called from others while > > > genpd_debugfs_dir is not yet set. Make sure genpd_debugfs_dir exists > > > before remove the sub components, otherwise components under > > > /sys/kernel/debug may be accidentally removed. > > > > > > Fixes: 718072ceb211 ("PM: domains: create debugfs nodes when adding power domains") > > > Signed-off-by: Hsin-Yi Wang > > > --- > > > An example: > > > scpsys_probe() in drivers/soc/mediatek/mtk-pm-domains.c indirectly calls > > > genpd_debug_remove() on probe fail, causing /sys/kernel/debug/usb to be > > > removed. > > > --- > > > drivers/base/power/domain.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c > > > index 3e86772d5fac5..5a2e0232862e0 100644 > > > --- a/drivers/base/power/domain.c > > > +++ b/drivers/base/power/domain.c > > > @@ -222,6 +222,9 @@ static void genpd_debug_remove(struct generic_pm_domain *genpd) > > > { > > > struct dentry *d; > > > > > > + if (!genpd_debugfs_dir) > > > + return; > > > + > > > d = debugfs_lookup(genpd->name, genpd_debugfs_dir); > > > debugfs_remove(d); > > > > Why not just change this to be: > > debugfs_remove(debugfs_lookup(genpd->name, debugfs_lookup("pm_genpd", NULL))); > If pm_genpd hasn't been created yet, debugfs_lookup("pm_genpd", NULL) > will return null. And how is this codepath being called if pm_genpd is not created yet? Surely you are not relying on the presence of a debugfs file to determine that? > If genpd->name also exists under root debugfs, it will still be > deleted unintentionally, since NULL represents root debugfs. > Eg. one of the genpd->name is "usb", which is supposed to be added as > /sys/kernel/debug/pm_genpd/usb later. But pm_genpd is not yet created, > /sys/kernel/debug/usb will be removed. Ah, that's a bad name to pick :) But still, don't paper over this problem, please solve the root issue of never relying on the creation of a debugfs file to determine functional logic. thanks, greg k-h