summaryrefslogtreecommitdiff
path: root/net
diff options
context:
space:
mode:
authorAl Viro <viro@zeniv.linux.org.uk>2023-10-30 08:09:50 +0300
committerAl Viro <viro@zeniv.linux.org.uk>2023-11-25 10:33:56 +0300
commit2f42f1eb9093834b635991c70d0273fbe249eabf (patch)
treece60831fa5018e50135b59e8d41d4ead48943638 /net
parentb06c684d3984ef64e792ec3e89889c96cab97b5e (diff)
downloadlinux-2f42f1eb9093834b635991c70d0273fbe249eabf.tar.xz
Call retain_dentry() with refcount 0
Instead of bumping it from 0 to 1, calling retain_dentry(), then decrementing it back to 0 (with ->d_lock held all the way through), just leave refcount at 0 through all of that. It will have a visible effect for ->d_delete() - now it can be called with refcount 0 instead of 1 and it can no longer play silly buggers with dropping/regaining ->d_lock. Not that any in-tree instances tried to (it's pretty hard to get right). Any out-of-tree ones will have to adjust (assuming they need any changes). Note that we do not need to extend rcu-critical area here - we have verified that refcount is non-negative after having grabbed ->d_lock, so nobody will be able to free dentry until they get into __dentry_kill(), which won't happen until they manage to grab ->d_lock. Reviewed-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Diffstat (limited to 'net')
0 files changed, 0 insertions, 0 deletions