linux-kernel - Re: [patch 00/30] semaphore cleanup

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: <alpine.LFD.2.00.1009072219400.2477@localhost6.localdomain6>
Date:	Tue, 7 Sep 2010 22:23:06 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Arnd Bergmann <arnd@...db.de>
cc:	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Peter Zijlstra <peterz@...radead.org>,
	Christoph Hellwig <hch@...radead.org>
Subject: Re: [patch 00/30] semaphore cleanup

Arnd,

On Tue, 7 Sep 2010, Arnd Bergmann wrote:

> On Tuesday 07 September 2010 17:38:33 Thomas Gleixner wrote:
> > Some of those can be converted to completions, but most of them have
> > utterly borked semantics. I'm not sure if its worth the trouble to
> > actually change all this as most of that stuff is ancient. Real
> > semaphores are not going away (at least not the counting type ones).
> 
> Ok. I thought I had seen a series from Ingo some time ago that actually
> converted all of them to something else, but maybe I was mistaken.
> 
> Not sure if there is anything to be gained (other than more work) from
> merging semaphore and rw_semaphore into a single implementation that
> is both counting and read-write.
> 
> One problem I see (not with your series, just with semaphores in
> general) is that they keep creeping in through drivers/staging: About
> half the users we currently have are in staging. Obviously they get
> removed from there in order for drivers to graduate from staging, but
> not exposing the interface to device drivers would reduce the number
> of bad choices for authors to make.

sure, but most of them are really the init_MUTEX[_LOCKED] type which
has been copied over and over again for almost a decade.

That's going away, so people are actually forced to look into the
alternative solutions. And I do not worry too much about staging/*

Thanks,

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