[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190718144950.yc6sambgdsz7vrvq@gondor.apana.org.au>
Date: Thu, 18 Jul 2019 22:49:50 +0800
From: Herbert Xu <herbert@...dor.apana.org.au>
To: Daniel Jordan <daniel.m.jordan@...cle.com>
Cc: Steffen Klassert <steffen.klassert@...unet.com>,
Andrea Parri <andrea.parri@...rulasolutions.com>,
Boqun Feng <boqun.feng@...il.com>,
"Paul E . McKenney" <paulmck@...ux.ibm.com>,
Peter Zijlstra <peterz@...radead.org>,
linux-arch@...r.kernel.org, linux-crypto@...r.kernel.org,
linux-kernel@...r.kernel.org,
Mathias Krause <minipli@...glemail.com>
Subject: Re: [PATCH] padata: Replace delayed timer with immediate workqueue
in padata_reorder
On Thu, Jul 18, 2019 at 10:25:15AM -0400, Daniel Jordan wrote:
>
> Which memory barrier do you mean? I think you're referring to the one that
> atomic_inc might provide? If so, the memory model maintainers can correct me
> here, but my understanding is that RMW atomic ops that don't return values are
> unordered, so switching the lines has no effect.
>
> Besides, the smp_mb__after_atomic is what orders the list insertion with the
> trylock of pd->lock.
The primitive smp_mb__after_atomic only provides a barrier when
used in conjunction with atomic_inc (and similar atomic ops).
The actual barrier may either be in smp_mb__after_atomic or the
atomic op itself (which is the case on x86). Since we need the
barrier to occur after the list insertion we must move both of
these after the list_add_tail.
Cheers,
--
Email: Herbert Xu <herbert@...dor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Powered by blists - more mailing lists