[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170928154354.GK3521@linux.vnet.ibm.com>
Date: Thu, 28 Sep 2017 08:43:54 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Will Deacon <will.deacon@....com>
Cc: Peter Zijlstra <peterz@...radead.org>,
kirill.shutemov@...ux.intel.com, linux-kernel@...r.kernel.org,
ynorov@...iumnetworks.com, rruigrok@...eaurora.org,
linux-arch@...r.kernel.org, akpm@...ux-foundation.org,
catalin.marinas@....com, rth@...ddle.net, ink@...assic.park.msu.ru,
mattst88@...il.com, linux-alpha@...r.kernel.org
Subject: Re: [RFC PATCH 1/2] arm64: mm: Use READ_ONCE/WRITE_ONCE when
accessing page tables
On Thu, Sep 28, 2017 at 09:45:35AM +0100, Will Deacon wrote:
> On Thu, Sep 28, 2017 at 10:38:01AM +0200, Peter Zijlstra wrote:
> > On Wed, Sep 27, 2017 at 04:49:28PM +0100, Will Deacon wrote:
> > > In many cases, page tables can be accessed concurrently by either another
> > > CPU (due to things like fast gup) or by the hardware page table walker
> > > itself, which may set access/dirty bits. In such cases, it is important
> > > to use READ_ONCE/WRITE_ONCE when accessing page table entries so that
> > > entries cannot be torn, merged or subject to apparent loss of coherence.
> >
> > In fact, we should use lockless_dereference() for many of them. Yes
> > Alpha is the only one that cares about the difference between that and
> > READ_ONCE() and they do have the extra barrier, but if we're going to do
> > this, we might as well do it 'right' :-)
>
> I know this sounds daft, but I think one of the big reasons why
> lockless_dereference() doesn't get an awful lot of use is because it's
> such a mouthful! Why don't we just move the smp_read_barrier_depends()
> into READ_ONCE? Would anybody actually care about the potential impact on
> Alpha (which, frankly, is treading on thin ice given the low adoption of
> lockless_dereference())?
This is my cue to ask my usual question... ;-)
Are people still running mainline kernels on Alpha? (Added Alpha folks.)
As always, if anyone is, we must continue to support Alpha, but sounds
like time to check again.
Thanx, Paul
Powered by blists - more mailing lists