Am Montag, 12. Januar 2004 09:14 schrieben Sie:
> Oliver Neukum wrote:
> > Am Montag, 12. Januar 2004 05:08 schrieben Sie:
> >
> >>>[EMAIL PROTECTED], 2004-01-12 00:26:13+01:00, [EMAIL PROTECTED]
> >>> - avoid GFP_KERNEL in block IO path
> >>>
> >>
> >>What you show below is pretty remote form a block IO path...
> >
> >
> > Error handling by usb_reset_device()
>
> No, that'd be the "device vanishes and re-enumerates" path, which
> comes up as an entirely new device. i/o directed at the old one
> will land on the floor; bits falling out the end of the ethernet
> cable, etc
Ok, I am an idiot.
Two issues. Firstly, I was mistaken. The line _you_ are referring to
is in usb_clear_halt, isn't it? I was looking at the wrong patch.
Now, usb_clear_halt() seems to be in the error handling code path, isn't it?
Secondly, regarding usb_reset_device() the requirements there seem
quite subtle. It seems to me that in the success case, we must always
use GFP_NOIO and in the device going away code path we must use
GFP_NOIO until the device has been set offline. As SCSI hotplug is
hopeless in 2.4 anyway, I'd always use GFP_NOIO from that context.
IIRC the orginal motivation for introducing the second argument to
usb_submit_urb() was exactly this problem. Somebody had reported
a deadlock during reset. We thought that 2.4 would be hard to fix.
I am inclined to simply let Alan's solution stand and leave it at that.
Greg, please disregard the patch.
Regards
Oliver
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
