| 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
| ||
|
Date: Mon, 3 Mar 2008 10:42:35 -0500 (EST) From: Alan Stern <stern@...land.harvard.edu> To: Pavel Machek <pavel@....cz> cc: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>, Linus Torvalds <torvalds@...ux-foundation.org>, Andrew Morton <akpm@...l.org>, Zdenek Kabelac <zdenek.kabelac@...il.com>, <davem@...emloft.net>, "Rafael J. Wysocki" <rjw@...k.pl>, Pierre Ossman <drzeus-mmc@...eus.cx>, Kernel development list <linux-kernel@...r.kernel.org>, pm list <linux-pm@...ts.linux-foundation.org> Subject: Re: [patch] Re: using long instead of atomic_t when only set/read is required On Mon, 3 Mar 2008, Pavel Machek wrote: > Hi! > > > > Alan thinks that `subj` is correct... > > > > More precisely, reads and writes of pointers are always atomic. That > > is, if a write and a read occur concurrently, it is guaranteed that the > > read will obtain either the old or the new value of the pointer, never > > a mish-mash of the two. If this were not so then RCU wouldn't work. Right, Paul? > Ok, so linux actually atomicity of long? > > If so, this should probably be applied... > > Signed-off-by: Pavel Machek <pavel@...e.cz> > > diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt > index 4ef2450..0a7d180 100644 > --- a/Documentation/atomic_ops.txt > +++ b/Documentation/atomic_ops.txt > @@ -21,6 +21,9 @@ local_t is very similar to atomic_t. If > updated by one CPU, local_t is probably more appropriate. Please see > Documentation/local_ops.txt for the semantics of local_t. > > +long (and int and void *) can be used instead of atomic_t, if all you > +need is atomic setting and atomic reading. > + > The first operations to implement for atomic_t's are the initializers and > plain reads. Yes indeed. This fact doesn't seem to be documented anywhere, but it is clearly a requirement of the kernel. I would make the text a little more explicit, see below. Alan Stern ------------------------------------------------------- Atomicity of reads of write for pointers and integral types (other than long long) should be documented. Signed-off-by: Alan Stern <stern@...land.harvard.edu> --- Index: usb-2.6/Documentation/atomic_ops.txt =================================================================== --- usb-2.6.orig/Documentation/atomic_ops.txt +++ usb-2.6/Documentation/atomic_ops.txt @@ -21,6 +21,21 @@ local_t is very similar to atomic_t. If updated by one CPU, local_t is probably more appropriate. Please see Documentation/local_ops.txt for the semantics of local_t. +For all properly-aligned pointer and integral types other than long +long, the kernel requires simple reads and writes to be atomic with +respect to each other. That is, if one CPU reads a pointer value at +the same time as another CPU overwrites the pointer, it is guaranteed +that the reader will obtain either the old or the new value of the +pointer, never some mish-mash combination of the two. Likewise, if +one CPU writes a long value at the same time as another CPU does, it +is guaranteed that one or the other of the values will end up stored +in memory, not some mish-mash combination of bits. + +Thus, if all you need is atomicity of reading and writing then you can +use plain old ints, longs, or pointers; you don't need to use +atomic_t. (But note: This guarantee emphatically does not apply to +long long values or unaligned values!) + The first operations to implement for atomic_t's are the initializers and plain reads. -- 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