Oliver Neukum wrote:
At least I fix the bugs I find.
Your patch included one fix and one bug; I objected to the bug. And the fix is merged in the core-0122 patch I submitted a couple days ago. (Can't let Greg's queue get _too_ thin!)
It doesn't. You can cancel only what you have submitted. Which the loop may have done, or may not have done. This is code running in kernel mode it sleeps only with TASK_UNINTERRUPTIBLE. It must be running in some context to run at all. As it runs in the context of the kernel thread in storage if used by the storage driver, that kernel thread will run only that code until the loop terminates. Hence the driver has just died. Not that hard to understand, is it?
The SCSI EH thread issues usb_sg_cancel() when it needs to, which causes io->status to become nonzero and terminates the loop. No, the invariant that usb_sg_cancel() terminates the other thread's usb_sg_wait() is not hard to understand at all. - Dave ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel