linux-kernel - Re: 2.6.22-rc6 spurious hangs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20070629135848.GA332@tv-sign.ru>
Date:	Fri, 29 Jun 2007 17:58:48 +0400
From:	Oleg Nesterov <oleg@...sign.ru>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Thomas Sattler <tsattler@....de>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Daniel Mack <daniel@...u.de>, Holger Waechtler <holger@...u.de>
Subject: Re: 2.6.22-rc6 spurious hangs

On 06/29, Ingo Molnar wrote:
> * Oleg Nesterov <oleg@...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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/