[Tux3] Possible solution to the deferred nameops delete issue

[OGAWA Hirofumi]

Daniel Phillips <phillips at phunq.net> 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 <hirofumi at mail.parknet.co.jp>

_______________________________________________
Tux3 mailing list
Tux3 at tux3.org
http://tux3.org/cgi-bin/mailman/listinfo/tux3