I wrote:
> Is it attempting to wake the scsi_eh_3 thread while scsi_error_handler
> is still processing an EH, which then calls scsi_restart_operations and
> puts the scsi_eh_3 thread back to sleep again?
It does look to me as if there is a potential race between the scsi_eh thread
and the wake-up mechanism.
host_eh_scheduled is read here in scsi_error_handler:
set_current_state(TASK_INTERRUPTIBLE);
while (!kthread_should_stop()) {
if ((shost->host_failed == 0 && shost->host_eh_scheduled == 0) ||
For scheduling an EH, scsi_schedule_eh takes the shost->host_lock, increments
shost->host_eh_scheduled, and then wakes the EH thread. If this happens
between the scsi_eh thread reading host_eh_scheduled and sending itself to
sleep, then nothing will wake up the thread and host_eh_scheduled will not
be inspected again.
Is there some mechanism that I've missed to prevent this from happening?
Bruce.
Latest News at: http://www.indigovision.com/index.php/en/news.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
