On Sat, 31 May 2003, Oliver Neukum wrote:
>
> + /* Normally the current state is RUNNING. If the control thread
> + * hasn't even started processing this command, the state will be
> + * IDLE. Anything else is a bug. */
> + if (state != US_STATE_RUNNING && state != US_STATE_IDLE) {
> + printk(KERN_ERR USB_STORAGE "Error in %s: "
> + "invalid state %d\n", __FUNCTION__, state);
> + return FAILED;
> + }
> +
> + /* Set state to ABORTING, set the ABORTING bit, and release the lock */
> + atomic_set(&us->sm_state, US_STATE_ABORTING);
> + set_bit(US_FLIDX_ABORTING, &us->flags);
> + scsi_unlock(host);
> +
> + /* If the state was RUNNING, stop an ongoing USB transfer */
> + if (state == US_STATE_RUNNING)
> + usb_stor_stop_transport(us);
> +
> + /* Wait for the aborted command to finish */
> + wait_for_completion(&us->notify);
>
> If the state here is US_STATE_IDLE, who calls the complete?
The control thread routine does, just as it does if the state is
US_STATE_RUNNING. You see, there's a race here. It's possible that the
command-abort gets called before the control thread has started to process
the command. (This actually happened to me once, though not by accident
-- it was a result of some other change I had made.) Once the control
thread finally wakes up and begins processing the command, it will see
that the command has already been aborted and skip directly to the part
where it signals the completion event.
Alan Stern
-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
