Daniel Phillips <[EMAIL PROTECTED]> writes:
> The patch below seems to resolve the issue where dcache would unhash
> any dentry that has multiple use counts at the time of a delete. I
> have no idea what the benefit of that is, and after scratching my head
> about it for days, I decided there probably is no good reason at all.
> A later dput will drop the dentry count to zero and do the d_iput. The
> elevated dentry count case is rare, and the guilty party is probably
> going to do a dput very soon. So I just can't imagine what the intent
> of the aggressive __d_drop really was.
IIRC, usually, if user deletes the file that is still opened,
dentry->d_count > 1. open() has the reference count:
fd -> filp -> filp-f_path.dentry -> dentry
and of course, unlink() should also have the reference count for self.
So, even if dentry->d_count > 1, we have to remove dentry from
namespace, otherwise the user can open it via cached_lookup() without
inode->i_op->lookup().
So, I think it's necessary.
Maybe, test case is:
$ echo 111 > test.txt
$ sleep 30 < test.txt &
$ rm test.txt
$ cat test.txt
Thanks.
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
_______________________________________________
Tux3 mailing list
[email protected]
http://tux3.org/cgi-bin/mailman/listinfo/tux3
