On Wed, Mar 21, 2012 at 08:23:55AM +0100, Lukas Czerner wrote:
> + /*
> + * This is fugly, but even though we're going to get rid of the
> + * EOFBLOCKS_LF in the future, we have to handle it correctly now
> + * because there are still versions of e2fsck out there which
> + * would scream otherwise. Once the new e2fsck code ignoring
> + * this flag is common enough this can be removed entirely.
> + */
> + if (ext4_test_inode_flag(inode, EXT4_INODE_EOFBLOCKS)) {
> + struct ext4_ext_path *path;
> + ext4_lblk_t last_block;
> +
> + mutex_lock(&inode->i_mutex);
> + down_read(&EXT4_I(inode)->i_data_sem);
I was looking at this patch, and I was wondering why we weren't taking
i_mutex earlier in ext4_ext_punch_hole(). The primary use of i_mutex
is to protect writes racing with each other and with truncate. Given
that punch essentially works like truncate, and all of ext4_truncate()
is run with i_mutex down, and currently ext4_ext_punch_hole() (before
applying this patch) doesn't isn't taking i_mutex at all, I'm
wondering if we can run into problems where punch is racing against a
write --- if the pages are already in mapped, then the write might not
even need to take i_data_sem.
Lukas, Allison --- am I missing something here?
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
