Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1223274 > unrolled thread

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

Started byPádraig Brady <P@draigBrady.com>
First post2015-09-12 02:30 +0200
Last post2015-09-12 03:20 +0200
Articles 2 — 2 participants

Back to article view | Back to linux.kernel


Contents

  query re unlink() ... inotify ... open() race Pádraig Brady <P@draigBrady.com> - 2015-09-12 02:30 +0200
    Re: query re unlink() ... inotify ... open() race Al Viro <viro@ZenIV.linux.org.uk> - 2015-09-12 03:20 +0200

#1223274 — query re unlink() ... inotify ... open() race

FromPádraig Brady <P@draigBrady.com>
Date2015-09-12 02:30 +0200
Subjectquery re unlink() ... inotify ... open() race
Message-ID<q7GRA-Zq-3@gated-at.bofh.it>
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1223283

FromAl Viro <viro@ZenIV.linux.org.uk>
Date2015-09-12 03:20 +0200
Message-ID<q7HDX-29A-1@gated-at.bofh.it>
In reply to#1223274
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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web