kernel/git/stable/linux.git/include/asm-x86/cmpxchg_32.h, branch master

x86, um: ... and asm-x86 move

2008-10-23T05:55:20+00:00

Signed-off-by: Al Viro Signed-off-by: H. Peter Anvin

x86: consolidate header guards

2008-07-22T19:31:34+00:00

This patch is the result of an automatic script that consolidates the format of all the headers in include/asm-x86/. The format: 1. No leading underscore. Names with leading underscores are reserved. 2. Pathname components are separated by two underscores. So we can distinguish between mm_types.h and mm/types.h. 3. Everything except letters and numbers are turned into single underscores. Signed-off-by: Vegard Nossum

include/asm-x86/cmpxchg_32.h: checkpatch cleanups - formatting only

2008-04-17T15:41:22+00:00

Signed-off-by: Joe Perches Signed-off-by: Ingo Molnar

x86: cast cmpxchg and cmpxchg_local result for 386 and 486

2008-03-21T16:06:15+00:00

mm/slub.c: In function 'slab_alloc': mm/slub.c:1637: warning: assignment makes pointer from integer without a cast mm/slub.c:1637: warning: assignment makes pointer from integer without a cast mm/slub.c: In function 'slab_free': mm/slub.c:1796: warning: assignment makes pointer from integer without a cast mm/slub.c:1796: warning: assignment makes pointer from integer without a cast A cast is needed in the 386 and 486 code because the type is a pointer. In every other integer case the original cmpxchg code (and the cmpxchg_local which has been copied from it) worked fine, but since we touch a pointer, the type needs to be casted in the cmpxchg_local and cmpxchg macros. The more recent code (586+) does not have this problem (the cast is already there). Signed-off-by: Mathieu Desnoyers Signed-off-by: Thomas Gleixner Reviewed-by: Christoph Lameter Cc: Vegard Nossum Cc: Pekka Enberg Signed-off-by: Andrew Morton Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner

x86: fall back on interrupt disable in cmpxchg8b on 80386 and 80486

2008-01-30T12:30:47+00:00

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 Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner

i386/x86_64: move headers to include/asm-x86

2007-10-11T09:20:03+00:00

Move the headers to include/asm-x86 and fixup the header install make rules Signed-off-by: Thomas Gleixner Signed-off-by: Ingo Molnar