Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1441992 > unrolled thread

[PATCH 2/2] ipc/sem.c: Remove duplicated memory barriers.

Started byManfred Spraul <manfred@colorfullife.com>
First post2016-07-13 07:10 +0200
Last post2016-07-13 20:40 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCH 2/2] ipc/sem.c: Remove duplicated memory barriers. Manfred Spraul <manfred@colorfullife.com> - 2016-07-13 07:10 +0200
    Re: [PATCH 2/2] ipc/sem.c: Remove duplicated memory barriers. Davidlohr Bueso <dave@stgolabs.net> - 2016-07-13 18:20 +0200
      Re: [PATCH 2/2] ipc/sem.c: Remove duplicated memory barriers. Manfred Spraul <manfred@colorfullife.com> - 2016-07-13 20:40 +0200

#1441992 — [PATCH 2/2] ipc/sem.c: Remove duplicated memory barriers.

FromManfred Spraul <manfred@colorfullife.com>
Date2016-07-13 07:10 +0200
Subject[PATCH 2/2] ipc/sem.c: Remove duplicated memory barriers.
Message-ID<rUkAN-6XH-1@gated-at.bofh.it>
With 2c610022711 (locking/qspinlock: Fix spin_unlock_wait() some more),
memory barriers were added into spin_unlock_wait().
Thus another barrier is not required.

And as explained in 055ce0fd1b8 (locking/qspinlock: Add comments),
spin_lock() provides a barrier so that reads within the critical
section cannot happen before the write for the lock is visible.
i.e. spin_lock provides an acquire barrier after the write of the lock
variable, this barrier pairs with the smp_mb() in complexmode_enter().

Please review!
For x86, the patch is safe. But I don't know enough about all archs
that support SMP.

Signed-off-by: Manfred Spraul <manfred@colorfullife.com>
---
 ipc/sem.c | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/ipc/sem.c b/ipc/sem.c
index 0da63c8..d7b4212 100644
--- a/ipc/sem.c
+++ b/ipc/sem.c
@@ -291,14 +291,6 @@ static void complexmode_enter(struct sem_array *sma)
 		sem = sma->sem_base + i;
 		spin_unlock_wait(&sem->lock);
 	}
-	/*
-	 * spin_unlock_wait() is not a memory barriers, it is only a
-	 * control barrier. The code must pair with spin_unlock(&sem->lock),
-	 * thus just the control barrier is insufficient.
-	 *
-	 * smp_rmb() is sufficient, as writes cannot pass the control barrier.
-	 */
-	smp_rmb();
 }
 
 /*
@@ -363,12 +355,6 @@ static inline int sem_lock(struct sem_array *sma, struct sembuf *sops,
 		 */
 		spin_lock(&sem->lock);
 
-		/*
-		 * A full barrier is required: the write of sem->lock
-		 * must be visible before the read is executed
-		 */
-		smp_mb();
-
 		if (!smp_load_acquire(&sma->complex_mode)) {
 			/* fast path successful! */
 			return sops->sem_num;
-- 
2.5.5

[toc] | [next] | [standalone]


#1442609

FromDavidlohr Bueso <dave@stgolabs.net>
Date2016-07-13 18:20 +0200
Message-ID<rUv3d-5rv-65@gated-at.bofh.it>
In reply to#1441992
Manfred, shouldn't this patch be part of patch 1 (as you add the unnecessary barriers there? 
Iow, can we have a single patch for all this?

Thanks,
Davidlohr

[toc] | [prev] | [next] | [standalone]


#1442755

FromManfred Spraul <manfred@colorfullife.com>
Date2016-07-13 20:40 +0200
Message-ID<rUxeG-6P0-23@gated-at.bofh.it>
In reply to#1442609
Hi Davidlohr,

On 07/13/2016 06:16 PM, Davidlohr Bueso wrote:
> Manfred, shouldn't this patch be part of patch 1 (as you add the 
> unnecessary barriers there? Iow, can we have a single patch for all this?
>
Two reasons:
- patch 1 is safe for backporting, patch 2 not.
- patch 1 is safe on all architectures, for patch 2 I would like to get 
some review feedback.

e.g. I just found/read 51d7d5205d33 ("powerpc: Add smp_mb() to 
arch_spin_is_locked()"):
For powerpc, a smp_mb() was added into spin_is_locked(), more or less 
for ipc/sem.c.

Patch 1 replaces the spin_is_locked() with smp_load_acquire().
Isn't that the proof that smp_mb() is required?



--
     Manfred

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web