From: "Jun'ichi Nomura" <j-nomura@ce.jp.nec.com>
To: Jens Axboe <jaxboe@fusionio.com>, Alasdair Kergon <agk@redhat.com>
Cc: "linux-raid@vger.kernel.org" <linux-raid@vger.kernel.org>,
device-mapper development <dm-devel@redhat.com>
Subject: Re: [PATCH] Fix deadlock with request based dm and some drivers
Date: Tue, 06 Nov 2012 21:14:30 +0900 [thread overview]
Message-ID: <5098FF26.4070907@ce.jp.nec.com> (raw)
In-Reply-To: <5098F47F.9030201@fusionio.com>
(Cc to dm-devel)
On 11/06/12 20:29, Jens Axboe wrote:
> I recently fixed a deadlock for a customer we have with
> the below patch. I have queued it up in my tree as not
> to lose it. Can I have an ack from you, or do you want
> to submit it yourself? I've marked it stable as well.
Could you tell details about how the deadlock happened?
dm's end_io always throws the completion handling to softirq:
end_clone_request()
dm_complete_request()
blk_complete_request()
then it is processed in softirq context:
dm_softirq_done()
dm_done()
dm_end_request()
rq_completed(run_queue=true)
blk_run_queue()
Since queue_lock is always held with interrupt disabled,
I couldn't see why it could deadlock.
Request-based dm followed the completion model of scsi
mid layer. So similar code path exists in scsi, too.
For example:
scsi_request_fn()
scsi_kill_request()
blk_complete_request()
then:
scsi_softirq_done()
scsi_io_completion()
scsi_next_command()
scsi_run_queue()
spin_lock queue_lock
__blk_run_queue()
If calling run-queue from softirq_done_fn() can cause deadlock,
I'm afraid the problem is not limited to dm.
> From 8ca211056519ac06bc96fb134dca1f8eb2141407 Mon Sep 17 00:00:00 2001
> From: Jens Axboe <axboe@kernel.dk>
> Date: Tue, 6 Nov 2012 12:24:26 +0100
> Subject: [PATCH] dm: fix deadlock with request based dm and queue request_fn
> recursion
>
> Request based dm attempts to re-run the request queue off the
> request completion path. If used with a driver that potentially does
> end_io from its request_fn, we could deadlock trying to recurse
> back into request dispatch. Fix this by punting the request queue
> run to kblockd.
>
> Tested to fix a quickly reproducible deadlock in such a scenario.
>
> Cc: stable@kernel.org
> Signed-off-by: Jens Axboe <axboe@kernel.dk>
> ---
> drivers/md/dm.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/md/dm.c b/drivers/md/dm.c
> index 02db918..77e6eff 100644
> --- a/drivers/md/dm.c
> +++ b/drivers/md/dm.c
> @@ -740,8 +740,14 @@ static void rq_completed(struct mapped_device *md, int rw, int run_queue)
> if (!md_in_flight(md))
> wake_up(&md->wait);
>
> + /*
> + * Run this off this callpath, as drivers could invoke end_io while
> + * inside their request_fn (and holding the queue lock). Calling
> + * back into ->request_fn() could deadlock attempting to grab the
> + * queue lock again.
> + */
> if (run_queue)
> - blk_run_queue(md->queue);
> + blk_run_queue_async(md->queue);
>
> /*
> * dm_put() must be at the end of this function. See the comment above
--
Jun'ichi Nomura, NEC Corporation
next prev parent reply other threads:[~2012-11-06 12:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-06 11:29 [PATCH] Fix deadlock with request based dm and some drivers Jens Axboe
2012-11-06 12:14 ` Jun'ichi Nomura [this message]
2012-11-06 12:35 ` Jens Axboe
2012-11-07 0:15 ` Jun'ichi Nomura
2012-11-07 8:00 ` Jens Axboe
2012-11-07 8:35 ` Jun'ichi Nomura
2012-11-07 10:59 ` [dm-devel] " Alasdair G Kergon
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=5098FF26.4070907@ce.jp.nec.com \
--to=j-nomura@ce.jp.nec.com \
--cc=agk@redhat.com \
--cc=dm-devel@redhat.com \
--cc=jaxboe@fusionio.com \
--cc=linux-raid@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.