Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp5669862imu; Tue, 13 Nov 2018 09:54:54 -0800 (PST) X-Google-Smtp-Source: AJdET5f2KZk5Mq4G3mZg/xw15UJs6xtV0+817t50S3jrUkVm53XbW7koW3ZBhL//NzdOFdFYjG7X X-Received: by 2002:a63:2447:: with SMTP id k68-v6mr5465227pgk.156.1542131694488; Tue, 13 Nov 2018 09:54:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542131694; cv=none; d=google.com; s=arc-20160816; b=Vr/Czhc+yFNLs5D3C1CJcwMv9TIL0o+Cqu/J5NYNBcUj0Qg8jlDHU6H6HMWLbRH+kh UapC84QLkN7iuYIdHd30vJ9Yy6xqekv9tMezM26qwm1XKfiqAmwVs/QYW0/b2UXuzdZk LvEa0+LiP2Dl+Hj2hQJbB0AsP2PVXpW6grR3u10rgtU1bHz7Z6ZepaSexp+xmqdivSNH +NGxmM/X/7nUu2pw1XFNWR+2BJaKhBQB6YR7sGgSAvGwE2Wd52mSewqCsPJyGcIdrtaU TS6D7+UUVfib9W5aEERh27F26xuK+6wpCLurZtiilahyWePlcHYqxvdM4F1XSEhFGYzs 1Vww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=/UQjNl9KMYOO2L/Btjnus7YePUZ4dnRxDDZ4QOFJ+4Q=; b=sACMLlAyJZSX7x8QIU5G3xhXsVYlrf7hdPgxNgvuYEEtxyMolqLKPohafJD5J9TYoK rW+Q1l+CIQsAWtEiI8IzNPIryewN76tQFz8JaNpRRojRODmljFdIxSMH0zI1Vi72X7zZ UvAh41K8aWmjpzZkOBzCT7Ff5b3CQPlNKl0d0h8tJgBumWzt9cEW4OjV1TxYZGYEIUlF XBFY/9zvmB86XCHJLoNLncdhAwudQ6tEccEofGDR8t8esyW0zQCuMpNXmUIMgTKMhPdW DGaHpsB5lmPvZnf5dVdZ6StIz66wXfyiSmZiorEqFjrwkYCDQLltyWDkWzSGFi0iqmls 0uBw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=RwoGukJJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bi6si4503155plb.279.2018.11.13.09.54.31; Tue, 13 Nov 2018 09:54:54 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=RwoGukJJ; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732179AbeKNDxP (ORCPT + 99 others); Tue, 13 Nov 2018 22:53:15 -0500 Received: from mail-wr1-f65.google.com ([209.85.221.65]:41726 "EHLO mail-wr1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1732098AbeKNDxP (ORCPT ); Tue, 13 Nov 2018 22:53:15 -0500 Received: by mail-wr1-f65.google.com with SMTP id v18-v6so14336383wrt.8 for ; Tue, 13 Nov 2018 09:54:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/UQjNl9KMYOO2L/Btjnus7YePUZ4dnRxDDZ4QOFJ+4Q=; b=RwoGukJJ7K/gZSt1+7JVUvI3S4b7QqodpFcNlk4KWLoTAHsfD+7zFrfMXBRT2KUp59 gmmc8Mwn2I91WRjCnL5QxXqgapAXgG9n+I5bljScvf4yFYSXXn7GxZIf4pJWI4rj60Gu CikS/N9nWD+xRVUir63QNA8LGtTC6vAjqY2M0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/UQjNl9KMYOO2L/Btjnus7YePUZ4dnRxDDZ4QOFJ+4Q=; b=o1x8/snyB9dO8DFThEJ/1U7gBq/qrZDyhfVor405mw6HOjV855GxUgYIIdsrbsy7n6 Rlyh8AZdBnYEo0U86FOlyyM0igL1WP+taueUj3cXlD4XcJZzkFLB/Wjg+UahSNhtaKck Z7/Ew+udGYzuOQR0yCf/ZhXiO3xWnyY4txOFfISq6x25dhzhXS/uny/heudqUP8wubOX k+BlPbBxw392U8HxjwG3op/q+6G7+/08EFG9tnzHJbBn18HMp6sB20E4PgUszrW6Vohf JlxFH7p7legv/o/liKB8UwUdp6nlvobfLgrggp1Ip6CEV2AEZOYVuGAUPyici5zzsGFD jjwQ== X-Gm-Message-State: AGRZ1gLM5WRveKxGUe7htkWv1vC5HjFX1zTkUaVnkAZfbKTiaQNvulcX uDEERVbdp1JJVntK1H1z4LKQAQ== X-Received: by 2002:a5d:410e:: with SMTP id l14mr4220381wrp.61.1542131644683; Tue, 13 Nov 2018 09:54:04 -0800 (PST) Received: from [192.168.43.112] ([37.180.154.12]) by smtp.gmail.com with ESMTPSA id 125-v6sm15077606wmm.25.2018.11.13.09.54.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Nov 2018 09:54:04 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Subject: Re: [PATCH 01/12] kernfs: add function to find kernfs_node without increasing ref counter From: Paolo Valente In-Reply-To: <20181112122840.GA1429@kroah.com> Date: Tue, 13 Nov 2018 18:53:59 +0100 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 Content-Transfer-Encoding: quoted-printable Message-Id: <07A5F685-9D7D-42A7-9A10-73C658F47435@linaro.org> References: <20181112095632.69114-1-paolo.valente@linaro.org> <20181112095632.69114-2-paolo.valente@linaro.org> <20181112122840.GA1429@kroah.com> To: Greg Kroah-Hartman X-Mailer: Apple Mail (2.3445.100.39) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Il giorno 12 nov 2018, alle ore 13:28, Greg Kroah-Hartman = ha scritto: >=20 > On Mon, Nov 12, 2018 at 10:56:21AM +0100, Paolo Valente wrote: >> From: Angelo Ruocco >>=20 >> 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. >>=20 >> This commit adds a function to just look for a node, without getting >> a reference on it. >=20 > 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. >=20 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. 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). 2) Do not define such a new function, and, in the other patches, use the already-available find_and_get. Looking forward to your feedback (or of other knowledgeable people on this issue) before proceeding to a rebased V2, Paolo > This feels wrong, what is the problem of having a properly reference > counted object passed back to you that you have to create a dangerous > function like this? >=20 > greg k-h