linux-kernel - Re: [PATCH 1/2] WorkStruct: Add assign_bits() to give an atomic-bitops safe assignment

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]

Message-ID: <Pine.LNX.4.64.0612121726150.3535@woody.osdl.org>
Date:	Tue, 12 Dec 2006 17:36:33 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Russell King <rmk+lkml@....linux.org.uk>
cc:	David Howells <dhowells@...hat.com>, akpm@...l.org,
	davem@...emloft.com, matthew@....cx, linux-kernel@...r.kernel.org,
	linux-arch@...r.kernel.org
Subject: Re: [PATCH 1/2] WorkStruct: Add assign_bits() to give an atomic-bitops
 safe assignment

On Tue, 12 Dec 2006, Russell King wrote:
> 
> This seems to be a very silly question (and I'm bound to be utterly
> wrong as proven in my last round) but why are we implementing a new
> set of atomic primitives which effectively do the same thing as our
> existing set?
> 
> Why can't we just use atomic_t for this?

Well, others have answered that ("wrong sizes"), but I'm wavering on using 
atomic_long_t. I have to admit that I'd rather not add a new accessor 
function, when it _should_ be easier to use the current ones.

That does depend on every arch maintainer saying they're ok with mixing 
bitops and "atomic*_t"s. It would also require us to at least add some 
_minimal_ function to get at the actual value, and turn the pointer into a 
"unsigned long *" for the bitop functions.

I would _hope_ that people hopefully already use the same locking for 
atomic_t and for bitops, and that arch maintainers could just say "sure, 
that works for me". Obvously, anybody with LL/SC or otherwise just 
basically atomic bitops (which covers a fair part of the spectrum) should 
be ok, but sparc and the usual cast of suspects would have to say that 
it's ok.

Should we also just make the rule be that the architecture _must_ allow 
the silly

	(atomic_long_t *) -> (unsigned long *)

casting (so that we can make _one_ generic inline function that takes an 
atomic_long_t and returns the same pointer as an "unsigned long *" to make 
bitop functions happy), or would this have to be another arch-specific 
function?

Comments? 

			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/