On Thu, 2005-09-08 at 11:59 -0400, Alan Stern wrote:
> I don't understand your reasoning. With your new system, you end up with
> two threads doing this:
>
> Removal thread Error handler thread
> ------------------------- ---------------------------
> Go from RUNNING to RECOVERY
> Try to go to CANCEL, fail
> Go to CANCEL_RECOVERY
> race: Go to DEL_RECOVERY Try to go to RUNNING, fail
Actually, no, that's why we have the parallel EH states ... let me put
in the events that trigger state transitions so you can see what
happens:
EH thread finishes
<---------------
EH thread begins
---------------->
<---------
running ---------> recovery
| |
| | scsi_remove_host() called
v <---------- v
cancel ----------> recover/cancel
| |
| | scsi_remove_host finishes visibility removal
v v
del <------------ recover/del
So the EH is allowed to activate in either running or cancel states, but
goes through its own state transition eventually coming back to del when
it finishes. Once the EH gets into recover/cancel it can never
transition back to running.
> At least, that's how it would work if you allow the RECOVERY -> CANCEL
> transition. Either way you end up in the correct state. So what's wrong
> with the old (current) system?
It's just nasty on two counts:
1) we have an incorrect bifurcation in the state model and
2) we never actually enforce any of the state transitions.
James
-
: 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
