Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1223274 > unrolled thread
| Started by | Pádraig Brady <P@draigBrady.com> |
|---|---|
| First post | 2015-09-12 02:30 +0200 |
| Last post | 2015-09-12 03:20 +0200 |
| Articles | 2 — 2 participants |
Back to article view | Back to linux.kernel
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
| From | Pádraig Brady <P@draigBrady.com> |
|---|---|
| Date | 2015-09-12 02:30 +0200 |
| Subject | query 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]
| From | Al Viro <viro@ZenIV.linux.org.uk> |
|---|---|
| Date | 2015-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