On Fri, Jun 10, 2016 at 01:25:03AM +0800, Boqun Feng wrote:
> On Thu, Jun 09, 2016 at 10:23:28PM +1000, Michael Ellerman wrote:
> > On Wed, 2016-06-08 at 15:59 +0200, Peter Zijlstra wrote:
> > > On Wed, Jun 08, 2016 at 11:49:20PM +1000, Michael Ellerman wrote:
> > >
> > > > > Ok; what tree does thi
On Thu, 2016-06-09 at 19:50 +0200, Peter Zijlstra wrote:
> On Thu, Jun 09, 2016 at 10:23:28PM +1000, Michael Ellerman wrote:
> > Unfortunately the patch isn't 100%.
>
> So what I'll do; since my patch is trying to ensure all implementations
> of spin_unlock_wait() provide ACQUIRE semantics, and th
On Thu, Jun 09, 2016 at 10:23:28PM +1000, Michael Ellerman wrote:
> Unfortunately the patch isn't 100%.
So what I'll do; since my patch is trying to ensure all implementations
of spin_unlock_wait() provide ACQUIRE semantics, and this patch does
indeed do so, is skip touching PPC entirely and hope
On Thu, Jun 09, 2016 at 10:23:28PM +1000, Michael Ellerman wrote:
> On Wed, 2016-06-08 at 15:59 +0200, Peter Zijlstra wrote:
> > On Wed, Jun 08, 2016 at 11:49:20PM +1000, Michael Ellerman wrote:
> >
> > > > Ok; what tree does this go in? I have this dependent series which I'd
> > > > like to get so
On Wed, 2016-06-08 at 15:59 +0200, Peter Zijlstra wrote:
> On Wed, Jun 08, 2016 at 11:49:20PM +1000, Michael Ellerman wrote:
>
> > > Ok; what tree does this go in? I have this dependent series which I'd
> > > like to get sorted and merged somewhere.
> >
> > Ah sorry, I didn't realise. I was going
On Wed, Jun 08, 2016 at 11:49:20PM +1000, Michael Ellerman wrote:
> > Ok; what tree does this go in? I have this dependent series which I'd
> > like to get sorted and merged somewhere.
>
> Ah sorry, I didn't realise. I was going to put it in my next (which doesn't
> exist yet but hopefully will e
On Wed, 2016-06-08 at 14:35 +0200, Peter Zijlstra wrote:
> On Wed, Jun 08, 2016 at 09:20:45PM +1000, Michael Ellerman wrote:
> > On Mon, 2016-06-06 at 16:46 +0200, Peter Zijlstra wrote:
> > > On Mon, Jun 06, 2016 at 10:17:25PM +1000, Michael Ellerman wrote:
> > > > On Mon, 2016-06-06 at 13:56 +0200
On Wed, Jun 08, 2016 at 09:20:45PM +1000, Michael Ellerman wrote:
> On Mon, 2016-06-06 at 16:46 +0200, Peter Zijlstra wrote:
> > On Mon, Jun 06, 2016 at 10:17:25PM +1000, Michael Ellerman wrote:
> > > On Mon, 2016-06-06 at 13:56 +0200, Peter Zijlstra wrote:
> > > > On Mon, Jun 06, 2016 at 09:42:20P
On Mon, 2016-06-06 at 16:46 +0200, Peter Zijlstra wrote:
> On Mon, Jun 06, 2016 at 10:17:25PM +1000, Michael Ellerman wrote:
> > On Mon, 2016-06-06 at 13:56 +0200, Peter Zijlstra wrote:
> > > On Mon, Jun 06, 2016 at 09:42:20PM +1000, Michael Ellerman wrote:
> > >
> > > Why the move to in-line this
On Mon, Jun 06, 2016 at 10:17:25PM +1000, Michael Ellerman wrote:
> On Mon, 2016-06-06 at 13:56 +0200, Peter Zijlstra wrote:
> > On Mon, Jun 06, 2016 at 09:42:20PM +1000, Michael Ellerman wrote:
> > > +static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
> > > +{
> > > + arch_spinlock_t
On Mon, 2016-06-06 at 13:56 +0200, Peter Zijlstra wrote:
> On Mon, Jun 06, 2016 at 09:42:20PM +1000, Michael Ellerman wrote:
> > +static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
> > +{
> > + arch_spinlock_t lock_val;
> > +
> > + smp_mb();
> > +
> > + /*
> > +* Atomically l
On Mon, Jun 06, 2016 at 09:42:20PM +1000, Michael Ellerman wrote:
> +static inline void arch_spin_unlock_wait(arch_spinlock_t *lock)
> +{
> + arch_spinlock_t lock_val;
> +
> + smp_mb();
> +
> + /*
> + * Atomically load and store back the lock value (unchanged). This
> + * ensu
From: Boqun Feng
There is an ordering issue with spin_unlock_wait() on powerpc, because
the spin_lock primitive is an ACQUIRE and an ACQUIRE is only ordering
the load part of the operation with memory operations following it.
Therefore the following event sequence can happen:
CPU 1
13 matches
Mail list logo
