[lkml]   [2000]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: spin_lock forgets to clobber memory and other smp fixes [was Re: [patch] waitqueue optimization, 2.4.0-test7]
    On Mon, 4 Sep 2000, Andrea Arcangeli wrote:

    >barrier()). I also noticed __sti()/__save_flags() doesn't need to clobber

    I'm not sure anymore if __sti and spin_unlock() doesn't need to clobber
    memory (it looks necessary to make sure the compiler doesn't delay to
    write data to the memory out of the critical section).

    And in practice I can't reproduce any corruption with any subtle testcase
    by removing "memory" from the clobber list of all the
    spinlocks/__sti/__cli, so it may be the other way around. Maybe we can
    rely on the __volatile__ statement of the asm that will enforce that if we

    *p = 0;
    __asm__ __volatile__("" : :);
    *p = 1;

    in the assembler we'll then find both a write of 0 and then a write of 1
    to memory. I'd say with the current compiler we can rely on it (infact the
    spinlock doesn't seems to get miscompiled at the moment even while they
    aren't clobbering "memory".

    Same with:

    int a = *p;
    __asm__ __volatile__("" : :);
    a = *p;

    (to do two explicit reads)

    If "memory" isn't necessary in spin_lock, then all the "memory" clobbers
    around include/*/* (also in mb() and __cli() and even barrier()) are not
    necessary. But then "why" we need a "memory" clobber in first place if the
    "memory" isn't necessary? :)) Also the gcc documentation seems to say we
    need "memory" in all such operations (also in __sti() and
    spin_unlock() unlike I said in my earlier email).

    I'd like if some compiler guy could comment (I got no one reply yet). I
    tried to grep gcc but my gcc knowledge is too low to reverse engeneer the
    implement semantics of the "memory" clobber fast (though I would
    appreciate a pointer in the gcc sources to start to understand some gcc
    code :).


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

     \ /
      Last update: 2005-03-22 12:38    [W:0.021 / U:2.028 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site