lkml.org 
[lkml]   [2012]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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


\
 
 \ /
  Last update: 2012-02-03 17:41    [W:0.095 / U:0.952 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site