linux-kernel - Re: [PATCH] sound_core.c: Remove BKL from soundcore

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20091011215131.03655961@lxorguk.ukuu.org.uk>
Date:	Sun, 11 Oct 2009 21:51:31 +0100
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Arjan van de Ven <arjan@...radead.org>
Cc:	Jonathan Corbet <corbet@....net>, John Kacur <jkacur@...hat.com>,
	linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Vincent^M^J Sanders <vince@...tec.co.uk>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: [PATCH] sound_core.c: Remove BKL from soundcore_open

> > It won't. Instead you get situations like one ioctl blocking another
> > to an unrelated device that just causes weird failures and performance
> > problems, or in some cases deadlocks.
> 
> yes the bkl using code will be slower because it'll now hit contention.

No - the mutex using ioctls that sleep now block each other out - this
mistake was made in some video drivers.

> > Open routines block so it takes about 5 seconds of thought to realise
> > that using a mutex here is brain dead and doesn't work.
> 
> it also takes 5 seconds to realize "uh oh. they block. BKL is rather
> limited in what it provides".

Which is what the code was written for.

This is why you can't just slap in a mutex but have to push it down.

Chances are that for a lot of small drivers you go

lock_kernel
foo->op()
unlock_kernel


to

foo->op()

	op()
	lock_kernel
	blah
	unlock_kernel

correctly on to

	op()
	{
		mutex_lock(instance->lock);
		blah
		mutex_unlock(instance->lock);

but you can't jump those steps and hope to get it right.

Alan
--
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/