Re: 2.6.22-rc6 spurious hangs

[Oleg Nesterov <oleg@tv-sign.ru>]

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.