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:4.415 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site