lkml.org 
[lkml]   [2021]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 1/6] MIPS: Octeon: Implement __smp_store_release()
    On Thu, Jan 28, 2021 at 01:09:39PM +0100, Alexander Sverdlin wrote:
    > On 28/01/2021 12:33, Peter Zijlstra wrote:
    > > On Thu, Jan 28, 2021 at 08:27:29AM +0100, Alexander Sverdlin wrote:
    > >
    > >>>> +#define __smp_store_release(p, v) \
    > >>>> +do { \
    > >>>> + compiletime_assert_atomic_type(*p); \
    > >>>> + __smp_wmb(); \
    > >>>> + __smp_rmb(); \
    > >>>> + WRITE_ONCE(*p, v); \
    > >>>> +} while (0)

    > I actually hoped you will remember the discussion you've participated 5 years
    > ago and (in my understanding) actually already agreed that the solution itself
    > is not broken:
    >
    > https://lore.kernel.org/lkml/20151112180003.GE17308@twins.programming.kicks-ass.net/

    My memory really isn't that good. I can barely remember what I did 5
    weeks ago, 5 years ago might as well have never happened.

    > Could you please just suggest the proper comment you expect to be added here,
    > because there is no doubts, you have much more experience here than me?

    So for store_release I'm not too worried, and provided no read
    speculation, wmb is indeed sufficient. This is because our store_release
    is RCpc.

    Something like:

    /*
    * Because Octeon does not do read speculation, an smp_wmb()
    * is sufficient to ensure {load,store}->{store} order.
    */
    #define __smp_store_release(p, v) \
    do { \
    compiletime_assert_atomic_type(*p); \
    __smp_wmb(); \
    WRITE_ONCE(*p, v); \
    } while (0)

    \
     
     \ /
      Last update: 2021-01-28 16:06    [W:5.670 / U:0.132 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site