]> git.karo-electronics.de Git - karo-tx-linux.git/commit
ext4: fix races in ext4_sync_parent()
authorTheodore Ts'o <tytso@mit.edu>
Wed, 27 Jul 2011 01:11:28 +0000 (21:11 -0400)
committerTheodore Ts'o <tytso@mit.edu>
Wed, 27 Jul 2011 01:11:28 +0000 (21:11 -0400)
commit8f29df05fa55426af6a9b1d0fea91c6800179a7c
treeb2c91a8ee19a7387fb86e86b0ac350579ed43df0
parent2d859db3e4a82a365572592d57624a5f996ed0ec
ext4: fix races in ext4_sync_parent()

Fix problems if fsync() races against a rename of a parent directory
as pointed out by Al Viro in his own inimitable way:

>While we are at it, could somebody please explain what the hell is ext4
>doing in
>static int ext4_sync_parent(struct inode *inode)
>{
>        struct writeback_control wbc;
>        struct dentry *dentry = NULL;
>        int ret = 0;
>
>        while (inode && ext4_test_inode_state(inode, EXT4_STATE_NEWENTRY)) {
>                ext4_clear_inode_state(inode, EXT4_STATE_NEWENTRY);
>                dentry = list_entry(inode->i_dentry.next,
>                                    struct dentry, d_alias);
>                if (!dentry || !dentry->d_parent || !dentry->d_parent->d_inode)
>                        break;
>                inode = dentry->d_parent->d_inode;
>                ret = sync_mapping_buffers(inode->i_mapping);
>                ...
>Note that dentry obviously can't be NULL there.  dentry->d_parent is never
>NULL.  And dentry->d_parent would better not be negative, for crying out
>loud!  What's worse, there's no guarantees that dentry->d_parent will
>remain our parent over that sync_mapping_buffers() *and* that inode won't
>just be freed under us (after rename() and memory pressure leading to
>eviction of what used to be our dentry->d_parent)......

Reported-by: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
fs/ext4/fsync.c