Re: 2.6.15-mm4: sem2mutex problem in USB OHCI

[Ingo Molnar]

* Andrew Morton <akpm@xxxxxxxx> wrote:

> >  Badness in __mutex_trylock_slowpath at kernel/mutex.c:281
> > 
> >  Call Trace: <IRQ> <ffffffff80148d8d>{mutex_trylock+141}
> >
> >         <ffffffff880abaf0>{:ohci_hcd:ohci_hub_status_data+480}
> >         <ffffffff802d25d0>{rh_timer_func+0} <ffffffff802d24c3>{usb_hcd_poll_rh_status+67}
> >         <ffffffff802d25d0>{rh_timer_func+0} <ffffffff802d25d9>{rh_timer_func+9}
> >         <ffffffff8013a3cc>{run_timer_softirq+396}

> err, taking a mutex from softirq context.

btw., i'm wondering how the down_trylock() can be correct code: what 
guarantees progress if the trylock happens to fail all the time? (or 
just happens to fail frequently, due to some other, unrelated dev->mutex 
workload)

Shouldnt this code use some other solution to process these timed events 
more robustly?

	Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/