|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] mini-os: fix bit ops comments and memory clobbers.
On 18/06/14 09:29, Samuel Thibault wrote:
> This fixes comments about test_and_clear_bit, set_bit and clear_bit,
> which are actually not atomic, can be reordered and are not memory
> barriers.
>
> This also drops the empty LOCK and LOCK_PREFIX macros which bring to the
> confusion.
>
> This also adds missing memory clobbers to set_bit and clear_bit.
>
> Signed-off-by: Samuel Thibault <samuel.thibault@xxxxxxxxxxxx>
Do you mean reordered by the compiler or reordered by the pipeline? The
memory clobbers prevent the compiler reordering, but lack of [lsm]fence
instructions allow the pipeline to reorder the reads/writes if it chooses.
~Andrew
>
> diff --git a/extras/mini-os/include/x86/os.h b/extras/mini-os/include/x86/os.h
> index f193865..510c632 100644
> --- a/extras/mini-os/include/x86/os.h
> +++ b/extras/mini-os/include/x86/os.h
> @@ -152,8 +152,6 @@ do {
> \
> #endif
>
>
> -#define LOCK_PREFIX ""
> -#define LOCK ""
> #define ADDR (*(volatile long *) addr)
> /*
> * Make sure gcc doesn't try to be clever and move things around
> @@ -200,15 +198,13 @@ static inline unsigned long __xchg(unsigned long x,
> volatile void * ptr, int siz
> * @nr: Bit to clear
> * @addr: Address to count from
> *
> - * This operation is atomic and cannot be reordered.
> - * It can be reorderdered on other architectures other than x86.
> - * It also implies a memory barrier.
> + * This operation is not atomic and can be reordered.
> */
> static inline int test_and_clear_bit(int nr, volatile unsigned long * addr)
> {
> int oldbit;
>
> - __asm__ __volatile__( LOCK
> + __asm__ __volatile__(
> "btrl %2,%1\n\tsbbl %0,%0"
> :"=r" (oldbit),"=m" (ADDR)
> :"Ir" (nr) : "memory");
> @@ -241,22 +237,17 @@ static inline int variable_test_bit(int nr, const
> volatile unsigned long * addr)
> * @nr: the bit to set
> * @addr: the address to start counting from
> *
> - * This function is atomic and may not be reordered. See __set_bit()
> - * if you do not require the atomic guarantees.
> - *
> - * Note: there are no guarantees that this function will not be reordered
> - * on non x86 architectures, so if you are writting portable code,
> - * make sure not to rely on its reordering guarantees.
> + * This function is not atomic and may be reordered.
> *
> * Note that @nr may be almost arbitrarily large; this function is not
> * restricted to acting on a single-word quantity.
> */
> static inline void set_bit(int nr, volatile unsigned long * addr)
> {
> - __asm__ __volatile__( LOCK
> + __asm__ __volatile__(
> "btsl %1,%0"
> :"=m" (ADDR)
> - :"Ir" (nr));
> + :"Ir" (nr): "memory");
> }
>
> /**
> @@ -271,10 +262,10 @@ static inline void set_bit(int nr, volatile unsigned
> long * addr)
> */
> static inline void clear_bit(int nr, volatile unsigned long * addr)
> {
> - __asm__ __volatile__( LOCK
> + __asm__ __volatile__(
> "btrl %1,%0"
> :"=m" (ADDR)
> - :"Ir" (nr));
> + :"Ir" (nr): "memory");
> }
>
> /**
> @@ -347,14 +338,13 @@ static inline unsigned long __xchg(unsigned long x,
> volatile void * ptr, int siz
> * @nr: Bit to clear
> * @addr: Address to count from
> *
> - * This operation is atomic and cannot be reordered.
> - * It also implies a memory barrier.
> + * This operation is not atomic and can be reordered.
> */
> static __inline__ int test_and_clear_bit(int nr, volatile void * addr)
> {
> int oldbit;
>
> - __asm__ __volatile__( LOCK_PREFIX
> + __asm__ __volatile__(
> "btrl %2,%1\n\tsbbl %0,%0"
> :"=r" (oldbit),"=m" (ADDR)
> :"dIr" (nr) : "memory");
> @@ -388,14 +378,14 @@ static __inline__ int variable_test_bit(int nr,
> volatile const void * addr)
> * @nr: the bit to set
> * @addr: the address to start counting from
> *
> - * This function is atomic and may not be reordered. See __set_bit()
> - * if you do not require the atomic guarantees.
> + * This function is not atomic and may be reordered.
> + *
> * Note that @nr may be almost arbitrarily large; this function is not
> * restricted to acting on a single-word quantity.
> */
> static __inline__ void set_bit(int nr, volatile void * addr)
> {
> - __asm__ __volatile__( LOCK_PREFIX
> + __asm__ __volatile__(
> "btsl %1,%0"
> :"=m" (ADDR)
> :"dIr" (nr) : "memory");
> @@ -406,17 +396,14 @@ static __inline__ void set_bit(int nr, volatile void *
> addr)
> * @nr: Bit to clear
> * @addr: Address to start counting from
> *
> - * clear_bit() is atomic and may not be reordered. However, it does
> - * not contain a memory barrier, so if it is used for locking purposes,
> - * you should call smp_mb__before_clear_bit() and/or
> smp_mb__after_clear_bit()
> - * in order to ensure changes are visible on other processors.
> + * clear_bit() is not atomic and may be reordered.
> */
> static __inline__ void clear_bit(int nr, volatile void * addr)
> {
> - __asm__ __volatile__( LOCK_PREFIX
> + __asm__ __volatile__(
> "btrl %1,%0"
> :"=m" (ADDR)
> - :"dIr" (nr));
> + :"dIr" (nr): "memory");
> }
>
> /**
> @@ -512,6 +499,8 @@ static inline unsigned long __synch_cmpxchg(volatile void
> *ptr,
> return old;
> }
>
> +/* These are atomic and may not be reordered. They also imply a full memory
> + * barrier. */
>
> static __inline__ void synch_set_bit(int nr, volatile void * addr)
> {
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxx
> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |