Re: Memory corruption due to word sharing

From: Andrew MacLeod
Date: Fri Feb 03 2012 - 11:39:22 EST

And I assume that since the compiler does them, that would now make it
impossible for us to gather a list of all the 'lock' prefixes so that
we can undo them if it turns out that we are running on a UP machine.

When we do SMP operations, we don't just add a "lock" prefix to it. We do this:

".section .smp_locks,\"a\"\n" \
".balign 4\n" \
".long 671f - .\n" /* offset */ \
".previous\n" \

#define LOCK_PREFIX LOCK_PREFIX_HERE "\n\tlock; "

I don't see why we cant do something similar when the compiler issues a lock on an atomic operation. I would guess we'd want to put it under some sort of flag control (something like -fatomic-lock-list ) since most applications aren't going to want that section. It certainly seems plausible to me anyway.
and I'm sure you know that, but I'm not sure the gcc people realize
the kinds of games we play to make things work better.

No, but someone just needs to tell us -)

We need both variants in the kernel. If the compiler generates one of
them for us, that doesn't really much help.
I must admit that the non-x86 per-CPU atomics are, ummm, "interesting".
Most non-x86 cpu's would probably be better off treating them the same
as smp-atomics (load-locked + store-conditional), but right now we
have this insane generic infrastructure for having versions that are
irq-safe by disabling interrupts etc. Ugh. Mainly because nobody
really is willing to work on and fix up the 25 architectures that
really don't matter.

The atomic intrinsics were created for c++11 memory model compliance, but I am certainly open to enhancements that would make them more useful. I am planning some enhancements for 4.8 now, and it sounds like you may have some suggestions...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at