[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181112122840.GA1429@kroah.com>
Date: Mon, 12 Nov 2018 04:28:40 -0800
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Paolo Valente <paolo.valente@...aro.org>
Cc: Jens Axboe <axboe@...nel.dk>, Tejun Heo <tj@...nel.org>,
Li Zefan <lizefan@...wei.com>,
Angelo Ruocco <angeloruocco90@...il.com>,
Dennis Zhou <dennis@...nel.org>,
Josef Bacik <josef@...icpanda.com>,
Liu Bo <bo.liu@...ux.alibaba.com>,
Bart Van Assche <bvanassche@....org>,
Johannes Weiner <hannes@...xchg.org>,
linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
ulf.hansson@...aro.org, linus.walleij@...aro.org,
broonie@...nel.org, bfq-iosched@...glegroups.com,
oleksandr@...alenko.name, cgroups@...r.kernel.org,
linux-doc@...r.kernel.org, Jonathan Corbet <corbet@....net>
Subject: Re: [PATCH 01/12] kernfs: add function to find kernfs_node without
increasing ref counter
On Mon, Nov 12, 2018 at 10:56:21AM +0100, Paolo Valente wrote:
> From: Angelo Ruocco <angeloruocco90@...il.com>
>
> 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.
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?
greg k-h
Powered by blists - more mailing lists