Oliver Neukum wrote:
>
> > > 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.
>
Actually it should be an endpoint specific setting.
There are a lot of things that are endpoint specific:
e.g. maxpacketsize, toggle bit, startingpoint and intervall
of INTR transfers, queueingpoint for URBs,...
And all that information is spread around. Some bits are in the
device struct some bits are in the URBs pipe slot. This can cause
a lot of inconsistency. E.g. the urb->dev field and the
usb_pipedevice (urb->pipe) can address two different devices within
the same URB and so on.
I think it would be better to use a more socket like approach
(maybe in 2.5):
An URB is like a socket_buffer and an endpoint is like a socket.
So the endpoint-entries would hold all that static information of an USB
endpoint and the URBs just points to the data blocks.
- Roman
> > 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
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
