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
next prev parent 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: linkBe 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.