lkml.org 
[lkml]   [2019]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH RFC tip/core/rcu 01/14] rcu/nocb: Atomic ->len field in rcu_segcblist structure
    On Sun, Aug 04, 2019 at 04:50:51PM +0200, Peter Zijlstra wrote:
    > On Fri, Aug 02, 2019 at 08:14:48AM -0700, Paul E. McKenney wrote:
    > > +/*
    > > + * Exchange the numeric length of the specified rcu_segcblist structure
    > > + * with the specified value. This can cause the ->len field to disagree
    > > + * with the actual number of callbacks on the structure. This exchange is
    > > + * fully ordered with respect to the callers accesses both before and after.
    > > + */
    > > +long rcu_segcblist_xchg_len(struct rcu_segcblist *rsclp, long v)
    > > +{
    > > +#ifdef CONFIG_RCU_NOCB_CPU
    > > + return atomic_long_xchg(&rsclp->len, v);
    > > +#else
    > > + long ret = rsclp->len;
    > > +
    > > + smp_mb(); /* Up to the caller! */
    > > + WRITE_ONCE(rsclp->len, v);
    > > + smp_mb(); /* Up to the caller! */
    > > + return ret;
    > > +#endif
    > > +}
    >
    > That one's weird; for matching semantics the load needs to be between
    > the memory barriers.

    Also, since you WRITE_ONCE() the thing, the load needs to be a
    READ_ONCE().

    \
     
     \ /
      Last update: 2019-08-04 16:54    [W:3.064 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site