lkml.org 
[lkml]   [2019]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Documentation: atomic_t.txt: Explain ordering provided by smp_mb__{before,after}_atomic()
On Tue, Apr 23, 2019 at 06:30:10AM -0700, Paul E. McKenney wrote:
> On Tue, Apr 23, 2019 at 02:32:09PM +0200, Peter Zijlstra wrote:
> > On Sat, Apr 20, 2019 at 01:54:40AM -0700, Paul E. McKenney wrote:
> > > And atomic_set(): set_preempt_state(). This fails
> > > on x86, s390, and TSO friends, does it not? Or is
> > > this ARM-only? Still, why not just smp_mb() before and
> > > after? Same issue in __kernfs_new_node(), bio_cnt_set(),
> > > sbitmap_queue_update_wake_batch(),
> > >
> > > Ditto for atomic64_set() in __ceph_dir_set_complete().
> > >
> > > Ditto for atomic_read() in rvt_qp_is_avail(). This function
> > > has a couple of other oddly placed smp_mb__before_atomic().
> >
> > That are just straight up bugs. The atomic_t.txt file clearly specifies
> > the barriers only apply to RmW ops and both _set() and _read() are
> > specified to not be a RmW.
>
> Agreed. The "Ditto" covers my atomic_set() consternation. ;-)

I was working on some of these before the Easter break [1, 2]: the plan
was to continue next week, but by addressing the remaining cases with a
conservative s/that barrier/smp_mb at first; unless you've other plans?

Andrea

[1] http://lkml.kernel.org/r/1555417031-27356-1-git-send-email-andrea.parri@amarulasolutions.com
[2] http://lkml.kernel.org/r/1555404968-39927-1-git-send-email-pbonzini@redhat.com

\
 
 \ /
  Last update: 2019-04-27 10:18    [W:0.091 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site