Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762548Ab2FVSFY (ORCPT ); Fri, 22 Jun 2012 14:05:24 -0400 Received: from mail-vc0-f174.google.com ([209.85.220.174]:37292 "EHLO mail-vc0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755838Ab2FVSFW convert rfc822-to-8bit (ORCPT ); Fri, 22 Jun 2012 14:05:22 -0400 MIME-Version: 1.0 In-Reply-To: <4FE41CC6.4010406@acm.org> References: <4FD345DC.6020405@acm.org> <4FD4DC26.5080902@acm.org> <20120618224253.GH32733@google.com> <4FE21C15.6040409@acm.org> <4FE2B3D1.6070504@acm.org> <4FE41CC6.4010406@acm.org> Date: Fri, 22 Jun 2012 11:05:20 -0700 Message-ID: Subject: Re: [PATCH UPDATED] block: In blk_execute_rq_nowait, init rq->end_io before checking for dead queue. From: Muthu Kumar To: Bart Van Assche Cc: Tejun Heo , Jens Axboe , Jej B , linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3200 Lines: 97 On Fri, Jun 22, 2012 at 12:20 AM, Bart Van Assche wrote: > On 06/21/12 21:40, Muthu Kumar wrote: > >> On Wed, Jun 20, 2012 at 10:40 PM, Bart Van Assche wrote: >>> On 06/21/12 00:53, Muthu Kumar wrote: >>>> This part already went in, its here only for testing - So in the final >>>> patch, before applying this should be removed. >>> >>> When did it go in ? As far as I can see that patch is not yet present in >>> Linus' tree nor in James' tree. >> >> My bad. I thought Jens/James took it already... may be not. > > > Do you agree with combining both patches into one (see below) ? Perfect. Thanks. Regards, Muthu. > > From: Muthukumar Ratty > Subject: [PATCH] block: Fix blk_execute_rq_nowait() dead queue handling > > If the queue is dead blk_execute_rq_nowait() doesn't invoke the done() > callback function. That will result in blk_execute_rq() being stuck > in wait_for_completion(). Avoid this by initializing rq->end_io to the > done() callback before we check the queue state. Also, make sure the > queue lock is held around the invocation of the done() callback. Found > this through source code review. > > Signed-off-by: Muthukumar Ratty > Signed-off-by: Bart Van Assche > Cc: Tejun Heo > Cc: Jens Axboe > Cc: James Bottomley > --- > ?block/blk-exec.c | ? 11 ++++++++--- > ?1 files changed, 8 insertions(+), 3 deletions(-) > > diff --git a/block/blk-exec.c b/block/blk-exec.c > index fb2cbd5..8b6dc5b 100644 > --- a/block/blk-exec.c > +++ b/block/blk-exec.c > @@ -43,6 +43,9 @@ static void blk_end_sync_rq(struct request *rq, int error) > ?* Description: > ?* ? ?Insert a fully prepared request at the back of the I/O scheduler queue > ?* ? ?for execution. ?Don't wait for completion. > + * > + * Note: > + * ? ?This function will invoke @done directly if the queue is dead. > ?*/ > ?void blk_execute_rq_nowait(struct request_queue *q, struct gendisk *bd_disk, > ? ? ? ? ? ? ? ? ? ? ? ? ? struct request *rq, int at_head, > @@ -51,18 +54,20 @@ void blk_execute_rq_nowait(struct request_queue *q, struct gendisk *bd_disk, > ? ? ? ?int where = at_head ? ELEVATOR_INSERT_FRONT : ELEVATOR_INSERT_BACK; > > ? ? ? ?WARN_ON(irqs_disabled()); > + > + ? ? ? rq->rq_disk = bd_disk; > + ? ? ? rq->end_io = done; > + > ? ? ? ?spin_lock_irq(q->queue_lock); > > ? ? ? ?if (unlikely(blk_queue_dead(q))) { > - ? ? ? ? ? ? ? spin_unlock_irq(q->queue_lock); > ? ? ? ? ? ? ? ?rq->errors = -ENXIO; > ? ? ? ? ? ? ? ?if (rq->end_io) > ? ? ? ? ? ? ? ? ? ? ? ?rq->end_io(rq, rq->errors); > + ? ? ? ? ? ? ? spin_unlock_irq(q->queue_lock); > ? ? ? ? ? ? ? ?return; > ? ? ? ?} > > - ? ? ? rq->rq_disk = bd_disk; > - ? ? ? rq->end_io = done; > ? ? ? ?__elv_add_request(q, rq, where); > ? ? ? ?__blk_run_queue(q); > ? ? ? ?/* the queue is stopped so it won't be run */ > -- > 1.7.7 > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/