| Message ID | 1474994615-29553-4-git-send-email-jack@suse.cz (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Sep 27, 2016 at 06:43:32PM +0200, Jan Kara wrote: > So far we did not return BH_New buffers from ext4_dax_get_block() > because that would trigger racy zeroing in DAX code. This zeroing is > gone these days so we can remove the workaround. > > Signed-off-by: Jan Kara <jack@suse.cz> Looks fine, Reviewed-by: Christoph Hellwig <hch@lst.de> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index 87150122d361..7ccd6fd7819d 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -3298,11 +3298,6 @@ int ext4_dax_get_block(struct inode *inode, sector_t iblock, if (ret < 0) return ret; } - /* - * At least for now we have to clear BH_New so that DAX code - * doesn't attempt to zero blocks again in a racy way. - */ - clear_buffer_new(bh_result); return 0; } #else
So far we did not return BH_New buffers from ext4_dax_get_block() because that would trigger racy zeroing in DAX code. This zeroing is gone these days so we can remove the workaround. Signed-off-by: Jan Kara <jack@suse.cz> --- fs/ext4/inode.c | 5 ----- 1 file changed, 5 deletions(-)