2.4.0-test: atomic_t unsafe on UP systems?

From: Arjan van de Ven (arjan@fenrus.demon.nl)
Date: Tue Aug 29 2000 - 12:58:08 EDT

  • Next message: Alexander Viro: "Re: hfs support for blocksize != 512"

    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/



    This archive was generated by hypermail 2b29 : Tue Aug 29 2000 - 13:00:01 EDT