All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Arjan van de Ven <arjan@infradead.org>,
	Rusty Russell <rusty@rustcorp.com.au>,
	jens.axboe@oracle.com
Subject: Re: Buggy IPI and MTRR code on low memory
Date: Wed, 28 Jan 2009 17:46:22 +0100	[thread overview]
Message-ID: <1233161182.10992.52.camel@laptop> (raw)
In-Reply-To: <alpine.DEB.1.10.0901281029150.25359@gandalf.stny.rr.com>

On Wed, 2009-01-28 at 11:38 -0500, Steven Rostedt wrote:

> The problem is that if we use the stack, then we must wait for the 
> function to finish. But in the mtrr code, the called functions are waiting 
> for the caller to do something after the smp_call_function. Thus we 
> deadlock!

You'd have to 'fix' the regular fallback paths to use your scheme as
well.

Below is a fix for the mtrr code to not rely on this.

---
Subject: x86: fix potential deadlock in set_mtrr()
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Wed Jan 28 17:17:32 CET 2009

smp_call_function() can fall-back to waiting on completion in case of
low memory (GFP_ATOMIC). set_mtrr() relies on the async behaviour of !wait.

This would deadlock.

Fix this by providing per-cpu csd's and using __smp_call_function_single().

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
 arch/x86/kernel/cpu/mtrr/main.c |   34 ++++++++++++++++++++++++++++------
 1 file changed, 28 insertions(+), 6 deletions(-)

Index: linux-2.6/arch/x86/kernel/cpu/mtrr/main.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/main.c
+++ linux-2.6/arch/x86/kernel/cpu/mtrr/main.c
@@ -38,6 +38,7 @@
 #include <linux/cpu.h>
 #include <linux/mutex.h>
 #include <linux/sort.h>
+#include <linux/smp.h>
 
 #include <asm/e820.h>
 #include <asm/mtrr.h>
@@ -130,12 +131,12 @@ struct set_mtrr_data {
 	mtrr_type	smp_type;
 };
 
+#ifdef CONFIG_SMP
 static void ipi_handler(void *info)
 /*  [SUMMARY] Synchronisation handler. Executed by "other" CPUs.
     [RETURNS] Nothing.
 */
 {
-#ifdef CONFIG_SMP
 	struct set_mtrr_data *data = info;
 	unsigned long flags;
 
@@ -158,9 +159,31 @@ static void ipi_handler(void *info)
 
 	atomic_dec(&data->count);
 	local_irq_restore(flags);
-#endif
 }
 
+DEFINE_PER_CPU(struct call_single_data, mtrr_csd);
+
+static void set_mtrr_smp(struct set_mtrr_data *data)
+{
+	int cpu;
+
+	for_each_online_cpu(cpu) {
+		struct call_single_data *csd = &per_cpu(mtrr_csd, cpu);
+
+		if (cpu == smp_processor_id())
+			continue;
+
+		csd->func = ipi_handler;
+		csd->info = data;
+		__smp_call_function_single(cpu, csd);
+	}
+}
+#else
+static void set_mtrr_smp(struct set_mtrr_data *data)
+{
+}
+#endif
+
 static inline int types_compatible(mtrr_type type1, mtrr_type type2) {
 	return type1 == MTRR_TYPE_UNCACHABLE ||
 	       type2 == MTRR_TYPE_UNCACHABLE ||
@@ -222,12 +245,11 @@ static void set_mtrr(unsigned int reg, u
 	smp_wmb();
 	atomic_set(&data.gate,0);
 
-	/*  Start the ball rolling on other CPUs  */
-	if (smp_call_function(ipi_handler, &data, 0) != 0)
-		panic("mtrr: timed out waiting for other CPUs\n");
-
 	local_irq_save(flags);
 
+	/*  Start the ball rolling on other CPUs  */
+	set_mtrr_smp(&data);
+
 	while(atomic_read(&data.count))
 		cpu_relax();
 



  parent reply	other threads:[~2009-01-28 16:46 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-28 16:38 Buggy IPI and MTRR code on low memory Steven Rostedt
2009-01-28 16:41 ` Steven Rostedt
2009-01-28 16:46 ` Peter Zijlstra [this message]
2009-01-28 16:56   ` Steven Rostedt
2009-01-28 17:00     ` Peter Zijlstra
2009-01-28 17:24   ` Steven Rostedt
2009-01-28 18:20     ` Peter Zijlstra
2009-01-28 18:52       ` Steven Rostedt
2009-01-28 18:22     ` Arjan van de Ven
2009-01-28 18:34       ` Steven Rostedt
2009-01-28 21:12 ` Andrew Morton
2009-01-28 21:13   ` Andrew Morton
2009-01-28 21:23     ` Steven Rostedt
2009-01-28 22:07       ` Andrew Morton
2009-01-28 22:47         ` Steven Rostedt
2009-01-28 23:20           ` Andrew Morton
2009-01-28 23:50             ` Steven Rostedt
2009-01-28 23:25 ` Rusty Russell
2009-01-28 23:41   ` Steven Rostedt
2009-01-29  0:52   ` [PATCH] use per cpu data for single cpu ipi calls Steven Rostedt
2009-01-29  1:30     ` Andrew Morton
2009-01-29  1:56       ` Steven Rostedt
2009-01-29  8:49       ` Peter Zijlstra
2009-01-29 11:13         ` Ingo Molnar
2009-01-29 11:41           ` Peter Zijlstra
2009-01-29 13:42             ` Ingo Molnar
2009-01-29 14:07             ` Steven Rostedt
2009-01-29 15:08         ` [PATCH -v2] " Steven Rostedt
2009-01-29 15:33           ` Peter Zijlstra
2009-01-29 16:17             ` Ingo Molnar
2009-01-29 17:21           ` Linus Torvalds
2009-01-29 17:44             ` Steven Rostedt
2009-01-29 17:50               ` Steven Rostedt
2009-01-29 18:08               ` Linus Torvalds
2009-01-29 18:11                 ` Steven Rostedt
2009-01-29 18:23                 ` Peter Zijlstra
2009-01-29 18:31                   ` Steven Rostedt
2009-01-29 18:39                   ` Linus Torvalds
2009-01-29 18:44                     ` Peter Zijlstra
2009-01-30 11:23                       ` Jens Axboe
2009-01-30 12:32                         ` [PATCH -v3] " Peter Zijlstra
2009-01-30 12:38                           ` Jens Axboe
2009-01-30 12:48                             ` Peter Zijlstra
2009-01-30 12:55                               ` Jens Axboe
2009-01-30 12:56                                 ` Jens Axboe
2009-01-30 13:00                                   ` Peter Zijlstra
2009-01-30 13:02                           ` [PATCH -v4] " Peter Zijlstra
2009-01-30 14:51                             ` Ingo Molnar
2009-01-30 16:04                           ` [PATCH -v3] " Linus Torvalds
2009-01-30 16:16                             ` Peter Zijlstra
2009-01-31  8:44                               ` Jens Axboe
2009-01-29 18:49                 ` [PATCH -v2] " Ingo Molnar
2009-01-30  1:55                 ` Rusty Russell
2009-01-29 17:47             ` Peter Zijlstra
2009-01-29 17:55               ` Peter Zijlstra
2009-01-29 18:08                 ` Steven Rostedt
2009-01-30  1:11           ` Rusty Russell

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=1233161182.10992.52.camel@laptop \
    --to=peterz@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=arjan@infradead.org \
    --cc=jens.axboe@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=rusty@rustcorp.com.au \
    --cc=tglx@linutronix.de \
    --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.