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.0612121828060.3535@woody.osdl.org>
Date:	Tue, 12 Dec 2006 18:30:05 -0800 (PST)
From:	Linus Torvalds <torvalds@...l.org>
To:	Nick Piggin <nickpiggin@...oo.com.au>
cc:	Russell King <rmk+lkml@....linux.org.uk>,
	David Howells <dhowells@...hat.com>,
	Andrew Morton <akpm@...l.org>,
	"David S. Miller" <davem@...emloft.net>, matthew@....cx,
	Linux Kernel Mailing List <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 Wed, 13 Dec 2006, Nick Piggin wrote:
> 
> parisc seems to, but sparc uses its own open coded spinlock for bitops, and
> the array of regular spinlocks for atomic ops. OTOH, consolidating them
> might give more scalable code *and* a smaller cacheline footprint?

Yeah, I think you'd actually end up with better behaviour by just sharing 
the lock logic, so I don't think there are any downsides there.

> > 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? 
> 
> AFAIK no architecture does anything special, so maybe a generic converter
> would be best, until one comes along that does. (the only thing of note
> really is that half of the atomics use volatile types and half don't, is
> that a problem?).

No, the cast would cast away any such differences, and since anybody would 
have to use asm for the actual implementation, the code can't care about 
the absense or presense of "volatile" anyway.

		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/