linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Tomoki Sekiyama <tomoki.sekiyama@hds.com>,
	Jens Axboe <axboe@kernel.dk>, Stefan Weinhuber <wein@de.ibm.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>, linux-next@vger.kernel.org
Subject: [PATCH -next] s390/dasd: hold request queue sysfs lock when calling elevator_init()
Date: Thu, 31 Oct 2013 14:21:52 +0100	[thread overview]
Message-ID: <20131031132152.GD5551@osiris> (raw)

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@de.ibm.com>
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@hds.com>
Cc: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
 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

             reply	other threads:[~2013-10-31 13:23 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-31 13:21 Heiko Carstens [this message]
2013-10-31 14:14 ` [PATCH -next] s390/dasd: hold request queue sysfs lock when calling elevator_init() Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131031132152.GD5551@osiris \
    --to=heiko.carstens@de.ibm.com \
    --cc=axboe@kernel.dk \
    --cc=linux-next@vger.kernel.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=tomoki.sekiyama@hds.com \
    --cc=wein@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).