All of lore.kernel.org
 help / color / mirror / Atom feed
From: Suresh Siddha <suresh.b.siddha@intel.com>
To: jens.axboe@oracle.com, paulmck@linux.vnet.ibm.com, mingo@elte.hu,
	jeremy.fitzhardinge@citrix.com, nickpiggin@yahoo.com.au,
	torvalds@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, asit.k.mallick@intel.com
Subject: [patch] generic-ipi: fix the smp_mb() placement
Date: Wed, 29 Oct 2008 15:42:29 -0700	[thread overview]
Message-ID: <20081029224229.GK30573@linux-os.sc.intel.com> (raw)

While looking at some other issue recently, we encountered this smp_mb()
placement issue.  x86 specific code also needs some similar fixes. Patch for
that will follow soon.

Please review the appended generic-ipi fix.

thanks,
suresh
---

From: Suresh Siddha <suresh.b.siddha@intel.com>
Subject: generic-ipi: fix the smp_mb() placement

smp_mb() is needed (to make the memory operations visible globally) before
sending the ipi on the sender and the receiver (on Alpha atleast) needs
smp_read_barrier_depends() in the handler before reading the call_single_queue
list in a lock-free fashion.

On x86, x2apic mode register accesses for sending IPI's don't have serializing
semantics. So the need for smp_mb() before sending the IPI becomes more
critical in x2apic mode.

Remove the unnecessary smp_mb() in csd_flag_wait(), as the presence of that
smp_mb() doesn't mean anything on the sender, when the ipi receiver is not
doing any thing special (like memory fence) after clearing the CSD_FLAG_WAIT.

Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
---

diff --git a/kernel/smp.c b/kernel/smp.c
index f362a85..75c8dde 100644
--- a/kernel/smp.c
+++ b/kernel/smp.c
@@ -51,10 +51,6 @@ static void csd_flag_wait(struct call_single_data *data)
 {
 	/* Wait for response */
 	do {
-		/*
-		 * We need to see the flags store in the IPI handler
-		 */
-		smp_mb();
 		if (!(data->flags & CSD_FLAG_WAIT))
 			break;
 		cpu_relax();
@@ -76,6 +72,11 @@ static void generic_exec_single(int cpu, struct call_single_data *data)
 	list_add_tail(&data->list, &dst->list);
 	spin_unlock_irqrestore(&dst->lock, flags);
 
+	/*
+	 * Make the list addition visible before sending the ipi.
+	 */
+	smp_mb();
+
 	if (ipi)
 		arch_send_call_function_single_ipi(cpu);
 
@@ -157,7 +158,7 @@ void generic_smp_call_function_single_interrupt(void)
 	 * Need to see other stores to list head for checking whether
 	 * list is empty without holding q->lock
 	 */
-	smp_mb();
+	smp_read_barrier_depends();
 	while (!list_empty(&q->list)) {
 		unsigned int data_flags;
 
@@ -191,7 +192,7 @@ void generic_smp_call_function_single_interrupt(void)
 		/*
 		 * See comment on outer loop
 		 */
-		smp_mb();
+		smp_read_barrier_depends();
 	}
 }
 
@@ -370,6 +371,11 @@ int smp_call_function_mask(cpumask_t mask, void (*func)(void *), void *info,
 	list_add_tail_rcu(&data->csd.list, &call_function_queue);
 	spin_unlock_irqrestore(&call_function_lock, flags);
 
+	/*
+	 * Make the list addition visible before sending the ipi.
+	 */
+	smp_mb();
+
 	/* Send a message to all CPUs in the map */
 	arch_send_call_function_ipi(mask);
 

             reply	other threads:[~2008-10-29 22:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-29 22:42 Suresh Siddha [this message]
2008-10-30  7:20 ` [patch] generic-ipi: fix the smp_mb() placement Jens Axboe
2008-10-30 16:30   ` Suresh Siddha
2008-10-30 17:25     ` Jens Axboe
2008-10-30 18:53 ` Ingo Molnar
2008-10-30 20:23   ` Suresh Siddha
2008-10-31  5:10     ` Jeremy Fitzhardinge
2008-10-31  9:39       ` Ingo Molnar
2008-10-31 11:12         ` Jeremy Fitzhardinge
2008-10-31 16:53           ` Suresh Siddha
2008-10-31 20:30             ` Jeremy Fitzhardinge
2008-11-03 10:17               ` Ingo Molnar
2008-11-03 23:48                 ` Jeremy Fitzhardinge
2008-11-04  9:19                   ` Ingo Molnar
2008-11-04 22:25                     ` Suresh Siddha
2008-11-05  9:20                       ` Jens Axboe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081029224229.GK30573@linux-os.sc.intel.com \
    --to=suresh.b.siddha@intel.com \
    --cc=asit.k.mallick@intel.com \
    --cc=jens.axboe@oracle.com \
    --cc=jeremy.fitzhardinge@citrix.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.