On Thu, 18 Aug 2022, hooanon05g@xxxxxxxxx wrote: > "NeilBrown": > > Thanks for the report. > > This possibility of calling d_delete() twice has been present > > since 9019fb391de0 in v5.16. > > I don't think 9019fb391de0 is a problem. > Before v6.0-rc1, the target dentry was unhashed by __d_drop() call in > nfs_unlink(), and nfs_dentry_handle_enoent() skipped calling d_delete() > by simple_positive(). d_delete() was called only once via > nfs_dentry_remove_handle_error(). Ahhh - simple_positive() checks d_unhashed() - I didn't connect that. So before my recent patch we needed the second call to d_delete() in nfs_unlink() because the first wasn't effective. However the second call in nfs_rmdir() was still a problem. So if the current fix (9a31abb1c009) gets ported back before the patch that removed unhash (3c59366c207e) then it won't do the right thing for nfs_unlink(). As it has a Fixes: tag, that is likely. It would be better to protect the d_delete() with d_really_is_positive(). Trond: can we drop that patch and replace it, or should I add the d_really_is_positive() check with a new patch? > > In v6.0-rc1, the dentry is not unhashed and nfs_dentry_handle_enoent() > doesn't skip calling d_delete(). > > > > How did you discover this bug, and why do you think my patch > > caused it? > > I met this problem during a stress test aiming a filesystem I am > developing. > And I think unhashing causes nfs_dentry_handle_enoent() to call > d_delete(). Thanks a lot for helping me understand! Thanks, NeilBrown
