[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170607122538.jy3nps6erhlfi4bh@hirez.programming.kicks-ass.net>
Date: Wed, 7 Jun 2017 14:25:38 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Palmer Dabbelt <palmer@...belt.com>
Cc: linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
Arnd Bergmann <arnd@...db.de>, olof@...om.net,
albert@...ive.com, patches@...ups.riscv.org
Subject: Re: [PATCH 13/17] RISC-V: Add include subdirectory
On Wed, Jun 07, 2017 at 01:54:23PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 06, 2017 at 04:00:03PM -0700, Palmer Dabbelt wrote:
> > +/* Assume that atomic operations are already serializing */
> > +#define smp_mb__before_atomic_dec() barrier()
> > +#define smp_mb__after_atomic_dec() barrier()
> > +#define smp_mb__before_atomic_inc() barrier()
> > +#define smp_mb__after_atomic_inc() barrier()
>
> > +#define smp_mb__before_clear_bit() smp_mb()
> > +#define smp_mb__after_clear_bit() smp_mb()
>
> These no longer exist.. Also how can they be different? bitops would use
> the same atomic primitives as regular atomic ops would and would thus
> have the very same implicit ordering.
Your manual states that each atomic instruction (be it AMO or LR/SC)
have two ordering bits: AQ and RL. If neither are set the instruction is
unordered, if either one is set, its either an ACQUIRE or a RELEASE and
if both are set its SC.
So you can in fact make the above happen, however your atomic
implementation does not appear to use ".aq.rl" mnemonics so would be
entirely unordered, just like your bitops.
Therefore the above is just plain wrong and broken.
Powered by blists - more mailing lists