get rid of ...lookup...fdget_rcu() family
authorAl Viro <viro@zeniv.linux.org.uk>
Wed, 31 Jul 2024 15:49:04 +0000 (11:49 -0400)
committerAl Viro <viro@zeniv.linux.org.uk>
Mon, 7 Oct 2024 17:34:41 +0000 (13:34 -0400)
commit8fd3395ec9051a52828fcca2328cb50a69dea8ef
treed68b2a86f57af48fbece1070a3d3a09fc16a7521
parent8cf0b93919e13d1e8d4466eb4080a4c4d9d66d7b
get rid of ...lookup...fdget_rcu() family

Once upon a time, predecessors of those used to do file lookup
without bumping a refcount, provided that caller held rcu_read_lock()
across the lookup and whatever it wanted to read from the struct
file found.  When struct file allocation switched to SLAB_TYPESAFE_BY_RCU,
that stopped being feasible and these primitives started to bump the
file refcount for lookup result, requiring the caller to call fput()
afterwards.

But that turned them pointless - e.g.
rcu_read_lock();
file = lookup_fdget_rcu(fd);
rcu_read_unlock();
is equivalent to
file = fget_raw(fd);
and all callers of lookup_fdget_rcu() are of that form.  Similarly,
task_lookup_fdget_rcu() calls can be replaced with calling fget_task().
task_lookup_next_fdget_rcu() doesn't have direct counterparts, but
its callers would be happier if we replaced it with an analogue that
deals with RCU internally.

Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
arch/powerpc/platforms/cell/spufs/coredump.c
fs/file.c
fs/gfs2/glock.c
fs/notify/dnotify/dnotify.c
fs/proc/fd.c
include/linux/fdtable.h
include/linux/file.h
kernel/bpf/task_iter.c
kernel/kcmp.c