| 
									
										
										
										
											2008-10-22 22:26:29 -07:00
										 |  |  | #ifndef _ASM_X86_CMPXCHG_32_H
 | 
					
						
							|  |  |  | #define _ASM_X86_CMPXCHG_32_H
 | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | #include <linux/bitops.h> /* for LOCK_PREFIX */
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-07-19 14:30:14 +03:00
										 |  |  | /*
 | 
					
						
							|  |  |  |  * Note: if you use set64_bit(), __cmpxchg64(), or their variants, you | 
					
						
							|  |  |  |  *       you need to test for the feature in boot_cpu_data. | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | #define xchg(ptr, v)							\
 | 
					
						
							|  |  |  | 	((__typeof__(*(ptr)))__xchg((unsigned long)(v), (ptr), sizeof(*(ptr)))) | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | struct __xchg_dummy { | 
					
						
							|  |  |  | 	unsigned long a[100]; | 
					
						
							|  |  |  | }; | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | #define __xg(x) ((struct __xchg_dummy *)(x))
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * The semantics of XCHGCMP8B are a bit strange, this is why | 
					
						
							|  |  |  |  * there is a loop and the loading of %%eax and %%edx has to | 
					
						
							|  |  |  |  * be inside. This inlines well in most cases, the cached | 
					
						
							|  |  |  |  * cost is around ~38 cycles. (in the future we might want | 
					
						
							|  |  |  |  * to do an SIMD/3DNOW!/MMX/FPU 64-bit store here, but that | 
					
						
							|  |  |  |  * might have an implicit FPU-save as a cost, so it's not | 
					
						
							|  |  |  |  * clear which path to go.) | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * cmpxchg8b must be used with the lock prefix here to allow | 
					
						
							|  |  |  |  * the instruction to be executed atomically, see page 3-102 | 
					
						
							|  |  |  |  * of the instruction set reference 24319102.pdf. We need | 
					
						
							|  |  |  |  * the reader side to see the coherent 64bit value. | 
					
						
							|  |  |  |  */ | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | static inline void __set_64bit(unsigned long long *ptr, | 
					
						
							|  |  |  | 			       unsigned int low, unsigned int high) | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 	asm volatile("\n1:\t" | 
					
						
							|  |  |  | 		     "movl (%0), %%eax\n\t" | 
					
						
							|  |  |  | 		     "movl 4(%0), %%edx\n\t" | 
					
						
							|  |  |  | 		     LOCK_PREFIX "cmpxchg8b (%0)\n\t" | 
					
						
							|  |  |  | 		     "jnz 1b" | 
					
						
							|  |  |  | 		     : /* no outputs */ | 
					
						
							|  |  |  | 		     : "D"(ptr), | 
					
						
							|  |  |  | 		       "b"(low), | 
					
						
							|  |  |  | 		       "c"(high) | 
					
						
							|  |  |  | 		     : "ax", "dx", "memory"); | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | static inline void __set_64bit_constant(unsigned long long *ptr, | 
					
						
							|  |  |  | 					unsigned long long value) | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 	__set_64bit(ptr, (unsigned int)value, (unsigned int)(value >> 32)); | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | #define ll_low(x)	*(((unsigned int *)&(x)) + 0)
 | 
					
						
							|  |  |  | #define ll_high(x)	*(((unsigned int *)&(x)) + 1)
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | static inline void __set_64bit_var(unsigned long long *ptr, | 
					
						
							|  |  |  | 				   unsigned long long value) | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | { | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 	__set_64bit(ptr, ll_low(value), ll_high(value)); | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | #define set_64bit(ptr, value)			\
 | 
					
						
							|  |  |  | 	(__builtin_constant_p((value))		\ | 
					
						
							|  |  |  | 	 ? __set_64bit_constant((ptr), (value))	\ | 
					
						
							|  |  |  | 	 : __set_64bit_var((ptr), (value))) | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | #define _set_64bit(ptr, value)						\
 | 
					
						
							|  |  |  | 	(__builtin_constant_p(value)					\ | 
					
						
							|  |  |  | 	 ? __set_64bit(ptr, (unsigned int)(value),			\ | 
					
						
							|  |  |  | 		       (unsigned int)((value) >> 32))			\ | 
					
						
							|  |  |  | 	 : __set_64bit(ptr, ll_low((value)), ll_high((value)))) | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 
 | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * Note: no "lock" prefix even on SMP: xchg always implies lock anyway | 
					
						
							|  |  |  |  * Note 2: xchg has side effect, so that attribute volatile is necessary, | 
					
						
							|  |  |  |  *	  but generally the primitive is invalid, *ptr is output argument. --ANK | 
					
						
							|  |  |  |  */ | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | static inline unsigned long __xchg(unsigned long x, volatile void *ptr, | 
					
						
							|  |  |  | 				   int size) | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | { | 
					
						
							|  |  |  | 	switch (size) { | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 	case 1: | 
					
						
							|  |  |  | 		asm volatile("xchgb %b0,%1" | 
					
						
							|  |  |  | 			     : "=q" (x) | 
					
						
							|  |  |  | 			     : "m" (*__xg(ptr)), "0" (x) | 
					
						
							|  |  |  | 			     : "memory"); | 
					
						
							|  |  |  | 		break; | 
					
						
							|  |  |  | 	case 2: | 
					
						
							|  |  |  | 		asm volatile("xchgw %w0,%1" | 
					
						
							|  |  |  | 			     : "=r" (x) | 
					
						
							|  |  |  | 			     : "m" (*__xg(ptr)), "0" (x) | 
					
						
							|  |  |  | 			     : "memory"); | 
					
						
							|  |  |  | 		break; | 
					
						
							|  |  |  | 	case 4: | 
					
						
							|  |  |  | 		asm volatile("xchgl %0,%1" | 
					
						
							|  |  |  | 			     : "=r" (x) | 
					
						
							|  |  |  | 			     : "m" (*__xg(ptr)), "0" (x) | 
					
						
							|  |  |  | 			     : "memory"); | 
					
						
							|  |  |  | 		break; | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 	} | 
					
						
							|  |  |  | 	return x; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * Atomic compare and exchange.  Compare OLD with MEM, if identical, | 
					
						
							|  |  |  |  * store NEW in MEM.  Return the initial value in MEM.  Success is | 
					
						
							|  |  |  |  * indicated by comparing RETURN with OLD. | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #ifdef CONFIG_X86_CMPXCHG
 | 
					
						
							|  |  |  | #define __HAVE_ARCH_CMPXCHG 1
 | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | #define cmpxchg(ptr, o, n)						\
 | 
					
						
							|  |  |  | 	((__typeof__(*(ptr)))__cmpxchg((ptr), (unsigned long)(o),	\ | 
					
						
							|  |  |  | 				       (unsigned long)(n),		\ | 
					
						
							|  |  |  | 				       sizeof(*(ptr)))) | 
					
						
							|  |  |  | #define sync_cmpxchg(ptr, o, n)						\
 | 
					
						
							|  |  |  | 	((__typeof__(*(ptr)))__sync_cmpxchg((ptr), (unsigned long)(o),	\ | 
					
						
							|  |  |  | 					    (unsigned long)(n),		\ | 
					
						
							|  |  |  | 					    sizeof(*(ptr)))) | 
					
						
							|  |  |  | #define cmpxchg_local(ptr, o, n)					\
 | 
					
						
							|  |  |  | 	((__typeof__(*(ptr)))__cmpxchg_local((ptr), (unsigned long)(o),	\ | 
					
						
							|  |  |  | 					     (unsigned long)(n),	\ | 
					
						
							|  |  |  | 					     sizeof(*(ptr)))) | 
					
						
							| 
									
										
											  
											
												x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
											
										 
											2008-01-30 13:30:47 +01:00
										 |  |  | #endif
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #ifdef CONFIG_X86_CMPXCHG64
 | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | #define cmpxchg64(ptr, o, n)						\
 | 
					
						
							|  |  |  | 	((__typeof__(*(ptr)))__cmpxchg64((ptr), (unsigned long long)(o), \ | 
					
						
							|  |  |  | 					 (unsigned long long)(n))) | 
					
						
							|  |  |  | #define cmpxchg64_local(ptr, o, n)					\
 | 
					
						
							|  |  |  | 	((__typeof__(*(ptr)))__cmpxchg64_local((ptr), (unsigned long long)(o), \ | 
					
						
							|  |  |  | 					       (unsigned long long)(n))) | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | #endif
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | static inline unsigned long __cmpxchg(volatile void *ptr, unsigned long old, | 
					
						
							|  |  |  | 				      unsigned long new, int size) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  | 	unsigned long prev; | 
					
						
							|  |  |  | 	switch (size) { | 
					
						
							|  |  |  | 	case 1: | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 		asm volatile(LOCK_PREFIX "cmpxchgb %b1,%2" | 
					
						
							|  |  |  | 			     : "=a"(prev) | 
					
						
							|  |  |  | 			     : "q"(new), "m"(*__xg(ptr)), "0"(old) | 
					
						
							|  |  |  | 			     : "memory"); | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 		return prev; | 
					
						
							|  |  |  | 	case 2: | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 		asm volatile(LOCK_PREFIX "cmpxchgw %w1,%2" | 
					
						
							|  |  |  | 			     : "=a"(prev) | 
					
						
							|  |  |  | 			     : "r"(new), "m"(*__xg(ptr)), "0"(old) | 
					
						
							|  |  |  | 			     : "memory"); | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 		return prev; | 
					
						
							|  |  |  | 	case 4: | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 		asm volatile(LOCK_PREFIX "cmpxchgl %1,%2" | 
					
						
							|  |  |  | 			     : "=a"(prev) | 
					
						
							|  |  |  | 			     : "r"(new), "m"(*__xg(ptr)), "0"(old) | 
					
						
							|  |  |  | 			     : "memory"); | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 		return prev; | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 	return old; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * Always use locked operations when touching memory shared with a | 
					
						
							|  |  |  |  * hypervisor, since the system may be SMP even if the guest kernel | 
					
						
							|  |  |  |  * isn't. | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | static inline unsigned long __sync_cmpxchg(volatile void *ptr, | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 					   unsigned long old, | 
					
						
							|  |  |  | 					   unsigned long new, int size) | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | { | 
					
						
							|  |  |  | 	unsigned long prev; | 
					
						
							|  |  |  | 	switch (size) { | 
					
						
							|  |  |  | 	case 1: | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 		asm volatile("lock; cmpxchgb %b1,%2" | 
					
						
							|  |  |  | 			     : "=a"(prev) | 
					
						
							|  |  |  | 			     : "q"(new), "m"(*__xg(ptr)), "0"(old) | 
					
						
							|  |  |  | 			     : "memory"); | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 		return prev; | 
					
						
							|  |  |  | 	case 2: | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 		asm volatile("lock; cmpxchgw %w1,%2" | 
					
						
							|  |  |  | 			     : "=a"(prev) | 
					
						
							|  |  |  | 			     : "r"(new), "m"(*__xg(ptr)), "0"(old) | 
					
						
							|  |  |  | 			     : "memory"); | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 		return prev; | 
					
						
							|  |  |  | 	case 4: | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 		asm volatile("lock; cmpxchgl %1,%2" | 
					
						
							|  |  |  | 			     : "=a"(prev) | 
					
						
							|  |  |  | 			     : "r"(new), "m"(*__xg(ptr)), "0"(old) | 
					
						
							|  |  |  | 			     : "memory"); | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 		return prev; | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 	return old; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | static inline unsigned long __cmpxchg_local(volatile void *ptr, | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 					    unsigned long old, | 
					
						
							|  |  |  | 					    unsigned long new, int size) | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | { | 
					
						
							|  |  |  | 	unsigned long prev; | 
					
						
							|  |  |  | 	switch (size) { | 
					
						
							|  |  |  | 	case 1: | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 		asm volatile("cmpxchgb %b1,%2" | 
					
						
							|  |  |  | 			     : "=a"(prev) | 
					
						
							|  |  |  | 			     : "q"(new), "m"(*__xg(ptr)), "0"(old) | 
					
						
							|  |  |  | 			     : "memory"); | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 		return prev; | 
					
						
							|  |  |  | 	case 2: | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 		asm volatile("cmpxchgw %w1,%2" | 
					
						
							|  |  |  | 			     : "=a"(prev) | 
					
						
							|  |  |  | 			     : "r"(new), "m"(*__xg(ptr)), "0"(old) | 
					
						
							|  |  |  | 			     : "memory"); | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 		return prev; | 
					
						
							|  |  |  | 	case 4: | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 		asm volatile("cmpxchgl %1,%2" | 
					
						
							|  |  |  | 			     : "=a"(prev) | 
					
						
							|  |  |  | 			     : "r"(new), "m"(*__xg(ptr)), "0"(old) | 
					
						
							|  |  |  | 			     : "memory"); | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 		return prev; | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 	return old; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
											
										 
											2008-01-30 13:30:47 +01:00
										 |  |  | static inline unsigned long long __cmpxchg64(volatile void *ptr, | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 					     unsigned long long old, | 
					
						
							|  |  |  | 					     unsigned long long new) | 
					
						
							| 
									
										
											  
											
												x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
											
										 
											2008-01-30 13:30:47 +01:00
										 |  |  | { | 
					
						
							|  |  |  | 	unsigned long long prev; | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 	asm volatile(LOCK_PREFIX "cmpxchg8b %3" | 
					
						
							|  |  |  | 		     : "=A"(prev) | 
					
						
							|  |  |  | 		     : "b"((unsigned long)new), | 
					
						
							|  |  |  | 		       "c"((unsigned long)(new >> 32)), | 
					
						
							|  |  |  | 		       "m"(*__xg(ptr)), | 
					
						
							|  |  |  | 		       "0"(old) | 
					
						
							|  |  |  | 		     : "memory"); | 
					
						
							| 
									
										
											  
											
												x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
											
										 
											2008-01-30 13:30:47 +01:00
										 |  |  | 	return prev; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | static inline unsigned long long __cmpxchg64_local(volatile void *ptr, | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 						   unsigned long long old, | 
					
						
							|  |  |  | 						   unsigned long long new) | 
					
						
							| 
									
										
											  
											
												x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
											
										 
											2008-01-30 13:30:47 +01:00
										 |  |  | { | 
					
						
							|  |  |  | 	unsigned long long prev; | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 	asm volatile("cmpxchg8b %3" | 
					
						
							|  |  |  | 		     : "=A"(prev) | 
					
						
							|  |  |  | 		     : "b"((unsigned long)new), | 
					
						
							|  |  |  | 		       "c"((unsigned long)(new >> 32)), | 
					
						
							|  |  |  | 		       "m"(*__xg(ptr)), | 
					
						
							|  |  |  | 		       "0"(old) | 
					
						
							|  |  |  | 		     : "memory"); | 
					
						
							| 
									
										
											  
											
												x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
											
										 
											2008-01-30 13:30:47 +01:00
										 |  |  | 	return prev; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | #ifndef CONFIG_X86_CMPXCHG
 | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * Building a kernel capable running on 80386. It may be necessary to | 
					
						
							|  |  |  |  * simulate the cmpxchg on the 80386 CPU. For that purpose we define | 
					
						
							|  |  |  |  * a function for each of the sizes we support. | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | extern unsigned long cmpxchg_386_u8(volatile void *, u8, u8); | 
					
						
							|  |  |  | extern unsigned long cmpxchg_386_u16(volatile void *, u16, u16); | 
					
						
							|  |  |  | extern unsigned long cmpxchg_386_u32(volatile void *, u32, u32); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | static inline unsigned long cmpxchg_386(volatile void *ptr, unsigned long old, | 
					
						
							| 
									
										
										
										
											2008-03-23 01:01:51 -07:00
										 |  |  | 					unsigned long new, int size) | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | { | 
					
						
							|  |  |  | 	switch (size) { | 
					
						
							|  |  |  | 	case 1: | 
					
						
							|  |  |  | 		return cmpxchg_386_u8(ptr, old, new); | 
					
						
							|  |  |  | 	case 2: | 
					
						
							|  |  |  | 		return cmpxchg_386_u16(ptr, old, new); | 
					
						
							|  |  |  | 	case 4: | 
					
						
							|  |  |  | 		return cmpxchg_386_u32(ptr, old, new); | 
					
						
							|  |  |  | 	} | 
					
						
							|  |  |  | 	return old; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
											
										 
											2008-01-30 13:30:47 +01:00
										 |  |  | #define cmpxchg(ptr, o, n)						\
 | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | ({									\ | 
					
						
							|  |  |  | 	__typeof__(*(ptr)) __ret;					\ | 
					
						
							|  |  |  | 	if (likely(boot_cpu_data.x86 > 3))				\ | 
					
						
							| 
									
										
										
										
											2008-03-06 13:45:46 +01:00
										 |  |  | 		__ret = (__typeof__(*(ptr)))__cmpxchg((ptr),		\ | 
					
						
							|  |  |  | 				(unsigned long)(o), (unsigned long)(n),	\ | 
					
						
							|  |  |  | 				sizeof(*(ptr)));			\ | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 	else								\ | 
					
						
							| 
									
										
										
										
											2008-03-06 13:45:46 +01:00
										 |  |  | 		__ret = (__typeof__(*(ptr)))cmpxchg_386((ptr),		\ | 
					
						
							|  |  |  | 				(unsigned long)(o), (unsigned long)(n),	\ | 
					
						
							|  |  |  | 				sizeof(*(ptr)));			\ | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 	__ret;								\ | 
					
						
							|  |  |  | }) | 
					
						
							| 
									
										
											  
											
												x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
											
										 
											2008-01-30 13:30:47 +01:00
										 |  |  | #define cmpxchg_local(ptr, o, n)					\
 | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | ({									\ | 
					
						
							|  |  |  | 	__typeof__(*(ptr)) __ret;					\ | 
					
						
							|  |  |  | 	if (likely(boot_cpu_data.x86 > 3))				\ | 
					
						
							| 
									
										
										
										
											2008-03-06 13:45:46 +01:00
										 |  |  | 		__ret = (__typeof__(*(ptr)))__cmpxchg_local((ptr),	\ | 
					
						
							|  |  |  | 				(unsigned long)(o), (unsigned long)(n),	\ | 
					
						
							|  |  |  | 				sizeof(*(ptr)));			\ | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 	else								\ | 
					
						
							| 
									
										
										
										
											2008-03-06 13:45:46 +01:00
										 |  |  | 		__ret = (__typeof__(*(ptr)))cmpxchg_386((ptr),		\ | 
					
						
							|  |  |  | 				(unsigned long)(o), (unsigned long)(n),	\ | 
					
						
							|  |  |  | 				sizeof(*(ptr)));			\ | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 	__ret;								\ | 
					
						
							|  |  |  | }) | 
					
						
							|  |  |  | #endif
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
											
										 
											2008-01-30 13:30:47 +01:00
										 |  |  | #ifndef CONFIG_X86_CMPXCHG64
 | 
					
						
							|  |  |  | /*
 | 
					
						
							|  |  |  |  * Building a kernel capable running on 80386 and 80486. It may be necessary | 
					
						
							|  |  |  |  * to simulate the cmpxchg8b on the 80386 and 80486 CPU. | 
					
						
							|  |  |  |  */ | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
											
										 
											2008-01-30 13:30:47 +01:00
										 |  |  | extern unsigned long long cmpxchg_486_u64(volatile void *, u64, u64); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2009-09-30 17:07:54 +02:00
										 |  |  | #define cmpxchg64(ptr, o, n)					\
 | 
					
						
							|  |  |  | ({								\ | 
					
						
							|  |  |  | 	__typeof__(*(ptr)) __ret;				\ | 
					
						
							|  |  |  | 	__typeof__(*(ptr)) __old = (o);				\ | 
					
						
							|  |  |  | 	__typeof__(*(ptr)) __new = (n);				\ | 
					
						
							|  |  |  | 	alternative_io("call cmpxchg8b_emu",			\ | 
					
						
							|  |  |  | 			"lock; cmpxchg8b (%%esi)" ,		\ | 
					
						
							|  |  |  | 		       X86_FEATURE_CX8,				\ | 
					
						
							|  |  |  | 		       "=A" (__ret),				\ | 
					
						
							|  |  |  | 		       "S" ((ptr)), "0" (__old),		\ | 
					
						
							|  |  |  | 		       "b" ((unsigned int)__new),		\ | 
					
						
							|  |  |  | 		       "c" ((unsigned int)(__new>>32))		\ | 
					
						
							|  |  |  | 		       : "memory");				\ | 
					
						
							|  |  |  | 	__ret; }) | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
											
										 
											2008-01-30 13:30:47 +01:00
										 |  |  | #define cmpxchg64_local(ptr, o, n)					\
 | 
					
						
							|  |  |  | ({									\ | 
					
						
							|  |  |  | 	__typeof__(*(ptr)) __ret;					\ | 
					
						
							|  |  |  | 	if (likely(boot_cpu_data.x86 > 4))				\ | 
					
						
							| 
									
										
										
										
											2008-03-06 13:45:46 +01:00
										 |  |  | 		__ret = (__typeof__(*(ptr)))__cmpxchg64_local((ptr),	\ | 
					
						
							|  |  |  | 				(unsigned long long)(o),		\ | 
					
						
							| 
									
										
											  
											
												x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
											
										 
											2008-01-30 13:30:47 +01:00
										 |  |  | 				(unsigned long long)(n));		\ | 
					
						
							|  |  |  | 	else								\ | 
					
						
							| 
									
										
										
										
											2008-03-06 13:45:46 +01:00
										 |  |  | 		__ret = (__typeof__(*(ptr)))cmpxchg_486_u64((ptr),	\ | 
					
						
							|  |  |  | 				(unsigned long long)(o),		\ | 
					
						
							| 
									
										
											  
											
												x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486
Actually, on 386, cmpxchg and cmpxchg_local fall back on
cmpxchg_386_u8/16/32: it disables interruptions around non atomic
updates to mimic the cmpxchg behavior.
The comment:
/* Poor man's cmpxchg for 386. Unsuitable for SMP */
already present in cmpxchg_386_u32 tells much about how this cmpxchg
implementation should not be used in a SMP context. However, the cmpxchg_local
can perfectly use this fallback, since it only needs to be atomic wrt the local
cpu.
This patch adds a cmpxchg_486_u64 and uses it as a fallback for cmpxchg64
and cmpxchg64_local on 80386 and 80486.
Q:
but why is it called cmpxchg_486 when the other functions are called
A:
Because the standard cmpxchg is missing only on 386, but cmpxchg8b is
missing both on 386 and 486.
Citing Intel's Instruction set reference:
cmpxchg:
This instruction is not supported on Intel processors earlier than the
Intel486 processors.
cmpxchg8b:
This instruction encoding is not supported on Intel processors earlier
than the Pentium processors.
Q:
What's the reason to have cmpxchg64_local on 32 bit architectures?
Without that need all this would just be a few simple defines.
A:
cmpxchg64_local on 32 bits architectures takes unsigned long long
parameters, but cmpxchg_local only takes longs. Since we have cmpxchg8b
to execute a 8 byte cmpxchg atomically on pentium and +, it makes sense
to provide a flavor of cmpxchg and cmpxchg_local using this instruction.
Also, for 32 bits architectures lacking the 64 bits atomic cmpxchg, it
makes sense _not_ to define cmpxchg64 while cmpxchg could still be
available.
Moreover, the fallback for cmpxchg8b on i386 for 386 and 486 is a
However, cmpxchg64_local will be emulated by disabling interrupts on all
architectures where it is not supported atomically.
Therefore, we *could* turn cmpxchg64_local into a cmpxchg_local, but it
would make the 386/486 fallbacks ugly, make its design different from
cmpxchg/cmpxchg64 (which really depends on atomic operations and cannot
be emulated) and require the __cmpxchg_local to be expressed as a macro
rather than an inline function so the parameters would not be fixed to
unsigned long long in every case.
So I think cmpxchg64_local makes sense there, but I am open to
suggestions.
Q:
Are there any callers?
A:
I am actually using it in LTTng in my timestamping code. I use it to
work around CPUs with asynchronous TSCs. I need to update 64 bits
values atomically on this 32 bits architecture.
Changelog:
- Ran though checkpatch.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
											
										 
											2008-01-30 13:30:47 +01:00
										 |  |  | 				(unsigned long long)(n));		\ | 
					
						
							|  |  |  | 	__ret;								\ | 
					
						
							|  |  |  | }) | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #endif
 | 
					
						
							| 
									
										
										
										
											2007-05-08 00:35:02 -07:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2008-10-22 22:26:29 -07:00
										 |  |  | #endif /* _ASM_X86_CMPXCHG_32_H */
 |