Messages in this thread | | | Date | Sat, 27 Apr 2019 01:36:29 -0700 | From | "Paul E. McKenney" <> | Subject | Re: [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
| |