diff options
author | Al Viro <viro@zeniv.linux.org.uk> | 2025-02-24 12:46:49 -0500 |
---|---|---|
committer | Al Viro <viro@zeniv.linux.org.uk> | 2025-06-10 22:11:39 -0400 |
commit | 790fa81b8c43cda9fe25c1b564d0afe3ddeeb370 (patch) | |
tree | a48b91875ca94155eee322959503bc027b14f691 /fs/proc/namespaces.c | |
parent | 5943c611c47c9444e834555c867dec744158b7ad (diff) |
new helper: d_splice_alias_ops()
Uses of d_set_d_op() on live dentry can be very dangerous; it is going
to be withdrawn and replaced with saner things.
The best way for a filesystem is to have the default dentry_operations
set at mount time and be done with that - __d_alloc() will use that.
Currently there are two cases when d_set_d_op() is used on a live dentry -
one is procfs, which has several genuinely different dentry_operations
instances (different ->d_revalidate(), etc.) and another is
simple_lookup(), where we would be better off without overriding ->d_op.
For procfs we have d_set_d_op() calls followed by d_splice_alias();
provide a new helper (d_splice_alias_ops(inode, dentry, d_ops)) that would
combine those two, and do the d_set_d_op() part while under ->d_lock.
That eliminates one of the places where ->d_flags had been modified
without holding ->d_lock; current behaviour is not racy, but the reasons
for that are far too brittle. Better move to uniform locking rules and
simpler proof of correctness...
The next commit will convert procfs to use of that helper; it is not
exported and won't be until somebody comes up with convincing modular
user for it.
Again, the best approach is to have default ->d_op and let __d_alloc()
do the right thing; filesystem _may_ need non-uniform ->d_op (procfs
does), but there'd better be good reasons for that.
Reviewed-by: Christian Brauner <brauner@kernel.org>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'fs/proc/namespaces.c')
0 files changed, 0 insertions, 0 deletions