On 21.10.2015 22:15, Matthew R. Ochs wrote: > Ioctl threads that use scsi_execute() can run for an excessive amount > of time due to the fact that they have lengthy timeouts and retry logic > built in. Under normal operation this is not an issue. However, once EEH > enters the picture, a long execution time coupled with the possibility > that a timeout can trigger entry to the driver via registered reset > callbacks becomes a liability. > > In particular, a deadlock can occur when an EEH event is encountered > while in running in scsi_execute(). As part of the recovery, the EEH > handler drains all currently running ioctls, waiting until they have > completed before proceeding with a reset. As the scsi_execute()'s are > situated on the ioctl path, the EEH handler will wait until they (and > the remainder of the ioctl handler they're associated with) have > completed. Normally this would not be much of an issue aside from the > longer recovery period. Unfortunately, the scsi_execute() triggers a > reset when it times out. The reset handler will see that the device is > already being reset and wait until that reset completed. This creates > a condition where the EEH handler becomes stuck, infinitely waiting for > the ioctl thread to complete. > > To avoid this behavior, temporarily unmark the scsi_execute() threads > as an ioctl thread by releasing the ioctl read semaphore. This allows > the EEH handler to proceed with a recovery while the thread is still > running. Once the scsi_execute() returns, the ioctl read semaphore is > reacquired and the adapter state is rechecked in case it changed while > inside of scsi_execute(). The state check will wait if the adapter is > still being recovered or returns a failure if the recovery failed. In > the event that the adapter reset failed, the failure is simply returned > as the ioctl would be unable to continue. > > Reported-by: Brian King <brking@xxxxxxxxxxxxxxxxxx> > Signed-off-by: Matthew R. Ochs <mrochs@xxxxxxxxxxxxxxxxxx> > Signed-off-by: Manoj N. Kumar <manoj@xxxxxxxxxxxxxxxxxx> > Reviewed-by: Brian King <brking@xxxxxxxxxxxxxxxxxx> > Reviewed-by: Daniel Axtens <dja@xxxxxxxxxx> Reviewed-by: Tomas Henzl <thenzl@xxxxxxxxxx> Tomas -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
