Messages in this thread | | | Date | Fri, 29 Jun 2007 17:58:48 +0400 | From | Oleg Nesterov <> | Subject | Re: 2.6.22-rc6 spurious hangs |
| |
On 06/29, Ingo Molnar wrote: > * Oleg Nesterov <oleg@tv-sign.ru> wrote: > > > Yes, I think cinergyt2 is buggy. > > > cinergyt2_release() does flush_scheduled_work() under cinergyt2->sem. > > flush_scheduled_work() hangs because cinergyt2_query_rc() waits for > > the same cinergyt2->sem. > > > > ->disconnect_pending is used without any locks/barriers, perhaps this > > is the reason.
I misread cinergyt2_release, it checks !->disconnect_pending, so it is very clear why cinergyt2_query_rc() tries to take the mutex.
> > I'll try to look further tomorrow. In any case, cinergyT2 should not > > use flush_scheduled_work() at all. > > would the hack below be worth trying, to see whether there are any > further problems? > > Ingo > > Index: linux/drivers/media/dvb/cinergyT2/cinergyT2.c > =================================================================== > --- linux.orig/drivers/media/dvb/cinergyT2/cinergyT2.c > +++ linux/drivers/media/dvb/cinergyT2/cinergyT2.c > @@ -523,7 +523,6 @@ static int cinergyt2_release (struct ino > > if (!cinergyt2->disconnect_pending && (file->f_flags & O_ACCMODE) != O_RDONLY) { > cancel_delayed_work(&cinergyt2->query_work); > - flush_scheduled_work(); > cinergyt2_sleep(cinergyt2, 1); > }
I don't think we can just kill flush_scheduled_work(). We can use cancel_rearming_delayed_work() instead of cancel_delayed_work()+flush_scheduled_work()
Still we can't do this under cinergyt2->sem, because cinergyt2_query() takes it too. This all looks very wrong to me, I hope maintaners can explain.
I think cinergyt2_query() and cinergyt2_query_rc() should not use ->disconnect_pending at all. cinergyt2_disconnect() should set ->disconnect_pending = 1 and cancel both delayed_works.
cinergyt2_release() checks !->disconnect_pending and does the cancel without mutex.
Oleg.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |