Messages in this thread | | | Date | Fri, 03 Feb 2012 11:38:34 -0500 | From | Andrew MacLeod <> | Subject | Re: Memory corruption due to word sharing |
| |
>> 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: >> >> #define LOCK_PREFIX_HERE \ >> ".section .smp_locks,\"a\"\n" \ >> ".balign 4\n" \ >> ".long 671f - .\n" /* offset */ \ >> ".previous\n" \ >> "671:" >> >> #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...
Andrew
| |