Re: [PATCH] ipc/sem.c: Update/correct memory barriers

2015-08-12 Thread Oleg Nesterov
On 08/09, Manfred Spraul wrote: > > /* > + * spin_unlock_wait() and !spin_is_locked() are not memory barriers, they > + * are only control barriers. > + * The code must pair with spin_unlock(&sem->lock) or > + * spin_unlock(&sem_perm.lock), thus just the control barrier is > insufficient. > + * >

Re: [PATCH] ipc/sem.c: Update/correct memory barriers

2015-08-10 Thread Peter Zijlstra
On Sun, Aug 09, 2015 at 07:55:39PM +0200, Manfred Spraul wrote: > sem_lock() did not properly pair memory barriers: > > !spin_is_locked() and spin_unlock_wait() are both only control barriers. > The code needs an acquire barrier, otherwise the cpu might perform > read operations before the lock te

[PATCH] ipc/sem.c: Update/correct memory barriers

2015-08-09 Thread Manfred Spraul
sem_lock() did not properly pair memory barriers: !spin_is_locked() and spin_unlock_wait() are both only control barriers. The code needs an acquire barrier, otherwise the cpu might perform read operations before the lock test. As no primitive exists inside and since it seems noone wants another

Re: [PATCH] ipc/sem.c: Update/correct memory barriers

2015-03-01 Thread Oleg Nesterov
Manfred, I leave this to you and Paul/Peter, but... On 03/01, Manfred Spraul wrote: > > +/* > + * spin_unlock_wait() and !spin_is_locked() are not memory barriers, they > + * are only control barriers, thus a memory barrier is required if the > + * operation should act as an acquire memory barrie

[PATCH] ipc/sem.c: Update/correct memory barriers

2015-03-01 Thread Manfred Spraul
3rd version of the patch: sem_lock() did not properly pair memory barriers: !spin_is_locked() and spin_unlock_wait() are both only control barriers. The code needs an acquire barrier, otherwise the cpu might perform read operations before the lock test. The patch: - defines new barriers that def

Re: [PATCH] ipc/sem.c: Update/correct memory barriers.

2015-03-01 Thread Manfred Spraul
Hi Oleg, On 03/01/2015 02:22 PM, Oleg Nesterov wrote: On 02/28, Peter Zijlstra wrote: On Sat, Feb 28, 2015 at 09:36:15PM +0100, Manfred Spraul wrote: +/* + * Place this after a control barrier (such as e.g. a spin_unlock_wait()) + * to ensure that reads cannot be moved ahead of the control_bar

Re: [PATCH] ipc/sem.c: Update/correct memory barriers.

2015-03-01 Thread Oleg Nesterov
On 02/28, Paul E. McKenney wrote: > > The idea is that this would become a no-op on x86, s390, sparc &c, an isb > instruction on ARM, an isync instruction on Power, and I cannot remember > what on Itanium? The other idea being to provide read-to-read control > ordering in addition to the current r

Re: [PATCH] ipc/sem.c: Update/correct memory barriers.

2015-03-01 Thread Oleg Nesterov
On 02/28, Peter Zijlstra wrote: > > On Sat, Feb 28, 2015 at 09:36:15PM +0100, Manfred Spraul wrote: > > +/* > > + * Place this after a control barrier (such as e.g. a spin_unlock_wait()) > > + * to ensure that reads cannot be moved ahead of the control_barrier. > > + * Writes do not need a barrier,

Re: [PATCH] ipc/sem.c: Update/correct memory barriers.

2015-02-28 Thread Paul E. McKenney
On Sat, Feb 28, 2015 at 10:45:33PM +0100, Peter Zijlstra wrote: > On Sat, Feb 28, 2015 at 09:36:15PM +0100, Manfred Spraul wrote: > > +/* > > + * Place this after a control barrier (such as e.g. a spin_unlock_wait()) > > + * to ensure that reads cannot be moved ahead of the control_barrier. > > + *

Re: [PATCH] ipc/sem.c: Update/correct memory barriers.

2015-02-28 Thread Peter Zijlstra
On Sat, Feb 28, 2015 at 09:36:15PM +0100, Manfred Spraul wrote: > +/* > + * Place this after a control barrier (such as e.g. a spin_unlock_wait()) > + * to ensure that reads cannot be moved ahead of the control_barrier. > + * Writes do not need a barrier, they are not speculated and thus cannot > +

[PATCH] ipc/sem.c: Update/correct memory barriers.

2015-02-28 Thread Manfred Spraul
sem_lock() did not properly pair memory barriers: spin_is_locked() or spin_unlock_wait() are both only control barriers. The code needs an acquire barrier, otherwise the cpu might perform read operations before the lock test. One path did the memory barriers correctly, in the other path the memor