On Fri, Jun 15 2007, Tejun Heo wrote: > SCSI marks internal commands with REQ_PREEMPT and push it at the front > of the request queue using blk_execute_rq(). When entering suspended > or frozen state, SCSI devices are quiesced using > scsi_device_quiesce(). In quiesced state, only REQ_PREEMPT requests > are processed. This is how SCSI blocks other requests out while > suspending and resuming. As all internal commands are pushed at the > front of the queue, this usually works. > > Unfortunately, this interacts badly with ordered requeueing. To > preserve request order on requeueing (due to busy device, active EH or > other failures), requests are sorted according to ordered sequence on > requeue if IO barrier is in progress. > > The following sequence deadlocks. > > 1. IO barrier sequence issues. > > 2. Suspend requested. Queue is quiesced with part or all of IO > barrier sequence at the front. > > 3. During suspending or resuming, SCSI issues internal command which > gets deferred and requeued for some reason. As the command is > issued after the IO barrier in #1, ordered requeueing code puts the > request after IO barrier sequence. > > 4. The device is ready to process requests again but still is in > quiesced state and the first request of the queue isn't > REQ_PREEMPT, so command processing is deadlocked - > suspending/resuming waits for the issued request to complete while > the request can't be processed till device is put back into > running state by resuming. > > This can be fixed by always putting !fs requests at the front when > requeueing. > > The following thread reports this deadlock. > > http://thread.gmane.org/gmane.linux.kernel/537473 > > Signed-off-by: Tejun Heo <htejun@xxxxxxxxx> > Cc: Jenn Axboe <jens.axboe@xxxxxxxxxx> > Cc: David Greaves <david@xxxxxxxxxxxx> > --- > > Yep looks good, except for the bad multi-line comment style, but that's > > minor stuff ;-) > > That's how Jeff likes it in libata and my fingers are hardcoded to it, > but I do appreciate the paramount importance of each maintainer's > right to his/her own comment style, so here's the respinned patch. :-) Thanks a lot! I'll pass it right on for 2.6.22. -- Jens Axboe _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
