[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190429092430.GF26546@localhost>
Date: Mon, 29 Apr 2019 11:24:30 +0200
From: Johan Hovold <johan@...nel.org>
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>,
Andrea Parri <andrea.parri@...rulasolutions.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 lock acquisition??? acm_read_bulk_callback().
> >
> > I think it goes with the set_bit() earlier, but what do I know.
>
> Quite possibly! In that case it should be smp_mb__after_atomic(),
> and it would be nice if it immediately followed the set_bit().
I noticed this one last week as well. The set_bit() had been incorrectly
moved and without noticing the smp_mb__before_atomic(). I've submitted a
patch to restore it and to fix a related issue to due missing barriers:
https://lkml.kernel.org/r/20190425160540.10036-5-johan@kernel.org
Johan
Powered by blists - more mailing lists