Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2993619AbbEPITP (ORCPT ); Sat, 16 May 2015 04:19:15 -0400 Received: from bband-dyn183.178-41-215.t-com.sk ([178.41.215.183]:22927 "EHLO ip4-83-240-18-248.cust.nbox.cz" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2993570AbbEPIS4 (ORCPT ); Sat, 16 May 2015 04:18:56 -0400 From: Jiri Slaby To: stable@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Lukas Czerner , "Theodore Ts'o" , Jiri Slaby Subject: [PATCH 3.12 095/142] ext4: fix data corruption caused by unwritten and delayed extents Date: Sat, 16 May 2015 09:37:35 +0200 Message-Id: <50a61d0ce8cadb9185b6fc47bcc99ce7bf69c62c.1431761807.git.jslaby@suse.cz> X-Mailer: git-send-email 2.3.7 In-Reply-To: <70c3d4ae1322b9e9bd7443ef574af5635234a0fa.1431761807.git.jslaby@suse.cz> References: <70c3d4ae1322b9e9bd7443ef574af5635234a0fa.1431761807.git.jslaby@suse.cz> In-Reply-To: References: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3892 Lines: 100 From: Lukas Czerner 3.12-stable review patch. If anyone has any objections, please let me know. =============== commit d2dc317d564a46dfc683978a2e5a4f91434e9711 upstream. Currently it is possible to lose whole file system block worth of data when we hit the specific interaction with unwritten and delayed extents in status extent tree. The problem is that when we insert delayed extent into extent status tree the only way to get rid of it is when we write out delayed buffer. However there is a limitation in the extent status tree implementation so that when inserting unwritten extent should there be even a single delayed block the whole unwritten extent would be marked as delayed. At this point, there is no way to get rid of the delayed extents, because there are no delayed buffers to write out. So when a we write into said unwritten extent we will convert it to written, but it still remains delayed. When we try to write into that block later ext4_da_map_blocks() will set the buffer new and delayed and map it to invalid block which causes the rest of the block to be zeroed loosing already written data. For now we can fix this by simply not allowing to set delayed status on written extent in the extent status tree. Also add WARN_ON() to make sure that we notice if this happens in the future. This problem can be easily reproduced by running the following xfs_io. xfs_io -f -c "pwrite -S 0xaa 4096 2048" \ -c "falloc 0 131072" \ -c "pwrite -S 0xbb 65536 2048" \ -c "fsync" /mnt/test/fff echo 3 > /proc/sys/vm/drop_caches xfs_io -c "pwrite -S 0xdd 67584 2048" /mnt/test/fff This can be theoretically also reproduced by at random by running fsx, but it's not very reliable, though on machines with bigger page size (like ppc) this can be seen more often (especially xfstest generic/127) Signed-off-by: Lukas Czerner Signed-off-by: Theodore Ts'o Signed-off-by: Jiri Slaby --- fs/ext4/extents_status.c | 8 ++++++++ fs/ext4/inode.c | 2 ++ 2 files changed, 10 insertions(+) diff --git a/fs/ext4/extents_status.c b/fs/ext4/extents_status.c index 171b9fa0f27a..4e8b79def9c7 100644 --- a/fs/ext4/extents_status.c +++ b/fs/ext4/extents_status.c @@ -656,6 +656,14 @@ int ext4_es_insert_extent(struct inode *inode, ext4_lblk_t lblk, BUG_ON(end < lblk); + if ((status & EXTENT_STATUS_DELAYED) && + (status & EXTENT_STATUS_WRITTEN)) { + ext4_warning(inode->i_sb, "Inserting extent [%u/%u] as " + " delayed and written which can potentially " + " cause data loss.\n", lblk, len); + WARN_ON(1); + } + newes.es_lblk = lblk; newes.es_len = len; ext4_es_store_pblock(&newes, pblk); diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index ba68d211d748..70a390bb4733 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -569,6 +569,7 @@ int ext4_map_blocks(handle_t *handle, struct inode *inode, status = map->m_flags & EXT4_MAP_UNWRITTEN ? EXTENT_STATUS_UNWRITTEN : EXTENT_STATUS_WRITTEN; if (!(flags & EXT4_GET_BLOCKS_DELALLOC_RESERVE) && + !(status & EXTENT_STATUS_WRITTEN) && ext4_find_delalloc_range(inode, map->m_lblk, map->m_lblk + map->m_len - 1)) status |= EXTENT_STATUS_DELAYED; @@ -678,6 +679,7 @@ found: status = map->m_flags & EXT4_MAP_UNWRITTEN ? EXTENT_STATUS_UNWRITTEN : EXTENT_STATUS_WRITTEN; if (!(flags & EXT4_GET_BLOCKS_DELALLOC_RESERVE) && + !(status & EXTENT_STATUS_WRITTEN) && ext4_find_delalloc_range(inode, map->m_lblk, map->m_lblk + map->m_len - 1)) status |= EXTENT_STATUS_DELAYED; -- 2.3.7 -- 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/