[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEXv5_ggWO39MBZu_y5z4hKuN9xRUrxM4xh30MaapR6smus3_g@mail.gmail.com>
Date: Sat, 11 Feb 2017 20:42:04 -0500
From: David Windsor <dwindsor@...il.com>
To: Bruce Fields <bfields@...ldses.org>
Cc: Jeff Layton <jlayton@...chiereds.net>, linux-nfs@...r.kernel.org,
netdev@...r.kernel.org, kernel-hardening@...ts.openwall.com,
Kees Cook <keescook@...omium.org>, "Reshetova, Elena" <elena.reshetova@...el.com>
Subject: Re: [RFC][PATCH] nfsd: add +1 to reference counting scheme for struct nfsd4_session
On Sat, Feb 11, 2017 at 8:15 PM, Bruce Fields <bfields@...ldses.org> wrote:
> On Sat, Feb 11, 2017 at 07:31:42AM -0500, Jeff Layton wrote:
>> The basic idea here is that nfsv4 sessions have a "resting state" of 0.
>> We want to keep them around, but if they go "dead" then we we'll tear
>> them down if they aren't actively in use at the time. So, we still free
>> the thing when the refcount goes to zero, but we have an extra condition
>> before we free it on the put -- that the session is also "dead" (meaning
>> that the client asked us to destroy it).
>>
>> Your patch doesn't look like it'll break anything, but I personally find
>> it harder to follow that way. The freeable reference state will be 1
>> instead of the normal 0.
>
> Alas, I don't have any examples in mind, but doesn't this pattern happen
> all over?
>
The majority of refcounted objects are allocated with refcount=1: the
very fact that they're being allocated means that they already have a
user.
The issue with struct nfsd4_session is that, like struct nfs4_client,
references to it are only taken when the server is actively working on
it. Its default "resting state" is with refcount=0.
I would like to make its default resting state with refcount=1. In
other cases similar to this, we've gotten around it by doing a
semantic +1 to the object's overall refcounting scheme.
Jeff suggested taking an additional reference in init_session(), and
dropping it in is_session_dead(), after determining, in fact, that the
object is DEAD.
> You have objects that live in some data structure. They're freed only
> when they're removed from the data structure. You want removal to fail
> whenever they're in use.
>
When they're in use, these objects' refcount should be > 0.
> So it's natural to use an atomic counter to track the number of external
> users and some other lock to serialize lookup and destruction.
>
When considering refcounted objects, the most "natural" interpretation
of refcount=0 means that the object no longer has any users and can be
freed. Increments on objects with refcount=0 shouldn't be allowed, as
this may indicate a use-after-free condition.
This discussion is difficult because the refcount_t API hasn't yet
been introduced. The purpose of that API is to eliminate
use-after-free bugs.
> --b.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
