s390/dasd: hold request queue sysfs lock when calling elevator_init()

Hi Tomoki and Jens,

due to a change in linux-next the patch below is needed for s390 as well. It looks to me as if the easiest way to get this patch upstream during the next merge would be via the s390 tree.
Even though I'd much more like if we could get rid of the elevator_init() call from the dasd driver, but Stefan is still reluctant ;)

From: Heiko Carstens <[email protected]>
Date: Thu, 31 Oct 2013 13:24:28 +0100
Subject: [PATCH] s390/dasd: hold request queue sysfs lock when calling
elevator_init()

"elevator: Fix a race in elevator switching and md device initialization" changed the semantics of elevator_init() in a way that now enforces to hold the corresponding request queue's sysfs_lock when calling elevator_init() to fix a race.
The patch did not convert the s390 dasd device driver which is the only device driver which also calls elevator_init(). So add the missing locking.

---
 drivers/s390/block/dasd.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

index 244f77f844f0..f302efa937ef 100644
@@ -2979,12 +2979,12 @@ static int dasd_alloc_queue(struct dasd_block *block)
 
 	elevator_exit(block->request_queue->elevator);
 	block->request_queue->elevator = NULL;
+	mutex_lock(&block->request_queue->sysfs_lock);
 	rc = elevator_init(block->request_queue, "deadline");
-	if (rc) {
+	if (rc)
 		blk_cleanup_queue(block->request_queue);
-		return rc;
-	}
-	return 0;
+	mutex_unlock(&block->request_queue->sysfs_lock);
+	return rc;
 }
 
 /*

1.8.3.4

I'll queue it up in the drivers branch of the 3.13 queue, that'll keep it closer to the breakage. And yes, that hack should die a horrible death.

Jens Axboe