summaryrefslogtreecommitdiff
path: root/fs/proc/namespaces.c
diff options
context:
space:
mode:
authorAl Viro <viro@zeniv.linux.org.uk>2025-02-24 12:46:49 -0500
committerAl Viro <viro@zeniv.linux.org.uk>2025-06-10 22:11:39 -0400
commit790fa81b8c43cda9fe25c1b564d0afe3ddeeb370 (patch)
treea48b91875ca94155eee322959503bc027b14f691 /fs/proc/namespaces.c
parent5943c611c47c9444e834555c867dec744158b7ad (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