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.1.00.0804151101590.2879@woody.linux-foundation.org>
Date:	Tue, 15 Apr 2008 11:14:06 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Matthew Wilcox <matthew@....cx>
cc:	Andi Kleen <andi@...stfloor.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Bart Van Assche <bart.vanassche@...il.com>,
	Roland Dreier <rdreier@...co.com>, Ingo Molnar <mingo@...e.hu>,
	Ingo Oeser <ioe-lkml@...eria.de>,
	Daniel Walker <dwalker@...sta.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Replace completions with semaphores



On Tue, 15 Apr 2008, Matthew Wilcox wrote:
> 
> > In other words, what makes me not like this is hat we first turn 
> > semaphores into the generic code (which is largely what completions were: 
> > just a special case of the generic semaphores!) and then turns completions 
> > into these things. That just doesn't make any sense to me!
> 
> Blame me for not realising that completions were semaphores under a
> different name.

The origin of completions is literally the semaphore code - just 
simplified to use spinlocks and be usable as just a mutex. We used to use 
semaphores, and because of the subtle race with lockless semaphores I 
wrote that stupid completion code as a "generic semaphore with a very 
specific usage schenario" and called them "completions".

The completions _could_ have been extended/used as mutex semaphores, but 
the difference was really the mental model for them. That then limited the 
implementation of them: the functions working on completions are defined 
on purpose to be limited - it doesn't really have "up()" and "down()" 
functions: "complete()" is really a up(), but "wait_for_completion()" is 
more like a "wait_until_I_could_do_a_trydown()" function.

Would it make sense to use completions for countable events too? Yeah. In 
fact, we have some things that really would like to do counting, both in 
the sense of "wait for <n> events to all complete" _and_ in the sense of 
"allow up to <n> events to be outstanding". Both of which could be done as 
a counting function (just make "complete" increment the counter, and then 
make "wait for <n> events" initialize it to negative, while "allow <n>
outstanding events" would be a positive counter, and make 
"wait_for_completion()" basically be a "decrement and wait until it 
is zero".

IOW, completions() really follow the same patterns as semaphores, and it 
*does* make sense to just have one single code-base. But if we want to 
make semaphores go away, I think that it would be better to implement 
semaphores in terms of "extended completions" rather than the other way 
around. That way, we could one day really get rid of semaphores entirely.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ