[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 Thu, 7 Sep 2000, Jamie Lokier wrote:

    >Interestingly enough, the local variable case is one where "memory" does
    >make a difference. Without "memory":
    > movl p, %eax
    > movl (%eax), %eax
    >With "memory":
    > movl p, %eax
    > movl (%eax), %eax

    My gcc doesn't make differences between "memory" and non "memory" in this

    int * p;

    extern f(int);

    int a;

    a = *p;

    __asm__ __volatile__("zzz" : :);

    a = *p;


    My compiler _always_ produced first the zzz and then it loads p
    (regardless of "memory" clobber or not). That's why I said I couldn't
    reproduce miscompilations.

    >As you can see from above, there are cases where
    > local_var = shared->mumble;
    > // ...
    > spin_lock (&spinlock);
    > local_var = shared->mumble;
    >requires a "memory" clobber, otherwise the second read, which is in a
    >critical region, won't be emitted by the compiler.

    In your testcase have only `//' in the underlined line, so the compiler is
    100% allowed to throw away the first read to local_val, so far so good.

    So the compiler does only one read from the `p' pointer and on with my
    compiler it's always done _after_ the spin_lock (or after the __asm__
    __volatile__ in the above testcase).

    Of course "memory" should enforce the read to be done after the spin_lock
    but in real life it seems to do the right thing anyway and I couldn't
    reproduce miscompilation.

    Said that if your compiler puts the read before the spin_lock without the
    memory clobber, it is allowed to do that, and in such case you would proof
    it was a real world bug (not just a "documentation" one).

    Or maybe your testcase was a bit different then mine, in such case please
    send it to me (I'm curious indeed :).


    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.025 / U:4.704 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site