From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D3EB1ECAAD5 for ; Fri, 2 Sep 2022 15:17:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236225AbiIBPRm (ORCPT ); Fri, 2 Sep 2022 11:17:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60896 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236391AbiIBPRJ (ORCPT ); Fri, 2 Sep 2022 11:17:09 -0400 Received: from zeniv.linux.org.uk (zeniv.linux.org.uk [IPv6:2a03:a000:7:0:5054:ff:fe1c:15ff]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B56EC28717 for ; Fri, 2 Sep 2022 07:49:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=linux.org.uk; s=zeniv-20220401; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=aZ+oBpeo8JsuvtNdwggGcqsSE9afnliueCxoJZqBN7U=; b=RAadmeaUeYbulm9czRnwLyIs2I WGb29yXZX4DZLJGpVl2nRhLsckXMLIiJSJVrV6LFl8X+wPJuomJYZh1vQggraP9Pdnhv/gGikP9Qu th93zu2WpmdgXVac6wraItw1t1YbqW67M1jYL6VtttTEynEM/urS1xL7pSpQMAmKGMg9Iq//2Ggcq P1w0VkeNNhKdGxuOVfjUmje02hm0DZPe3MHA6LEi4L94zZuNE7sFbdwjoT9d4oHoLNJYGTmYKucF1 Vy1wm7IRZ1IdAVc1VgIHfAJqFW2dcQV7w2VzMj3Y5UCeoGZSdlw5jrpv1pvVp53LTEpSQ6l/LSVyC +Bp2YXWw==; Received: from viro by zeniv.linux.org.uk with local (Exim 4.95 #2 (Red Hat Linux)) id 1oU7z5-00BMvU-LF; Fri, 02 Sep 2022 14:49:27 +0000 Date: Fri, 2 Sep 2022 15:49:27 +0100 From: Al Viro To: Greg Kroah-Hartman Cc: Kuyo Chang , major.chen@samsung.com, Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Valentin Schneider , Matthias Brugger , wsd_upstream@mediatek.com, hongfei.tang@samsung.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org Subject: Re: [PATCH 1/1] sched/debug: fix dentry leak in update_sched_domain_debugfs Message-ID: References: <20220902031518.1116-1-kuyo.chang@mediatek.com> <5ce45c874d6a05ca69abed3961d413c4a4360e79.camel@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Al Viro Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Sep 02, 2022 at 11:11:54AM +0200, Greg Kroah-Hartman wrote: > +/** > + * debugfs_lookup_and_remove - lookup a directory or file and recursively remove it > + * @name: a pointer to a string containing the name of the item to look up. > + * @parent: a pointer to the parent dentry of the item. > + * > + * This is the equlivant of doing something like > + * debugfs_remove(debugfs_lookup(..)) but with the proper reference counting > + * handled for the directory being looked up. > + */ > +void debugfs_lookup_and_remove(const char *name, struct dentry *parent) > +{ > + struct dentry *dentry; > + > + dentry = debugfs_lookup(name, parent); > + if (IS_ERR_OR_NULL(dentry)) > + return; Could somebody explain how could that return ERR_PTR()? Incidentally, IS_ERR_OR_NULL is almost always a sign of bad interface - or that of lazy cargo-culting. Please, don't propagate that garbage... ;-/