lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sat, 27 Apr 2019 10:17:38 +0200
From:   Andrea Parri <andrea.parri@...rulasolutions.com>
To:     "Paul E. McKenney" <paulmck@...ux.ibm.com>
Cc:     Peter Zijlstra <peterz@...radead.org>,
        Nicholas Piggin <npiggin@...il.com>,
        LKMM Maintainers -- Akira Yokosawa <akiyks@...il.com>,
        Boqun Feng <boqun.feng@...il.com>,
        David Howells <dhowells@...hat.com>,
        Daniel Lustig <dlustig@...dia.com>,
        Jade Alglave <j.alglave@....ac.uk>,
        Kernel development list <linux-kernel@...r.kernel.org>,
        Luc Maranget <luc.maranget@...ia.fr>,
        Alan Stern <stern@...land.harvard.edu>,
        Will Deacon <will.deacon@....com>
Subject: Re: [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

Powered by blists - more mailing lists