----- Original Message -----
> From: "Steve Longerbeam" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, May 07, 2001 10:39 AM
> Subject: Re: [linux-usb-devel] OHCI ed-hash-chain corruption (kernel BUG at
>usb-ohci.h:465!)
>
> Martin Diehl wrote:
> > ...
> >
> > seems my tests are pretty good in hitting some critical paths ;-)
> > This one happened during load/consistency test using usb-ohci on
> > UP testbox and 2.4.4-vanilla. (ksymoops attached)
I like such tests ... :) Though I should have caught this one ...
Testing can't always find such bugs!
> > Btw, the add/remove operation on the hash collision chains appear to be
> > unprotected - at least on hash_*()/dma_to_*() api level. Are they
> > guaranteed to be always called inside some spinlock (irqsafe) - like it
> > was when the BUG was hitted?
>
> Hi Martin,
>
> You're right. I found a case where td_alloc() is called by sohci_submit_urb(),
> which is unprotected. There may be others too.
Well, there are only two calls to td_alloc, and only the one isn't protected.
Seems only that loop in sohci_submit_urb is troublesome.
> I've attached a simple patch
> against 2.4.4-vanilla that adds locks around hash_add_ed_td() and
> hash_free_ed_td(). I hope this fixes the chaining corruption.
Seems like since updated versions of this patch fix the BUG(),
this is likely the root cause.
But in general I dislike adding more locks -- gets error prone.
How about a simpler fix? (a) update sohci_submit_urb to use
the existing spinlock in that loop, (b) make both calls to td_alloc()
pass SLAB_ATOMIC so nothing tries sleeping while holding that
spinlock, (c) repeat both for the dev_alloc() call in sohci_alloc_dev.
Note that (b) is another latent bug, one of the type testing is
less likely to find! An earlier memory patch had that problem
only the ep_add_ed() call.
- Dave
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
