On Thu, Mar 1, 2012 at 6:29 AM, James Bottomley
<James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote:
>> Hmm, what about something like:
>>
>> if (current != host->ehandler) {
>> schedule_reset_to_run_in_eh_context():
>> wait_for_eh();
>> } else
>> do_reset();
>
> I think that would work for me ... as long as the wait doesn't cause
> entangled deadlocks (I can't think of any at the moment, but I'll think
> a bit more deeply about it).
So there is a deadlock due to:
commit d7a1bb0a04ca835bffc0a91e64ab827dfba7d8f5
Author: James Smart <James.Smart@xxxxxxxxxx>
Date: Wed Mar 8 14:50:12 2006 -0500
[SCSI] Block I/O while SG reset operation in progress - the midlayer patch
The scsi midlayer portion of the patch
Signed-off-by: James Smart <James.Smart@xxxxxxxxxx>
Signed-off-by: James Bottomley <James.Bottomley@xxxxxxxxxxxx>
...this adds shost->tmf_in_progress to scsi_host_in_recovery(), so I
can't "wait for eh" because the exit condition for that wait is
"!scsi_host_in_recovery()". But since sg_reset is opened O_NONBLOCK
by default and that is likely the only non-eh reason for calling the
eh_{bus|device}_reset_handler routines I'll just make this routine
asynchronously queue a reset and return.
--
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
