[PATC] block: update queue limits atomically

[Mikulas Patocka <mpatocka@redhat.com>]

The block limits may be read while they are being modified. The statement
"q->limits = *lim" is not really atomic. The compiler may turn it into
memcpy (clang does).

On x86-64, the kernel uses the "rep movsb" instruction for memcpy - it is
optimized on modern CPUs, but it is not atomic, it may be interrupted at
any byte boundary - and if it is interrupted, the readers may read
garbage.

On sparc64, there's an instruction that zeroes a cache line without
reading it from memory. The kernel memcpy implementation uses it (see
b3a04ed507bf) to avoid loading the destination buffer from memory. The
problem is that if we copy a block of data to q->limits and someone reads
it at the same time, the reader may read zeros.

This commit changes it to use WRITE_ONCE, so that individual words are
updated atomically.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: stable@vger.kernel.org

---
 block/blk-settings.c |   10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

Index: linux-2.6/block/blk-settings.c
===================================================================
--- linux-2.6.orig/block/blk-settings.c
+++ linux-2.6/block/blk-settings.c
@@ -433,6 +433,7 @@ int queue_limits_commit_update(struct re
 		struct queue_limits *lim)
 {
 	int error;
+	size_t i;
 
 	error = blk_validate_limits(lim);
 	if (error)
@@ -446,7 +447,14 @@ int queue_limits_commit_update(struct re
 	}
 #endif
 
-	q->limits = *lim;
+	/*
+	 * Note that direct assignment like "q->limits = *lim" is not atomic
+	 * (the compiler can generate things like "rep movsb" for it),
+	 * so we use WRITE_ONCE.
+	 */
+	for (i = 0; i < sizeof(struct queue_limits) / sizeof(long); i++)
+		WRITE_ONCE(*((long *)&q->limits + i), *((long *)lim + i));
+
 	if (q->disk)
 		blk_apply_bdi_limits(q->disk->bdi, lim);
 out_unlock: