> > These are usb_control_message() and usb_clear_halt(). I was thinking
> > of doing a version for block devices that uses NOIO. Thus compatibility
> > is maintained in 2.4 and in 2.5 we'd merge and add another parameter to
> > the call.
>
> What did you think of Alan's notion of basically wrapping this
> option up as a device flag rather than a per-request flag, at
> least as a near term solution?
Certainly doable. I see no distinct advantage eitherway.
If we however decide that an additional parameter to usb_submit_urb() is
better anyway, we should not make this a device specific setting.
> Long term I think per-request options here are essential.
> Near term, flagging this at the device level may well be
> the least invasive solution.
Long term by any means yes.
Short term I am not sure.
> > > "out of memory" error reports in places it's not necessary (khubd
> > > as one example). But I'm not sure making usb_control_msg() and
> > > all its callers (and their callers ... :) take a new mem_flags
> > > parameter would be a reasonable API change.
> >
> > Which leads to the question whether another parameter to usb_submit_urb()
> > would be acceptable, too.
>
> usb_submit_urb() or usb_allocate_urb()? If there's a flag inside
> the URB that says use NOIO, no new parameter is needed when
> it's submitted.
To both.
usb_alloc_urb() clearly needs it and from then on we should keep it
consistent. Even so the example of the ASYNC_UNLINK flag should be a warning.
> > We could get rid of the in_interrupt() checks in
> > the host controler drivers, too.
>
> Everywhere. The in_interrupt() logic isn't sufficient anyway; anyone can
> call such routines while holding a lock and !in_interrupt(), then code that
> relies on that logic will conclude that it's OK to sleep (even NOIO) when
> in fact it really isn't.
You are right.
> There are some error checks for in_interrupt() that should stay. For
> example, synchronous unlinking while in_interrupt() is deeply evil.
It should result in a BUG().
> > Still we still deadlock if GFP_NOIO fails in swapping.
>
> Deadlock? Or just fail? Not the same.
The memory allocation will not fail immediately as the VM subsystem thinks
that it can free pages after writing them out. Eventually the scsi request
should timeout. I am not sure whether the error handling will work under this
conditions. The scsi layer will try to abort io. This under these
circumstances might fail as there is no urb to be unlinked. Then a reset is
called, which works only with memory allocation. Independently from that if
we depend on the device to free memory
we are still in deep trouble. The io error of the first page is not
guaranteed to free memory. An io error while writing out an mmaped page
should result in the task mmapping getting a signal. But can the signal be
caught ? I think under sufficiently unlucky circumstances we could deadlock.
> > We need a small pool
> > of free pages which GFP_NOIO will be serviced from and GFP_ATOMIC won't
> > be serviced from.
>
> That's not a USB-only problem though. And I'm not sure I see why
> the 'emergency pools' shared by GFP_ATOMIC and GFP_NOIO
> shouldn't be shared. (That's "__GFP_HIGH" ...)
I want this to work while we are flood pinged.
Regards
Oliver
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
