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 <axboe@xxxxxxxxx> > Cc: Tejun Heo <tj@xxxxxxxxxx> > Cc: linux-fsdevel@xxxxxxxxxxxxxxx > Signed-off-by: Asias He <asias@xxxxxxxxxx> > --- > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
