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 a59819b17c4a2d06b48ee44236d848161d8d8bb9 Mon Sep 17 00:00:00 2001
From: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
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.
Cc: Tomoki Sekiyama <tomoki.sekiyama@xxxxxxx>
Cc: Jens Axboe <axboe@xxxxxxxxx>
Signed-off-by: Heiko Carstens <heiko.carstens@xxxxxxxxxx>
---
drivers/s390/block/dasd.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/s390/block/dasd.c b/drivers/s390/block/dasd.c
index 244f77f844f0..f302efa937ef 100644
--- a/drivers/s390/block/dasd.c
+++ b/drivers/s390/block/dasd.c
@@ -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
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
