Am Montag, 12. Januar 2004 19:45 schrieb David Brownell:
> >>>>>[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...
> >>
> >>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.
>
> No, it was the second segment in that patch, which allocated
> memory for configuration descriptors. Enumeration logic.
OK, I'll have to redo this anyway. Do you agree that we need to use
GFP_NOIO in usb_ctrl_msg() due to usb_clear_halt() ?
> > Secondly, regarding usb_reset_device() the requirements there seem
> > quite subtle. ...
>
> Actually Alan's PF_MEMALLOC fix would solve that more comprehensively.
Unfortunately no. Usb_reset_device() is called directly, not from storage's
kernel thread.
> Alternatively, pass gfp_flags to usb_reset_device(), specifically to
> distinguish the normal GFP_KERNEL case from the usb-storage GFP_NOIO:
> two different kinds of "can sleep" context.
That's an API change.
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
