On Mon, 2005-09-19 at 19:20 -0700, Linus Torvalds wrote:
>
> On Mon, 19 Sep 2005, John McCutchan wrote:
> >
> > To quote you:
>
> Yeah, sometimes I'm more right than other times. That wasn't one of them.
>
> It's actually _almost_ right. The problem being that dentry_iput() is
> called for non-delete events too.
>
> However, your patch is _worse_. Your patch will cause it not to report the
> delete at all, because what will happen is that if the delete() is done
> while somebody else has a pointer to the dentry, then we won't call
> "dentry_iput()" with a "delete" AT ALL. We will only call it later when
> the _other_ person (who didn't do a delete) releases the dentry.
>
> See? It's very very wrong to send a flag that depends on the call-chain,
> because the call-chain is _not_ what determines whether the inode gets
> deleted or not.
>
Yeah, I see this now.
> The only way to know whether it gets deleted or not is whan the actual
> i_nlink goes down to 0, and the inode gets deleted. Ie exactly the
> generic_delete_inode() case.
>
> But if you keep a reference to the inode, that will never actually happen.
> Hmm.
>
> Who wants that inode delete event anyway? It's fundamentally harder than
> removing a name, partly because of the delayed delete, partly because an
> inode may be reachable multiple ways.
>
I think the name fsnotify_inoderemove is causing some confusion. We only
care that some name that is pointing to this inode has been deleted.
Remember, it was suggested as a replacement for fsnotify_unlink. We
don't care if the inode is actually going away or not.
> Maybe this patch instead? It's not going to be reliable on networked
> filesystems, though. Nothing is.
>
Thanks, I will have it tested.
--
John McCutchan <[email protected]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |