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(>lock) or
> + * spin_unlock(_perm.lock), thus just the control barrier is
> insufficient.
> + *
> + *
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.
+ *
+ *
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
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 test.
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
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 include/spinlock.h and since it seems
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
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
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
On 02/28, Paul E. McKenney wrote:
>
> The idea is that this would become a no-op on x86, s390, sparc , 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
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
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
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, they are
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 barrier,
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
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
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.
> > +
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
>
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
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
+ *
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.
+ * Writes
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
22 matches
Mail list logo
