Hello, I wrote:
The end of musb_h_disable() is totally insane:
list_for_each_entry_safe_from()
will obviously cause a kernel oops given a NULL pointer and
otherwise it'd be
too late to give back the first URB in the list as
musb_cleanup_urb() called
beforehand would have already done that, unlinking it from the URB
list and
thus causing the interator to loop on this URB forever. The list
interator is
not safe to use either as URBs may be explicitly dequeued by upper
layers while
it's running. As if that was not enough) musb_giveback() is not safe
to call
from here either because:
- when we're disabling an endpoint with an URB being currently
active, once
URB list empties, we must immediately switch to serving the next
endpoint
(represented to 'struct musb_qh') or risk the shecdule list being
stalled;
- when we're disabling an endpoint not being currently active,
musb_giveback()
may e.g. spoil the saved data toggle since it'll be reading it
while another
logical endpoint ('struct musb_qh') is active.
Finally, it doesn't seem to be safe to read 'hep->hcpriv' before
taking hold of
'musb->lock'... phew. :-)
Signed-off-by: Sergei Shtylyov <[email protected]>
---
I wonder who wrote the original code... :-/
This patch replaces a part of the patch originally posted by Ajay
Kumar Gupta
(http://marc.info/?l=linux-usb&m=122284678326862) that however,
dealt with the
issue incorrectly...
I am getting kernel-panic as logged below. Seems issue is not yet
solved completely.
Had you also applied the musb_urb_enqueue() fix?
Will post review comments later.
To reproduce,
1. Use bulk-mux case by doing the change in musb_schedule() as below,
/* use bulk reserved ep1 if no other ep is free */
if (/*best_end < 0 && */ qh->type == USB_ENDPOINT_XFER_BULK) {
OR just revert below patch.
usb: musb: fix BULK request on different available endpoints
[...]
Sigh, the problem is that I don't have the board which has MUSB and
boots the recent kernel.org kernel -- DaVinci EVM appeared to be dead.
Well, I can try to carry my patches into the DaVinci tree or import
your patches into our working tree... The issue is also that I still
don't have enough time. :-(
Oh, I've just realized that don't have this patch in the internal
tree, so it should be quite good for reproducing... I'll wait for your
reply though before doing that.
WBR, Sergei
_______________________________________________
Davinci-linux-open-source mailing list
[email protected]
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
