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 Sat, Apr 27, 2019 at 10:17:38AM +0200, Andrea Parri wrote:
> 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

Sounds good to me! ;-)

Thanx, Paul

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