dio: track and serialise unaligned direct IO

If we get two unaligned direct IO's to the same filesystem block that is marked as a new allocation (i.e. buffer_new), then both IOs will zero the portion of the block they are not writing data to. As a result, when the IOs complete there will be a portion of the block that contains zeros from the last IO to complete rather than the data that should be there.

This is easily manifested by qemu using aio+dio with an unaligned guest filesystem - every IO is unaligned and fileystem corruption is encountered in the guest filesystem. xfstest 240 (from Eric Sandeen) is also a simple reproducer.

To avoid this problem, track unaligned IO that triggers sub-block zeroing and check new incoming unaligned IO that require sub-block zeroing against that list. If we get an overlap where the start and end of unaligned IOs hit the same filesystem block, then we need to block the incoming IOs until the IO that is zeroing the block completes. The blocked IO can then continue without needing to do any zeroing and hence won't overwrite valid data with zeros.

Quoted 6 lines · Dave Chinner

If we get two unaligned direct IO's to the same filesystem block that is marked as a new allocation (i.e. buffer_new), then both IOs will zero the portion of the block they are not writing data to. As a result, when the IOs complete there will be a portion of the block that contains zeros from the last IO to complete rather than the data that should be there.

Urgh. Yuck.

Quoted 5 lines

This is easily manifested by qemu using aio+dio with an unaligned guest filesystem - every IO is unaligned and fileystem corruption is encountered in the guest filesystem. xfstest 240 (from Eric Sandeen) is also a simple reproducer.

Quoted 6 lines

To avoid this problem, track unaligned IO that triggers sub-block zeroing and check new incoming unaligned IO that require sub-block zeroing against that list. If we get an overlap where the start and end of unaligned IOs hit the same filesystem block, then we need to block the incoming IOs until the IO that is zeroing the block completes. The blocked IO can then continue without needing to do any zeroing and hence won't overwrite valid data with zeros.

Urgh. Yuck.

Could we perhaps handle this by making an IO instantiate a page cache page for partial writes, and forcing that portion of the IO through the page cache? The second IO would hit the same page and use the existing O_DIRECT vs page cache paths.

Quoted 15 lines · Matthew Wilcox

Quoted 6 lines · Dave Chinner

If we get two unaligned direct IO's to the same filesystem block that is marked as a new allocation (i.e. buffer_new), then both IOs will zero the portion of the block they are not writing data to. As a result, when the IOs complete there will be a portion of the block that contains zeros from the last IO to complete rather than the data that should be there.

Urgh. Yuck.

Quoted 5 lines

This is easily manifested by qemu using aio+dio with an unaligned guest filesystem - every IO is unaligned and fileystem corruption is encountered in the guest filesystem. xfstest 240 (from Eric Sandeen) is also a simple reproducer.

Quoted 8 lines

Quoted 6 lines

To avoid this problem, track unaligned IO that triggers sub-block zeroing and check new incoming unaligned IO that require sub-block zeroing against that list. If we get an overlap where the start and end of unaligned IOs hit the same filesystem block, then we need to block the incoming IOs until the IO that is zeroing the block completes. The blocked IO can then continue without needing to do any zeroing and hence won't overwrite valid data with zeros.

Urgh. Yuck.

It's better than silent data corruption.

Quoted 4 lines

Could we perhaps handle this by making an IO instantiate a page cache page for partial writes, and forcing that portion of the IO through the page cache? The second IO would hit the same page and use the existing O_DIRECT vs page cache paths.

I don't want any direct IO for XFS to go through the page cache - unaligned or not. using the page cache for the unaligned blocks would also be much worse for performance that this method because it turns unaligned direct IO into 3 IOs - the unaligned head block, the aligned body and the unaligned tail block. It would also be a performance hit you take on every single dio, whereas this way the hit is only taken when an overlap is detected.

And besides, such decisions on whether to use buffered IO have to be made high up in the filesystem when we are deciding how to lock the inode for the dio - buffered IO requires exclusive locking, not the shared locking we do for dio writes. That further reduces the performance of unaligned direct IO even when there are no overlaps, and it's a solution that every filesystem needs to implement themselves in some way.

I've looked at a couple of different ways to fix this (e.g. passing the unaligned state to get_blocks() to allow the filesystem to serialise there) but they've all died a horrible death of dodgy locking and hacky IO completion detection. not to mention requiring a different solution in every filesystem.

This way may be a bit ugly, but it works, is isolated and seems to me to be the least-worst way of solving the problem. It could be made to scale better by making the tracking per-inode, but I don't think that growing the struct inode for this corner case is a good tradeoff, either...

Cheers,

Dave.

Quoted 8 lines · Dave Chinner

Quoted 7 lines · Matthew Wilcox

Quoted 6 lines · Dave Chinner

If we get two unaligned direct IO's to the same filesystem block that is marked as a new allocation (i.e. buffer_new), then both IOs will zero the portion of the block they are not writing data to. As a result, when the IOs complete there will be a portion of the block that contains zeros from the last IO to complete rather than the data that should be there.

Quoted 7 lines

I don't want any direct IO for XFS to go through the page cache - unaligned or not. using the page cache for the unaligned blocks would also be much worse for performance that this method because it turns unaligned direct IO into 3 IOs - the unaligned head block, the aligned body and the unaligned tail block. It would also be a performance hit you take on every single dio, whereas this way the hit is only taken when an overlap is detected.

Does this problem also possible for DIO and non AIO case? (Ext4 case this only happy with AIO+DIO+unaligned). If not, could we simply force unaligned AIO+DIO to be synchronous? Still direct IO...

Quoted 8 lines

And besides, such decisions on whether to use buffered IO have to be made high up in the filesystem when we are deciding how to lock the inode for the dio - buffered IO requires exclusive locking, not the shared locking we do for dio writes. That further reduces the performance of unaligned direct IO even when there are no overlaps, and it's a solution that every filesystem needs to implement themselves in some way.

Quoted 5 lines

I've looked at a couple of different ways to fix this (e.g. passing the unaligned state to get_blocks() to allow the filesystem to serialise there) but they've all died a horrible death of dodgy locking and hacky IO completion detection. not to mention requiring a different solution in every filesystem.

I also have been thinking other ways to fix this, initial thoughts about this but concerned about the scalability.

I was looking at ways to use buffer head state to indicate any unaligned AIO DIO write to buffer_new buffers(do_direct_IO set the state), then for any futhur unaligned IO need to wait for the AIO+DIO complete on that buffer.

but the buffer head passed from do_direct_IO to get_blocks() is a dummy buffer, have to get the buffer head from device...

this would only impact to all IOs that are really conflict with pending AIO DIOs... it should work for ext4 case...would this something usable for XFS? I have got the approach started last week but not very far.

Quoted 9 lines · Mingming Cao

Quoted 8 lines · Dave Chinner

Quoted 7 lines · Matthew Wilcox

Quoted 6 lines · Dave Chinner

If we get two unaligned direct IO's to the same filesystem block that is marked as a new allocation (i.e. buffer_new), then both IOs will zero the portion of the block they are not writing data to. As a result, when the IOs complete there will be a portion of the block that contains zeros from the last IO to complete rather than the data that should be there.

....

Quoted 8 lines

Quoted 7 lines

I don't want any direct IO for XFS to go through the page cache - unaligned or not. using the page cache for the unaligned blocks would also be much worse for performance that this method because it turns unaligned direct IO into 3 IOs - the unaligned head block, the aligned body and the unaligned tail block. It would also be a performance hit you take on every single dio, whereas this way the hit is only taken when an overlap is detected.

Quoted 3 lines

Does this problem also possible for DIO and non AIO case? (Ext4 case this only happy with AIO+DIO+unaligned). If not, could we simply force unaligned AIO+DIO to be synchronous? Still direct IO...

There is nothing specific to AIO about this bug. XFS (at least) allows concurrent DIO writes to the same inode regardless of whether they are dispatched via AIO or multiple separate threads and so the race condition exists outside just the AIO context...

Quoted 19 lines · Dave Chinner

Quoted 9 lines · Mingming Cao

Quoted 8 lines · Dave Chinner

Quoted 7 lines · Matthew Wilcox

Quoted 6 lines · Dave Chinner

If we get two unaligned direct IO's to the same filesystem block that is marked as a new allocation (i.e. buffer_new), then both IOs will zero the portion of the block they are not writing data to. As a result, when the IOs complete there will be a portion of the block that contains zeros from the last IO to complete rather than the data that should be there.

....

Quoted 8 lines

Quoted 7 lines

I don't want any direct IO for XFS to go through the page cache - unaligned or not. using the page cache for the unaligned blocks would also be much worse for performance that this method because it turns unaligned direct IO into 3 IOs - the unaligned head block, the aligned body and the unaligned tail block. It would also be a performance hit you take on every single dio, whereas this way the hit is only taken when an overlap is detected.

Quoted 9 lines

Quoted 3 lines

Does this problem also possible for DIO and non AIO case? (Ext4 case this only happy with AIO+DIO+unaligned). If not, could we simply force unaligned AIO+DIO to be synchronous? Still direct IO...

There is nothing specific to AIO about this bug. XFS (at least) allows concurrent DIO writes to the same inode regardless of whether they are dispatched via AIO or multiple separate threads and so the race condition exists outside just the AIO context...

Okay..yeah ext4 prevent direct IO write to the same inode from multiple threads, so this is not a issue for non-aio case.

How does XFS serialize direct IO (aligned) to the same file offset(or overlap) from multiple threads?

From: Dave Chinner <[email protected]>

If we get two unaligned direct IO's to the same filesystem block that is marked as a new allocation (i.e. buffer_new), then both IOs will zero the portion of the block they are not writing data to. As a result, when the IOs complete there will be a portion of the block that contains zeros from the last IO to complete rather than the data that should be there.

This is easily manifested by qemu using aio+dio with an unaligned guest filesystem - every IO is unaligned and fileystem corruption is encountered in the guest filesystem. xfstest 240 (from Eric Sandeen) is also a simple reproducer.

To avoid this problem, track unaligned IO that triggers sub-block zeroing and check new incoming unaligned IO that require sub-block zeroing against that list. If we get an overlap where the start and end of unaligned IOs hit the same filesystem block, then we need to block the incoming IOs until the IO that is zeroing the block completes. The blocked IO can then continue without needing to do any zeroing and hence won't overwrite valid data with zeros.

Signed-off-by Dave Chinner <[email protected]>

---
 fs/direct-io.c |  152 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 146 insertions(+), 6 deletions(-)

fs/direct-io.c +146 -6

index a10cb91..611524e 100644
@@ -71,6 +71,9 @@ struct dio {
 	unsigned start_zero_done;	/* flag: sub-blocksize zeroing has
 					   been performed at the start of a
 					   write */
+#define LAST_SECTOR ((sector_t)-1LL)
+	sector_t zero_block_front;	/* fs block we are zeroing at front */
+	sector_t zero_block_rear;	/* fs block we are zeroing at rear */
 	int pages_in_io;		/* approximate total IO pages */
 	size_t	size;			/* total request size (doesn't change)*/
 	sector_t block_in_file;		/* Current offset into the underlying

@@ -135,6 +138,101 @@ struct dio {
 	struct page *pages[DIO_PAGES];	/* page buffer */
 };
 
+
+/*
+ * record fs blocks we are doing zeroing on in a zero block list.
+ * unaligned IO is not very performant and so is relatively uncommon,
+ * so a global list should be sufficent to track them.
+ */
+struct dio_zero_block {
+	struct list_head dio_list;	/* list of io in progress */
+	sector_t	zero_block;	/* block being zeroed */
+	struct dio	*dio;		/* owner dio */
+	wait_queue_head_t wq;		/* New IO block here */
+	atomic_t	ref;		/* reference count */
+};
+
+DEFINE_SPINLOCK(dio_zero_block_lock);
+LIST_HEAD(dio_zero_block_list);
+
+/*
+ * Add a filesystem block to the list of blocks we are tracking.
+ */
+static void
+dio_start_zero_block(struct dio *dio, sector_t zero_block)
+{
+	struct dio_zero_block *zb;
+
+	zb = kmalloc(sizeof(*zb), GFP_NOIO);
+	if (!zb)
+		return;
+	INIT_LIST_HEAD(&zb->dio_list);
+	init_waitqueue_head(&zb->wq);
+	zb->zero_block = zero_block;
+	zb->dio = dio;
+	atomic_set(&zb->ref, 1);
+
+	spin_lock(&dio_zero_block_lock);
+	list_add(&zb->dio_list, &dio_zero_block_list);
+	spin_unlock(&dio_zero_block_lock);
+}
+
+static void
+dio_drop_zero_block(struct dio_zero_block *zb)
+{
+	if (atomic_dec_and_test(&zb->ref))
+		kfree(zb);
+}
+
+/*
+ * Check whether a filesystem block is currently being zeroed, and if it is
+ * wait for it to complete before returning. If we waited for a block being
+ * zeroed, return 1 to indicate that the block is already initialised,
+ * otherwise return 0 to indicate that it needs zeroing.
+ */
+static int
+dio_wait_zero_block(struct dio *dio, sector_t zero_block)
+{
+	struct dio_zero_block *zb;
+
+	spin_lock(&dio_zero_block_lock);
+	list_for_each_entry(zb, &dio_zero_block_list, dio_list) {
+		if (zb->dio->inode != dio->inode)
+			continue;
+		if (zb->zero_block != zero_block)
+			continue;
+		atomic_inc(&zb->ref);
+		spin_unlock(&dio_zero_block_lock);
+		wait_event(zb->wq, (list_empty(&zb->dio_list)));
+		dio_drop_zero_block(zb);
+		return 1;
+	}
+	spin_unlock(&dio_zero_block_lock);
+	return 0;
+}
+
+/*
+ * Complete a block zeroing and wake up anyone waiting for it.
+ */
+static void dio_end_zero_block(struct dio *dio, sector_t zero_block)
+{
+	struct dio_zero_block *zb;
+
+	spin_lock(&dio_zero_block_lock);
+	list_for_each_entry(zb, &dio_zero_block_list, dio_list) {
+		if (zb->dio->inode != dio->inode)
+			continue;
+		if (zb->zero_block != zero_block)
+			continue;
+		list_del_init(&zb->dio_list);
+		spin_unlock(&dio_zero_block_lock);
+		wake_up(&zb->wq);
+		dio_drop_zero_block(zb);
+		return;
+	}
+	spin_unlock(&dio_zero_block_lock);
+}
+
 /*
  * How many pages are in the queue?
  */

@@ -253,6 +351,11 @@ static int dio_complete(struct dio *dio, loff_t offset, int ret, bool is_async)
 		aio_complete(dio->iocb, ret, 0);
 	}
 
+	if (dio->zero_block_front != LAST_SECTOR)
+		dio_end_zero_block(dio, dio->zero_block_front);
+	if (dio->zero_block_rear != LAST_SECTOR)
+		dio_end_zero_block(dio, dio->zero_block_rear);
+
 	if (dio->flags & DIO_LOCKING)
 		/* lockdep: non-owner release */
 		up_read_non_owner(&dio->inode->i_alloc_sem);

@@ -777,6 +880,12 @@ static void clean_blockdev_aliases(struct dio *dio)
  * block with zeros. This happens only if user-buffer, fileoffset or
  * io length is not filesystem block-size multiple.
  *
+ * We need to track the blocks we are zeroing. If we have concurrent IOs that hit
+ * the same start or end block, we do not want all the IOs to zero the portion
+ * they are not writing data to as that will overwrite data from the other IOs.
+ * Hence we need to block until the first unaligned IO completes before we can
+ * continue (without executing any zeroing).
+ *
  * `end' is zero if we're doing the start of the IO, 1 at the end of the
  * IO.
  */

@@ -784,8 +893,8 @@ static void dio_zero_block(struct dio *dio, int end)
 {
 	unsigned dio_blocks_per_fs_block;
 	unsigned this_chunk_blocks;	/* In dio_blocks */
-	unsigned this_chunk_bytes;
 	struct page *page;
+	sector_t fsblock;
 
 	dio->start_zero_done = 1;
 	if (!dio->blkfactor || !buffer_new(&dio->map_bh))

@@ -797,17 +906,41 @@ static void dio_zero_block(struct dio *dio, int end)
 	if (!this_chunk_blocks)
 		return;
 
+	if (end)
+		this_chunk_blocks = dio_blocks_per_fs_block - this_chunk_blocks;
+
 	/*
 	 * We need to zero out part of an fs block.  It is either at the
-	 * beginning or the end of the fs block.
+	 * beginning or the end of the fs block, but first we need to check if
+	 * there is already a zeroing being run on this block.
+	 *
+	 * If we are doing a sub-block IO (i.e. zeroing both front and rear of
+	 * the same block) we don't need to wait or set a gaurd for the rear of
+	 * the block as we already have one set.
 	 */
-	if (end) 
-		this_chunk_blocks = dio_blocks_per_fs_block - this_chunk_blocks;
+	fsblock = dio->block_in_file >> dio->blkfactor;
+	if (!end || dio->zero_block_front != fsblock) {
 
-	this_chunk_bytes = this_chunk_blocks << dio->blkbits;
+		/* wait for any zeroing already in progress */
+		if (dio_wait_zero_block(dio, fsblock)) {
+			/* skip the range we would have zeroed. */
+			dio->next_block_for_io += this_chunk_blocks;
+			return;
+		}
+
+		/*
+		 * we are going to zero stuff now, so set a guard to catch
+		 * others that might want to zero the same block.
+		 */
+		dio_start_zero_block(dio, fsblock);
+		if (end)
+			dio->zero_block_rear = fsblock;
+		else
+			dio->zero_block_front = fsblock;
+	}
 
 	page = ZERO_PAGE(0);
-	if (submit_page_section(dio, page, 0, this_chunk_bytes, 
+	if (submit_page_section(dio, page, 0, this_chunk_blocks << dio->blkbits,
 				dio->next_block_for_io))
 		return;
 

@@ -1191,6 +1324,13 @@ __blockdev_direct_IO_newtrunc(int rw, struct kiocb *iocb, struct inode *inode,
 	 */
 	memset(dio, 0, offsetof(struct dio, pages));
 
+	/*
+	 * zero_blocks need to initialised to largeѕt value to avoid
+	 * matching the zero block accidentally.
+	 */
+	dio->zero_block_front = LAST_SECTOR;
+	dio->zero_block_rear = LAST_SECTOR;
+
 	dio->flags = flags;
 	if (dio->flags & DIO_LOCKING) {
 		/* watch out for a 0 len io from a tricksy fs */

Signature · 6 lines

1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 21 lines · Dave Chinner

From: Dave Chinner <[email protected]>

If we get two unaligned direct IO's to the same filesystem block that is marked as a new allocation (i.e. buffer_new), then both IOs will zero the portion of the block they are not writing data to. As a result, when the IOs complete there will be a portion of the block that contains zeros from the last IO to complete rather than the data that should be there.

This is easily manifested by qemu using aio+dio with an unaligned guest filesystem - every IO is unaligned and fileystem corruption is encountered in the guest filesystem. xfstest 240 (from Eric Sandeen) is also a simple reproducer.

To avoid this problem, track unaligned IO that triggers sub-block zeroing and check new incoming unaligned IO that require sub-block zeroing against that list. If we get an overlap where the start and end of unaligned IOs hit the same filesystem block, then we need to block the incoming IOs until the IO that is zeroing the block completes. The blocked IO can then continue without needing to do any zeroing and hence won't overwrite valid data with zeros.

Quoted 1 line

Signed-off-by Dave Chinner <[email protected]>

I can confirm that, it fixes corruption of my VM images when using AIO +DIO. (cache=none,aio=native). I haven't reviewed the patch closely, but

1) can we do this only for AIO+DIO combination ? For regular DIO, we should have all the IOs serialized by i_mutex anyway..

2) Having a single global list (for all devices) might cause scaling issues.

3) Are you dropping i_mutex when you are waiting for the zero-out to finish ?

From: Dave Chinner <[email protected]>

If we get two unaligned direct IO's to the same filesystem block that is marked as a new allocation (i.e. buffer_new), then both IOs will zero the portion of the block they are not writing data to. As a result, when the IOs complete there will be a portion of the block that contains zeros from the last IO to complete rather than the data that should be there.

This is easily manifested by qemu using aio+dio with an unaligned guest filesystem - every IO is unaligned and fileystem corruption is encountered in the guest filesystem. xfstest 240 (from Eric Sandeen) is also a simple reproducer.

To avoid this problem, track unaligned IO that triggers sub-block zeroing and check new incoming unaligned IO that require sub-block zeroing against that list. If we get an overlap where the start and end of unaligned IOs hit the same filesystem block, then we need to block the incoming IOs until the IO that is zeroing the block completes. The blocked IO can then continue without needing to do any zeroing and hence won't overwrite valid data with zeros.

Signed-off-by Dave Chinner <[email protected]>

---
 fs/direct-io.c |  152 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 files changed, 146 insertions(+), 6 deletions(-)

fs/direct-io.c +146 -6

index a10cb91..611524e 100644
@@ -71,6 +71,9 @@ struct dio {
 	unsigned start_zero_done;	/* flag: sub-blocksize zeroing has
 					   been performed at the start of a
 					   write */
+#define LAST_SECTOR ((sector_t)-1LL)
+	sector_t zero_block_front;	/* fs block we are zeroing at front */
+	sector_t zero_block_rear;	/* fs block we are zeroing at rear */
 	int pages_in_io;		/* approximate total IO pages */
 	size_t	size;			/* total request size (doesn't change)*/
 	sector_t block_in_file;		/* Current offset into the underlying

@@ -135,6 +138,101 @@ struct dio {
 	struct page *pages[DIO_PAGES];	/* page buffer */
 };
 
+
+/*
+ * record fs blocks we are doing zeroing on in a zero block list.
+ * unaligned IO is not very performant and so is relatively uncommon,
+ * so a global list should be sufficent to track them.
+ */
+struct dio_zero_block {
+	struct list_head dio_list;	/* list of io in progress */
+	sector_t	zero_block;	/* block being zeroed */
+	struct dio	*dio;		/* owner dio */
+	wait_queue_head_t wq;		/* New IO block here */
+	atomic_t	ref;		/* reference count */
+};
+
+DEFINE_SPINLOCK(dio_zero_block_lock);
+LIST_HEAD(dio_zero_block_list);
+
+/*
+ * Add a filesystem block to the list of blocks we are tracking.
+ */
+static void
+dio_start_zero_block(struct dio *dio, sector_t zero_block)
+{
+	struct dio_zero_block *zb;
+
+	zb = kmalloc(sizeof(*zb), GFP_NOIO);
+	if (!zb)
+		return;
+	INIT_LIST_HEAD(&zb->dio_list);
+	init_waitqueue_head(&zb->wq);
+	zb->zero_block = zero_block;
+	zb->dio = dio;
+	atomic_set(&zb->ref, 1);
+
+	spin_lock(&dio_zero_block_lock);
+	list_add(&zb->dio_list, &dio_zero_block_list);
+	spin_unlock(&dio_zero_block_lock);
+}
+
+static void
+dio_drop_zero_block(struct dio_zero_block *zb)
+{
+	if (atomic_dec_and_test(&zb->ref))
+		kfree(zb);
+}
+
+/*
+ * Check whether a filesystem block is currently being zeroed, and if it is
+ * wait for it to complete before returning. If we waited for a block being
+ * zeroed, return 1 to indicate that the block is already initialised,
+ * otherwise return 0 to indicate that it needs zeroing.
+ */
+static int
+dio_wait_zero_block(struct dio *dio, sector_t zero_block)
+{
+	struct dio_zero_block *zb;
+
+	spin_lock(&dio_zero_block_lock);
+	list_for_each_entry(zb, &dio_zero_block_list, dio_list) {
+		if (zb->dio->inode != dio->inode)
+			continue;
+		if (zb->zero_block != zero_block)
+			continue;
+		atomic_inc(&zb->ref);
+		spin_unlock(&dio_zero_block_lock);
+		wait_event(zb->wq, (list_empty(&zb->dio_list)));
+		dio_drop_zero_block(zb);
+		return 1;
+	}
+	spin_unlock(&dio_zero_block_lock);
+	return 0;
+}
+
+/*
+ * Complete a block zeroing and wake up anyone waiting for it.
+ */
+static void dio_end_zero_block(struct dio *dio, sector_t zero_block)
+{
+	struct dio_zero_block *zb;
+
+	spin_lock(&dio_zero_block_lock);
+	list_for_each_entry(zb, &dio_zero_block_list, dio_list) {
+		if (zb->dio->inode != dio->inode)
+			continue;
+		if (zb->zero_block != zero_block)
+			continue;
+		list_del_init(&zb->dio_list);
+		spin_unlock(&dio_zero_block_lock);
+		wake_up(&zb->wq);
+		dio_drop_zero_block(zb);
+		return;
+	}
+	spin_unlock(&dio_zero_block_lock);
+}
+
 /*
  * How many pages are in the queue?
  */

@@ -253,6 +351,11 @@ static int dio_complete(struct dio *dio, loff_t offset, int ret, bool is_async)
 		aio_complete(dio->iocb, ret, 0);
 	}
 
+	if (dio->zero_block_front != LAST_SECTOR)
+		dio_end_zero_block(dio, dio->zero_block_front);
+	if (dio->zero_block_rear != LAST_SECTOR)
+		dio_end_zero_block(dio, dio->zero_block_rear);
+
 	if (dio->flags & DIO_LOCKING)
 		/* lockdep: non-owner release */
 		up_read_non_owner(&dio->inode->i_alloc_sem);

@@ -777,6 +880,12 @@ static void clean_blockdev_aliases(struct dio *dio)
  * block with zeros. This happens only if user-buffer, fileoffset or
  * io length is not filesystem block-size multiple.
  *
+ * We need to track the blocks we are zeroing. If we have concurrent IOs that hit
+ * the same start or end block, we do not want all the IOs to zero the portion
+ * they are not writing data to as that will overwrite data from the other IOs.
+ * Hence we need to block until the first unaligned IO completes before we can
+ * continue (without executing any zeroing).
+ *
  * `end' is zero if we're doing the start of the IO, 1 at the end of the
  * IO.
  */

@@ -784,8 +893,8 @@ static void dio_zero_block(struct dio *dio, int end)
 {
 	unsigned dio_blocks_per_fs_block;
 	unsigned this_chunk_blocks;	/* In dio_blocks */
-	unsigned this_chunk_bytes;
 	struct page *page;
+	sector_t fsblock;
 
 	dio->start_zero_done = 1;
 	if (!dio->blkfactor || !buffer_new(&dio->map_bh))

@@ -797,17 +906,41 @@ static void dio_zero_block(struct dio *dio, int end)
 	if (!this_chunk_blocks)
 		return;
 
+	if (end)
+		this_chunk_blocks = dio_blocks_per_fs_block - this_chunk_blocks;
+
 	/*
 	 * We need to zero out part of an fs block.  It is either at the
-	 * beginning or the end of the fs block.
+	 * beginning or the end of the fs block, but first we need to check if
+	 * there is already a zeroing being run on this block.
+	 *
+	 * If we are doing a sub-block IO (i.e. zeroing both front and rear of
+	 * the same block) we don't need to wait or set a gaurd for the rear of
+	 * the block as we already have one set.
 	 */
-	if (end) 
-		this_chunk_blocks = dio_blocks_per_fs_block - this_chunk_blocks;
+	fsblock = dio->block_in_file >> dio->blkfactor;
+	if (!end || dio->zero_block_front != fsblock) {
 
-	this_chunk_bytes = this_chunk_blocks << dio->blkbits;
+		/* wait for any zeroing already in progress */
+		if (dio_wait_zero_block(dio, fsblock)) {
+			/* skip the range we would have zeroed. */
+			dio->next_block_for_io += this_chunk_blocks;
+			return;
+		}
+
+		/*
+		 * we are going to zero stuff now, so set a guard to catch
+		 * others that might want to zero the same block.
+		 */
+		dio_start_zero_block(dio, fsblock);
+		if (end)
+			dio->zero_block_rear = fsblock;
+		else
+			dio->zero_block_front = fsblock;
+	}
 
 	page = ZERO_PAGE(0);
-	if (submit_page_section(dio, page, 0, this_chunk_bytes, 
+	if (submit_page_section(dio, page, 0, this_chunk_blocks << dio->blkbits,
 				dio->next_block_for_io))
 		return;
 

@@ -1191,6 +1324,13 @@ __blockdev_direct_IO_newtrunc(int rw, struct kiocb *iocb, struct inode *inode,
 	 */
 	memset(dio, 0, offsetof(struct dio, pages));
 
+	/*
+	 * zero_blocks need to initialised to largeѕt value to avoid
+	 * matching the zero block accidentally.
+	 */
+	dio->zero_block_front = LAST_SECTOR;
+	dio->zero_block_rear = LAST_SECTOR;
+
 	dio->flags = flags;
 	if (dio->flags & DIO_LOCKING) {
 		/* watch out for a 0 len io from a tricksy fs */

Signature · 6 lines

1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 14 lines · Dave Chinner

From: Dave Chinner <[email protected]>

If we get two unaligned direct IO's to the same filesystem block that is marked as a new allocation (i.e. buffer_new), then both IOs will zero the portion of the block they are not writing data to. As a result, when the IOs complete there will be a portion of the block that contains zeros from the last IO to complete rather than the data that should be there.

This is easily manifested by qemu using aio+dio with an unaligned guest filesystem - every IO is unaligned and fileystem corruption is encountered in the guest filesystem. xfstest 240 (from Eric Sandeen) is also a simple reproducer.

Quoted 7 lines

To avoid this problem, track unaligned IO that triggers sub-block zeroing and check new incoming unaligned IO that require sub-block zeroing against that list. If we get an overlap where the start and end of unaligned IOs hit the same filesystem block, then we need to block the incoming IOs until the IO that is zeroing the block completes. The blocked IO can then continue without needing to do any zeroing and hence won't overwrite valid data with zeros.

This seems to address both two IOs are unaligned direct IO. If the first IO is aligned direct IO, then it is not tracked?

I am also concerned about the aligned direct IO case...

1) first thread aio+dio+aligned write to a hole, there is no zero-out submitted from kernel. But the hole remains initialized before all IO complete and convert it from uninitialized extent to initialized.
2) second thread aio+dio+unalign write to the same hole, this time it is unaligned. since buffer is still new (not converted yet), the new incoming thread zero out port of data that first thread has written to

Quoted 26 lines · Mingming Cao

Quoted 14 lines · Dave Chinner

From: Dave Chinner <[email protected]>

If we get two unaligned direct IO's to the same filesystem block that is marked as a new allocation (i.e. buffer_new), then both IOs will zero the portion of the block they are not writing data to. As a result, when the IOs complete there will be a portion of the block that contains zeros from the last IO to complete rather than the data that should be there.

This is easily manifested by qemu using aio+dio with an unaligned guest filesystem - every IO is unaligned and fileystem corruption is encountered in the guest filesystem. xfstest 240 (from Eric Sandeen) is also a simple reproducer.

Quoted 7 lines

To avoid this problem, track unaligned IO that triggers sub-block zeroing and check new incoming unaligned IO that require sub-block zeroing against that list. If we get an overlap where the start and end of unaligned IOs hit the same filesystem block, then we need to block the incoming IOs until the IO that is zeroing the block completes. The blocked IO can then continue without needing to do any zeroing and hence won't overwrite valid data with zeros.

This seems to address both two IOs are unaligned direct IO. If the first IO is aligned direct IO, then it is not tracked?

Quoted 8 lines

I am also concerned about the aligned direct IO case...

1) first thread aio+dio+aligned write to a hole, there is no zero-out submitted from kernel. But the hole remains initialized before all IO complete and convert it from uninitialized extent to initialized.
2) second thread aio+dio+unalign write to the same hole, this time it is unaligned. since buffer is still new (not converted yet), the new incoming thread zero out port of data that first thread has written to

That is clearly and unmistakably an application bug - it should not be issuing concurrent, overlapping IO to the same block(s) regardless of whether they are unaligned, aligned or a mixture of both. By using direct IO, the application has assumed responsibility for preventing data corruption due to overlapping IOs - they are inherently racy and nothing in the dio code prevents that from occurring.

The bug I'm fixing is for *non-overlapping* concurrent unaligned IOs where the kernel direct IO code causes the data corruption, not the application. The application is not doing something stupid, and as such needs to be fixed.

Quoted 26 lines · Mingming Cao

Quoted 14 lines · Dave Chinner

From: Dave Chinner <[email protected]>

If we get two unaligned direct IO's to the same filesystem block that is marked as a new allocation (i.e. buffer_new), then both IOs will zero the portion of the block they are not writing data to. As a result, when the IOs complete there will be a portion of the block that contains zeros from the last IO to complete rather than the data that should be there.

This is easily manifested by qemu using aio+dio with an unaligned guest filesystem - every IO is unaligned and fileystem corruption is encountered in the guest filesystem. xfstest 240 (from Eric Sandeen) is also a simple reproducer.

Quoted 7 lines

To avoid this problem, track unaligned IO that triggers sub-block zeroing and check new incoming unaligned IO that require sub-block zeroing against that list. If we get an overlap where the start and end of unaligned IOs hit the same filesystem block, then we need to block the incoming IOs until the IO that is zeroing the block completes. The blocked IO can then continue without needing to do any zeroing and hence won't overwrite valid data with zeros.

This seems to address both two IOs are unaligned direct IO. If the first IO is aligned direct IO, then it is not tracked?

Quoted 8 lines

I am also concerned about the aligned direct IO case...

1) first thread aio+dio+aligned write to a hole, there is no zero-out submitted from kernel. But the hole remains initialized before all IO complete and convert it from uninitialized extent to initialized.
2) second thread aio+dio+unalign write to the same hole, this time it is unaligned. since buffer is still new (not converted yet), the new incoming thread zero out port of data that first thread has written to

That is clearly and unmistakably an application bug - it should not be issuing concurrent, overlapping IO to the same block(s) regardless of whether they are unaligned, aligned or a mixture of both. By using direct IO, the application has assumed responsibility for preventing data corruption due to overlapping IOs - they are inherently racy and nothing in the dio code prevents that from occurring.

The bug I'm fixing is for *non-overlapping* concurrent unaligned IOs where the kernel direct IO code causes the data corruption, not the application. The application is not doing something stupid, and as such needs to be fixed.

Quoted 13 lines · Dave Chinner

Quoted 11 lines · Mingming Cao

This seems to address both two IOs are unaligned direct IO. If the first IO is aligned direct IO, then it is not tracked?

I am also concerned about the aligned direct IO case...

1) first thread aio+dio+aligned write to a hole, there is no zero-out submitted from kernel. But the hole remains initialized before all IO complete and convert it from uninitialized extent to initialized.
2) second thread aio+dio+unalign write to the same hole, this time it is unaligned. since buffer is still new (not converted yet), the new incoming thread zero out port of data that first thread has written to

Quoted 7 lines

That is clearly and unmistakably an application bug - it should not be issuing concurrent, overlapping IO to the same block(s) regardless of whether they are unaligned, aligned or a mixture of both. By using direct IO, the application has assumed responsibility for preventing data corruption due to overlapping IOs - they are inherently racy and nothing in the dio code prevents that from occurring.

while there are multiple applications running on the same filesystem, they could possible touching the same files concurrently. How could applications know there is other apps to change the same file at the same time?

Quoted 4 lines

The bug I'm fixing is for *non-overlapping* concurrent unaligned IOs where the kernel direct IO code causes the data corruption, not the application. The application is not doing something stupid, and as such needs to be fixed.

For the case I refering to here, it's the kernel direct IO who zero out the block for 2). The application did 2) did not do zero-out it self, but it will result in loose data the application write in 1). It's the same as what you are trying to fix.