lkml.org 
[lkml]   [2000]   [Aug]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
Subject2.4.0-test: atomic_t unsafe on UP systems?
Hi,

While looking at the atomic_t definition for i386, I found the fact that
"counter" isn't volatile is rather strange. Especially since a
volatile_read() doesn't add the "volatile" which would make the (probably
bogus example):

while (atomic_read(&atom_var));

dangerous as gcc might optimize it into registers... [1]
Granted, the example is probably not a good one, but I hope it shows the
problem.

Stranger things might happen if the variable is also modified from
interrupt-context... as there is nothing that stops gcc from optimizing
the variable in the the non-interrupt code into registers.

The patch below will make the counter always volatile; it seems to be the
correct thing to do.

Greetings,
Arjan van de Ven


[1] No doubt the crusoe will handle this nicely

--- linux/include/asm-i386/atomic.h.org Tue Aug 29 18:44:42 2000
+++ linux/include/asm-i386/atomic.h Tue Aug 29 18:44:59 2000
@@ -19,11 +19,7 @@
*/
#define __atomic_fool_gcc(x) (*(volatile struct { int a[100]; } *)x)

-#ifdef __SMP__
typedef struct { volatile int counter; } atomic_t;
-#else
-typedef struct { int counter; } atomic_t;
-#endif

#define ATOMIC_INIT(i) { (i) }

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.024 / U:5.720 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site