On Tue, 20 Jan 2015, Heiko Przybyl wrote:
> I'm not 100% sure, but then it's probably a race between urb
> enqueuing (duplicates?) and the watchdog orphan cleanup.
>
> The crash log already shows the double list add in ohci_urb_enqueue
> "
> ohci-hcd.c:238: list_add(&ed->in_use_list, &ohci->eds_in_use);
> "
> This is probably due to the ed returned by ed_get() being reused before the
> watchdog ran, thus the same in_use_list re-added to ohci.eds_in_use.
But this won't happen unless ed->state was ED_IDLE; and then
ed_schedule() changes ed->state to ED_OPER before ed is added to the
in_use_list.
> Entries seem to get removed in finish_unlinks()
> "
> ohci-q.c:1090: list_del(&ed->in_use_list);
> "
> with list_del() poisoning the next/prev pointers of the removed entry.
And finish_unlinks() is where ed->state gets set back to ED_IDLE.
Furthermore, all these operations take place under the protection of
ohci->lock, so they can't race with each other.
They have to happen in strict sequence: list_add, list_del, list_add.
The second list_add can't occur until after the list_del, because
ed->state won't be equal to ED_IDLE until then.
At least, that's how it's _supposed_ to work...
> Now with the watchdog starting cleanup it iterates over the ohci.eds_in_use
> list
> that still has the second very same entry of in_use_list we double-added (but
> now with 0xdead... pointers) and we fault on
> "
> ohci-hcd.c:761: if (ed->pending_td) {
> "
>
> I hope that makes any sense? I'll hook up the list checking tomorrow. Though I
> haven't hit the (double-add) problem again, since the bug report. Seems pretty
> specific the whole thing.
It's a puzzling problem. I hope you can find the cause.
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
