linux-kernel - Re: [PATCH] Replace completions with semaphores

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]

Date:	Mon, 14 Apr 2008 17:39:28 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Matthew Wilcox <matthew@....cx>
Cc:	Roland Dreier <rdreier@...co.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Oeser <ioe-lkml@...eria.de>,
	Daniel Walker <dwalker@...sta.com>,
	linux-kernel@...r.kernel.org, Linus Torvalds <torvalds@...l.org>
Subject: Re: [PATCH] Replace completions with semaphores

* Matthew Wilcox <matthew@....cx> wrote:

> On Sun, Apr 13, 2008 at 09:08:33AM +0200, Ingo Molnar wrote:
> > but semaphores will be _removed_, _completely_. Rewriting them in 
> > generic C code is just the first step towards that - it consolidates all 
> > the myriads of semaphore implementations that Linux has spread out.
> 
> I think you're dreaming. [...]

no, i'm hoping for a simpler and thus more maintainable kernel.

> [...]  We have 11 places in the tree that currently demand to use a 
> counting semaphore (with 'n' plausibly greater than 1). [...]

which ones exactly are these places that demand the use of a counting 
semaphore? I cannot think of a single place where it's the best choice, 
let alone one where it's the only choice.

And if there's just 5 isolated places in the kernel that would need a 
different locking primitive then i say that it's probably not worth it. 
Locking is at the center of every data structure and the clarity and 
simplicity of basic data structure operations is paramount IMHO. 

Semaphores are i think a relic from the days when people thought that 
parallelism can be best achieved via complexity and rafinery of locking 
primitives - regardless of how usable and debuggable those APIs end up 
to be. Today we can go extremely parallel with very simple and robust 
primitives.

> [...] If we remove the facility, these places are going to invent 
> their own weird locking schemes.

i'm not worried about weird locking anymore - lockdep tends to expose 
them rather nicely and the lack of lockdep coverage for open-coded 
locking schemes tends to be a barrier as well. The past 2 years have 
shown that people want lockdep coverage for just about everything where 
it can be applied: workqueues, special locks, etc. (there's even 
questions about whether it could be extended to cover user-space locks.)

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