All of lore.kernel.org
 help / color / mirror / Atom feed
From: Will Deacon <will.deacon@arm.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Jon Hunter <jon-hunter@ti.com>,
	Javier Martinez Canillas <martinez.javier@gmail.com>,
	"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
	Tony Lindgren <tony@atomide.com>,
	Javier Martinez Canillas <javier@dowhile0.org>,
	Shawn Guo <shawn.guo@linaro.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP
Date: Fri, 27 Jul 2012 22:40:24 +0100	[thread overview]
Message-ID: <20120727214024.GA10249@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <20120727210637.GA16377@n2100.arm.linux.org.uk>

Hi Russell,

On Fri, Jul 27, 2012 at 10:06:37PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 27, 2012 at 09:44:47PM +0100, Will Deacon wrote:
> > I did comment on this one:
> > 
> >   http://thread.gmane.org/gmane.linux.kernel/1303115
> > 
> > and I really think we should fix the cause of the problem, rather than
> > point patching this instance of it.
> 
> What do you think needs fixing there?

Well, we certainly need to fix the NULL dereference and the original patch
does do that. I just think it might be nicer to remove the possibility of a
NULL dereference instead.

> We support booting a kernel on systems with or without SMP support, even
> with a SMP kernel.  When the kernel is booted on such a system, it is
> undefined whether smp_cross_call() is a valid function pointer.

So let's define it to point at a dummy function which explodes with a BUG if
the cpumask passed in isn't empty. That allows SMP kernels to do things like
`cross call to all other cores' without having to worry about whether there
are any other cores or not.

> In any case, when we have only one CPU online in the system, it is
> pointless even calling smp_cross_call().

Pointless, but also error-prone and requiring explicit cpumask checks at
each call-site.

> That is why I explicitly suggested this solution.  This is the solution
> _I_ want, because it is the most sane solution all round.

Adding a dummy implementation is straightforward [ok, this is untested]:


diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 2c7217d..ffa411f 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -329,7 +329,13 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
        }
 }
 
-static void (*smp_cross_call)(const struct cpumask *, unsigned int);
+static void dummy_smp_cross_call(const struct cpumask *mask, unsigned int irq)
+{
+       BUG_ON(!cpumask_empty(mask));
+}
+
+static void (*smp_cross_call)(const struct cpumask *, unsigned int) =
+       dummy_smp_cross_call;
 
 void __init set_smp_cross_call(void (*fn)(const struct cpumask *, unsigned int))
 {


If you still prefer checking at the call-site then the original patch will
certainly work. Otherwise, I'm happy to submit the above after some testing.

Will

WARNING: multiple messages have this Message-ID (diff)
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP
Date: Fri, 27 Jul 2012 22:40:24 +0100	[thread overview]
Message-ID: <20120727214024.GA10249@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <20120727210637.GA16377@n2100.arm.linux.org.uk>

Hi Russell,

On Fri, Jul 27, 2012 at 10:06:37PM +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 27, 2012 at 09:44:47PM +0100, Will Deacon wrote:
> > I did comment on this one:
> > 
> >   http://thread.gmane.org/gmane.linux.kernel/1303115
> > 
> > and I really think we should fix the cause of the problem, rather than
> > point patching this instance of it.
> 
> What do you think needs fixing there?

Well, we certainly need to fix the NULL dereference and the original patch
does do that. I just think it might be nicer to remove the possibility of a
NULL dereference instead.

> We support booting a kernel on systems with or without SMP support, even
> with a SMP kernel.  When the kernel is booted on such a system, it is
> undefined whether smp_cross_call() is a valid function pointer.

So let's define it to point at a dummy function which explodes with a BUG if
the cpumask passed in isn't empty. That allows SMP kernels to do things like
`cross call to all other cores' without having to worry about whether there
are any other cores or not.

> In any case, when we have only one CPU online in the system, it is
> pointless even calling smp_cross_call().

Pointless, but also error-prone and requiring explicit cpumask checks at
each call-site.

> That is why I explicitly suggested this solution.  This is the solution
> _I_ want, because it is the most sane solution all round.

Adding a dummy implementation is straightforward [ok, this is untested]:


diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 2c7217d..ffa411f 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -329,7 +329,13 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
        }
 }
 
-static void (*smp_cross_call)(const struct cpumask *, unsigned int);
+static void dummy_smp_cross_call(const struct cpumask *mask, unsigned int irq)
+{
+       BUG_ON(!cpumask_empty(mask));
+}
+
+static void (*smp_cross_call)(const struct cpumask *, unsigned int) =
+       dummy_smp_cross_call;
 
 void __init set_smp_cross_call(void (*fn)(const struct cpumask *, unsigned int))
 {


If you still prefer checking at the call-site then the original patch will
certainly work. Otherwise, I'm happy to submit the above after some testing.

Will

  reply	other threads:[~2012-07-27 21:40 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-24 10:28 [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP Javier Martinez Canillas
2012-06-24 10:28 ` Javier Martinez Canillas
2012-06-25  0:51 ` Shawn Guo
2012-06-25  0:51   ` Shawn Guo
2012-06-25  8:09   ` Javier Martinez Canillas
2012-06-25  8:09     ` Javier Martinez Canillas
2012-06-25  8:49   ` Russell King - ARM Linux
2012-06-25  8:49     ` Russell King - ARM Linux
2012-06-25 10:31     ` Javier Martinez Canillas
2012-06-25 10:31       ` Javier Martinez Canillas
2012-07-27 17:15       ` Jon Hunter
2012-07-27 17:15         ` Jon Hunter
2012-07-27 20:44         ` Will Deacon
2012-07-27 20:44           ` Will Deacon
2012-07-27 21:06           ` Russell King - ARM Linux
2012-07-27 21:06             ` Russell King - ARM Linux
2012-07-27 21:40             ` Will Deacon [this message]
2012-07-27 21:40               ` Will Deacon
2012-07-28 10:08               ` Russell King - ARM Linux
2012-07-28 10:08                 ` Russell King - ARM Linux
2012-07-28 12:11                 ` Will Deacon
2012-07-28 12:11                   ` Will Deacon
2012-07-28 14:26                   ` Javier Martinez Canillas
2012-07-28 14:26                     ` Javier Martinez Canillas
2012-07-29 21:31                     ` Russell King - ARM Linux
2012-07-29 21:31                       ` Russell King - ARM Linux
2012-07-30  9:22                       ` Javier Martinez Canillas
2012-07-30  9:22                         ` Javier Martinez Canillas
2012-07-30 14:35                         ` Russell King - ARM Linux
2012-07-30 14:35                           ` Russell King - ARM Linux
2012-07-30 14:51                           ` Javier Martinez Canillas
2012-07-30 14:51                             ` Javier Martinez Canillas

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=20120727214024.GA10249@mudshark.cambridge.arm.com \
    --to=will.deacon@arm.com \
    --cc=javier@dowhile0.org \
    --cc=jon-hunter@ti.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=martinez.javier@gmail.com \
    --cc=shawn.guo@linaro.org \
    --cc=tony@atomide.com \
    /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.