query re unlink() ... inotify ... open() race

query re unlink() ... inotify ... open() race

[Pádraig Brady]

Hi,

We're noticing a rare race here with open() in tail(1), where this happens:

  tail --follow=name "file"
    /* "file" is unlinked() by another process */
    read(IN_ATTRIB from inotify); /* for st_nlink-- */
    open("file") /* Done to check if deleted, but this succeeds! */

The open() succeeding is surprising. Is that allowed?
The summary of the sequence in the kernel is:

  vfs_unlink() {
    mutex_lock(&(dentry->d_inode->i_mutex));
    security_inode_unlink(dir, dentry);
    try_break_deleg(target, delegated_inode);
    dir->i_op->unlink(dir, dentry);
    dont_mount(dentry);
    detach_mounts(dentry);
    mutex_unlock(&(dentry->d_inode->i_mutex));

    fsnotify_link_count(target)
    d_delete(dentry);
  }

thanks,
Pádraig.

Re: query re unlink() ... inotify ... open() race

[Al Viro]

On Sat, Sep 12, 2015 at 01:28:27AM +0100, Pádraig Brady wrote:

> The open() succeeding is surprising. Is that allowed?
> The summary of the sequence in the kernel is:
> 
>   vfs_unlink() {
>     mutex_lock(&(dentry->d_inode->i_mutex));
>     security_inode_unlink(dir, dentry);
>     try_break_deleg(target, delegated_inode);
>     dir->i_op->unlink(dir, dentry);
>     dont_mount(dentry);
>     detach_mounts(dentry);
>     mutex_unlock(&(dentry->d_inode->i_mutex));
> 
>     fsnotify_link_count(target)
>     d_delete(dentry);
>   }

... and ->unlink() is the one to decrement the link count.  With lookup
via dcache coming at some point after that.  idiotify is a red herring
here - stat(2) will report decremented link count just as well.