Re: [patch] stop inotify from sending random DELETE_SELF event underload

[Linus Torvalds]

On Tue, 20 Sep 2005, John McCutchan wrote:
> 
> > 	* removal of this link, at the moment when it stops being accessible
> > [ none of the above, better done from vfs_...() ]
> 
> That is the behaviour we want, how does Linus's second patch not
> accomplish this? 

My latest patch will still wait for any other process that has that _path_ 
open to release it.

The reason? It looks "easy" to do it from d_delete(), but the thing is, at
the point where we've released the d_lock spinlock, the "struct inode" is
gone, gone, gone. And we don't want to do the notification _while_ we hold
the spinlocks either.

So we can either do it the easy way - _before_ we get any spinlocks (but
that means that processes will be notified before the name is actually
gone), or we have to wait until _after_ we've unhashed the dentry and
released the spinlocks.

But waiting until after that automatically means that the inode isn't 
stable any more: it might be gone.

The "fsnotify_nameremove()" thing doesn't have this problem, because it 
simply doesn't even care about the inode - it only cares about the dentry, 
which is stable.

This is why movign the release to "dentry_iput()" helps us - it's the
point where we release the dentry spinlocks, and it's also where the inode
actually goes away. In other words, it's the _one_ point where we can
insert the notification outside of the dcache locks but before the inode
is gone.

It's a sligtly inconvenient place, though. And it does mean that if the
dentry was in use by something else when the delete happened, the "inode
is gone"  notification will be delayed until the dentry is really free'd.
However, at least at that point it's really a per-path thing, and it won't 
have any other global issues (ie hardlinks etc do not come into play with
my last patch).

If you want immediate notification when the name disappears, you'd better 
listen to the "nameremove" thing. 

I don't think we can reasonably do better than the last patch, but maybe 
Al sees something I've missed.

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/