From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-6.6 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=unavailable autolearn_force=no version=3.4.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id 137627D08A for ; Tue, 13 Nov 2018 19:35:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728751AbeKNFfN (ORCPT ); Wed, 14 Nov 2018 00:35:13 -0500 Received: from mail.kernel.org ([198.145.29.99]:32954 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726291AbeKNFfM (ORCPT ); Wed, 14 Nov 2018 00:35:12 -0500 Received: from localhost (unknown [64.114.255.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BAB7921582; Tue, 13 Nov 2018 19:35:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1542137738; bh=IdQcfyuvdm+re6Cg0ueAy5cNXPj5ZQVuW0IBiT0DzBc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=HTWv29RID+GfRKNj/L/QDgwP4Af7T59ZxO2+iJZTCbsp8+PVNYmnlEmpKsQ+VxntY 8WtRdw7JzUB6mH4FOvAfSPay/tZeggDYYQEBYxmbIwnGCaqquT5oC+sQx127rpywA1 NyWHM46k5n3NXz1B1LAn1OTfiulTA3OeK2QAHWjo= Date: Tue, 13 Nov 2018 11:35:38 -0800 From: Greg Kroah-Hartman To: Paolo Valente Cc: Jens Axboe , Tejun Heo , Li Zefan , Angelo Ruocco , Dennis Zhou , Josef Bacik , Liu Bo , Bart Van Assche , Johannes Weiner , linux-block , linux-kernel , Ulf Hansson , Linus Walleij , Mark Brown , bfq-iosched@googlegroups.com, oleksandr@natalenko.name, cgroups@vger.kernel.org, linux-doc@vger.kernel.org, Jonathan Corbet Subject: Re: [PATCH 01/12] kernfs: add function to find kernfs_node without increasing ref counter Message-ID: <20181113193538.GA5096@kroah.com> References: <20181112095632.69114-1-paolo.valente@linaro.org> <20181112095632.69114-2-paolo.valente@linaro.org> <20181112122840.GA1429@kroah.com> <07A5F685-9D7D-42A7-9A10-73C658F47435@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <07A5F685-9D7D-42A7-9A10-73C658F47435@linaro.org> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org On Tue, Nov 13, 2018 at 06:53:59PM +0100, Paolo Valente wrote: > > > > Il giorno 12 nov 2018, alle ore 13:28, Greg Kroah-Hartman ha scritto: > > > > On Mon, Nov 12, 2018 at 10:56:21AM +0100, Paolo Valente wrote: > >> From: Angelo Ruocco > >> > >> The kernfs pseudo file system doesn't export any function to only find > >> a node by name, without also getting a reference on it. > >> But in some cases it is useful to just locate a kernfs node, while > >> using it or not depends on some other condition. > >> > >> This commit adds a function to just look for a node, without getting > >> a reference on it. > > > > Eeek, that sounds really bad. So you save off a pointer to something, > > and have no idea if that pointer now really is valid or not? It can > > instantly disappear right afterwards. > > > > Hi Greg, > that function is invoked only in functions executed with cgroup_mutex > held. This guarantees that nothing disappears or becomes > inconsistent. That's why we decided to go for this optimization, > instead of doing useless gets&puts pairs. Still, I'm not expert > enough to state whether it is impossible that, once we have defined > that function, it may then get used in some unsafe way. I can guarantee once you define that function, it will be used in an unsafe way :( So just don't create it, use the put calls, it's fast and should never be a performance issue. > So, I seem to see two options: > 1) Add a comment on the function, saying that cgroup_mutex must be > held while invoking it (I guess you won't like this one). Nope, do not create it. > 2) Do not define such a new function, and, in the other patches, use > the already-available find_and_get. Yes, please do that. thanks, greg k-h