linux-kernel - Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch doesn't support it

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:	Thu, 07 Dec 2006 20:23:01 +1100
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Linus Torvalds <torvalds@...l.org>
CC:	Roman Zippel <zippel@...ux-m68k.org>,
	Matthew Wilcox <matthew@....cx>,
	Christoph Lameter <clameter@....com>,
	David Howells <dhowells@...hat.com>, akpm@...l.org,
	linux-arm-kernel@...ts.arm.linux.org.uk,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH] WorkStruct: Implement generic UP cmpxchg() where an arch
 doesn't support it

Linus Torvalds wrote:
> 
> On Thu, 7 Dec 2006, Roman Zippel wrote:
> 
>>On Wed, 6 Dec 2006, Matthew Wilcox wrote:
>>
>>
>>>To be honest, it'd be much easier if we only defined these operations on
>>>atomic_t's.  We have all the infrastructure in place for them, and
>>>they're fairly well understood.  If you need different sizes, I'm OK
>>>with an atomic_pointer_t, or whatever.
>>
>>FWIW Seconded.
> 
> 
> I disagree.
> 
> Any _real_ CPU will simply never care about _anything_ else than just the 
> size of the datum in question. There's absolutely no point to only allow 
> it on certain types, especially as we _know_ those certain types are 
> already going to be more than one, and we also know that they are going to 
> be different sizes. In other words, in reality, we have to handle a 
> sizeable subset of the whole generic situation, and the "on certain types 
> only" situation is only going to be awkward and irritating.
> 
> For example, would we have a different "cmpxchg_ptr()" function for the 
> atomic pointer thing? With any reasonable CPU just depending on the _size_ 
> of the type, I don't see what the problem is with just doing the 
> bog-standard "cmpxchg_8/16/32/64" and having the bog-standard case- 
> statement in a header file to do it all automatically for you, and then we 
> don't need to worry about it.

What's wrong with using atomic_cmpxchg? For unsigned long / pointers,
there is a patch to implement atomic_long_cmpxchg.

Some architectures simply can't implement cmpxchg on memory that may
be modified in arbitrary ways. If you add some more conditions to use
cmpxchg, then you weaken it (ie. can't use it for synchronisation
with userspace) and on top of that you don't get the easy static
checking that atomic_t gives you.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 
-
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/