aboutsummaryrefslogtreecommitdiffstats
path: root/fs/file_table.c
diff options
context:
space:
mode:
authorAl Viro <[email protected]>2024-07-31 15:49:04 +0000
committerAl Viro <[email protected]>2024-10-07 17:34:41 +0000
commit8fd3395ec9051a52828fcca2328cb50a69dea8ef (patch)
treed68b2a86f57af48fbece1070a3d3a09fc16a7521 /fs/file_table.c
parentLinux 6.12-rc2 (diff)
downloadkernel-8fd3395ec9051a52828fcca2328cb50a69dea8ef.tar.gz
kernel-8fd3395ec9051a52828fcca2328cb50a69dea8ef.zip
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 <[email protected]> Signed-off-by: Al Viro <[email protected]>
Diffstat (limited to 'fs/file_table.c')
0 files changed, 0 insertions, 0 deletions