From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tejun Heo Subject: Re: [RFC PATCH 2/5] block: Do not stop draining if waitqueue is not empty. Date: Mon, 21 May 2012 08:39:22 -0700 Message-ID: <20120521153922.GA6549@google.com> References: <1337591313-26333-1-git-send-email-asias@redhat.com> <1337591313-26333-2-git-send-email-asias@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jens Axboe , linux-fsdevel@vger.kernel.org To: Asias He Return-path: Received: from mail-pz0-f46.google.com ([209.85.210.46]:44091 "EHLO mail-pz0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750817Ab2EUPj1 (ORCPT ); Mon, 21 May 2012 11:39:27 -0400 Received: by dady13 with SMTP id y13so6961425dad.19 for ; Mon, 21 May 2012 08:39:27 -0700 (PDT) Content-Disposition: inline In-Reply-To: <1337591313-26333-2-git-send-email-asias@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, May 21, 2012 at 05:08:30PM +0800, Asias He wrote: > If there are processes still in the wait queue, keep draining, > otherwise these processes would be in D state forever. > > I noticed this situation: > q->rq.count[0] == 0, q->rq.count[1] == 0, however wait queue > q->rq.wait[0].task_list and q->rq.wait[1].task_list are not empty. > > Cc: Jens Axboe > Cc: Tejun Heo > Cc: linux-fsdevel@vger.kernel.org > Signed-off-by: Asias He > --- > block/blk-core.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/block/blk-core.c b/block/blk-core.c > index ca42fd7..2c2b585 100644 > --- a/block/blk-core.c > +++ b/block/blk-core.c > @@ -394,6 +394,7 @@ void blk_drain_queue(struct request_queue *q, bool drain_all) > drain |= q->rq.count[i]; > drain |= q->in_flight[i]; > drain |= !list_empty(&q->flush_queue[i]); > + drain |= waitqueue_active(&q->rq.wait[i]); Hmm... how does that happen? What do you mean "you noticed this situation"? Did that actually happen or you noticed such scenarios would be possible? If rl.wait[] isn't empty with zero rq count, the queue would hang, so we should be fixing that situation instead of working around it from cleanup_queue. Thanks. -- tejun