On Wed, 27 Sept 2023 at 14:06, Mateusz Guzik <mjguzik@xxxxxxxxx> wrote:
>
> I think you attached the wrong file, it has next to no changes and in
> particular nothing for fd lookup.
The fd lookup is already safe.
It already does the whole "double-check the file pointer after doing
the increment" for other reasons - namely the whole "oh, the file
table can be re-allocated under us" thing.
So the fd lookup needs rcu, but it does all the checks to make it all
work with SLAB_TYPESAFE_BY_RCU.
> You may find it interesting that both NetBSD and FreeBSD have been
> doing something to that extent for years now in order to provide
> lockless fd lookup despite not having an equivalent to RCU (what they
> did have at the time is "type stable" -- objs can get reused but the
> memory can *never* get freed. utterly gross, but that's old Unix for
> you).
That kind of "never free'd" thing is indeed gross, but the
type-stability is useful.
Our SLAB_TYPESAFE_BY_RCU is somewhat widely used, exactly because it's
much cheaper than an *actual* RCU delayed free.
Of course, it also requires more care, but it so happens that we
already have that for other reasons for 'struct file'.
> It does work, but I always found it dodgy because it backpedals in a
> way which is not free of side effects.
Grep around for SLAB_TYPESAFE_BY_RCU and you'll see that we actually
have it in multiple places, most notably the sighand_struct.
> Note that validating you got the right file bare minimum requires
> reloading the fd table pointer because you might have been racing
> against close *and* resize.
Exactly. See __fget_files_rcu().
Linus
