[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Javier Martinez Canillas]

On reboot or poweroff (machine_shutdown()) a call to smp_send_stop() is
made (to stop the others CPU's) when CONFIG_SMP=y.

arch/arm/kernel/process.c:

void machine_shutdown(void)
{
 #ifdef CONFIG_SMP
       smp_send_stop();
 #endif
}

smp_send_stop() calls the function pointer smp_cross_call(), which is set
on the smp_init_cpus() function for OMAP processors.

arch/arm/mach-omap2/omap-smp.c:

void __init smp_init_cpus(void)
{
...
	set_smp_cross_call(gic_raise_softirq);
...
}

But the ARM setup_arch() function only calls smp_init_cpus()
if CONFIG_SMP=y && is_smp().

arm/kernel/setup.c:

void __init setup_arch(char **cmdline_p)
{
...
 #ifdef CONFIG_SMP
	if (is_smp())
		smp_init_cpus();
 #endif
...
}

Newer OMAP CPU's are SMP machines so omap2plus_defconfig sets
CONFIG_SMP=y. Unfortunately on an OMAP UP machine is_smp()
returns false and smp_init_cpus() is never called and the
smp_cross_call() function remains NULL.

If the machine is rebooted or powered off, smp_send_stop() will
be called (since CONFIG_SMP=y) leading to the following error:

[   42.815551] Restarting system.
[   42.819030] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[   42.827667] pgd = d7a74000
[   42.830566] [00000000] *pgd=96ce7831, *pte=00000000, *ppte=00000000
[   42.837249] Internal error: Oops: 80000007 [#1] SMP ARM
[   42.842773] Modules linked in:
[   42.846008] CPU: 0    Not tainted  (3.5.0-rc3-next-20120622-00002-g62e87ba-dirty #44)
[   42.854278] PC is at 0x0
[   42.856994] LR is at smp_send_stop+0x4c/0xe4
[   42.861511] pc : [<00000000>]    lr : [<c00183a4>]    psr: 60000013
[   42.861511] sp : d6c85e70  ip : 00000000  fp : 00000000
[   42.873626] r10: 00000000  r9 : d6c84000  r8 : 00000002
[   42.879150] r7 : c07235a0  r6 : c06dd2d0  r5 : 000f4241  r4 : d6c85e74
[   42.886047] r3 : 00000000  r2 : 00000000  r1 : 00000006  r0 : d6c85e74
[   42.892944] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   42.900482] Control: 10c5387d  Table: 97a74019  DAC: 00000015
[   42.906555] Process reboot (pid: 1166, stack limit = 0xd6c842f8)
[   42.912902] Stack: (0xd6c85e70 to 0xd6c86000)
[   42.917510] 5e60:                                     c07235a0 00000000 00000000 d6c84000
[   42.926177] 5e80: 01234567 c00143d0 4321fedc c00511bc d6c85ebc 00000168 00000460 00000000
[   42.934814] 5ea0: c1017950 a0000013 c1017900 d8014390 d7ec3858 c0498e48 c1017950 00000000
[   42.943481] 5ec0: d6ddde10 d6c85f78 00000003 00000000 d6ddde10 d6c84000 00000000 00000000
[   42.952117] 5ee0: 00000002 00000000 00000000 c0088c88 00000002 00000000 00000000 c00f4b90
[   42.960784] 5f00: 00000000 d6c85ebc d8014390 d7e311c8 60000013 00000103 00000002 d6c84000
[   42.969421] 5f20: c00f3274 d6e00a00 00000001 60000013 d6c84000 00000000 00000000 c00895d4
[   42.978057] 5f40: 00000002 d8007c80 d781f000 c00f6150 d8010cc0 c00f3274 d781f000 d6c84000
[   42.986694] 5f60: c0013020 d6e00a00 00000001 20000010 0001257c ef000000 00000000 c00895d4
[   42.995361] 5f80: 00000002 00000001 00000003 00000000 00000001 00000003 00000000 00000058
[   43.003997] 5fa0: c00130c8 c0012f00 00000001 00000003 fee1dead 28121969 01234567 00000002
[   43.012634] 5fc0: 00000001 00000003 00000000 00000058 00012584 0001257c 00000001 00000000
[   43.021270] 5fe0: 000124bc bec5cc6c 00008f9c 4a2f7c40 20000010 fee1dead 00000000 00000000
[   43.029968] [<c00183a4>] (smp_send_stop+0x4c/0xe4) from [<c00143d0>] (machine_restart+0xc/0x4c)
[   43.039154] [<c00143d0>] (machine_restart+0xc/0x4c) from [<c00511bc>] (sys_reboot+0x144/0x1f0)
[   43.048278] [<c00511bc>] (sys_reboot+0x144/0x1f0) from [<c0012f00>] (ret_fast_syscall+0x0/0x3c)
[   43.057464] Code: bad PC value
[   43.060760] ---[ end trace c3988d1dd0b8f0fb ]---

Add a check so smp_cross_call() is only called when there is more than one CPU on-line.

Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
---

Changes since v1:

- check for cpumask_empty() on arch/arm/kernel/smp.c instead for
  is_smp() on arch/arm/kernel/process.c

 arch/arm/kernel/smp.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 2c7217d..ea73045 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -563,7 +563,8 @@ void smp_send_stop(void)
 
 	cpumask_copy(&mask, cpu_online_mask);
 	cpumask_clear_cpu(smp_processor_id(), &mask);
-	smp_cross_call(&mask, IPI_CPU_STOP);
+	if (!cpumask_empty(&mask))
+		smp_cross_call(&mask, IPI_CPU_STOP);
 
 	/* Wait up to one second for other CPUs to stop */
 	timeout = USEC_PER_SEC;
-- 
1.7.7.6

[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Javier Martinez Canillas]

On reboot or poweroff (machine_shutdown()) a call to smp_send_stop() is
made (to stop the others CPU's) when CONFIG_SMP=y.

arch/arm/kernel/process.c:

void machine_shutdown(void)
{
 #ifdef CONFIG_SMP
       smp_send_stop();
 #endif
}

smp_send_stop() calls the function pointer smp_cross_call(), which is set
on the smp_init_cpus() function for OMAP processors.

arch/arm/mach-omap2/omap-smp.c:

void __init smp_init_cpus(void)
{
...
	set_smp_cross_call(gic_raise_softirq);
...
}

But the ARM setup_arch() function only calls smp_init_cpus()
if CONFIG_SMP=y && is_smp().

arm/kernel/setup.c:

void __init setup_arch(char **cmdline_p)
{
...
 #ifdef CONFIG_SMP
	if (is_smp())
		smp_init_cpus();
 #endif
...
}

Newer OMAP CPU's are SMP machines so omap2plus_defconfig sets
CONFIG_SMP=y. Unfortunately on an OMAP UP machine is_smp()
returns false and smp_init_cpus() is never called and the
smp_cross_call() function remains NULL.

If the machine is rebooted or powered off, smp_send_stop() will
be called (since CONFIG_SMP=y) leading to the following error:

[   42.815551] Restarting system.
[   42.819030] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[   42.827667] pgd = d7a74000
[   42.830566] [00000000] *pgd=96ce7831, *pte=00000000, *ppte=00000000
[   42.837249] Internal error: Oops: 80000007 [#1] SMP ARM
[   42.842773] Modules linked in:
[   42.846008] CPU: 0    Not tainted  (3.5.0-rc3-next-20120622-00002-g62e87ba-dirty #44)
[   42.854278] PC is at 0x0
[   42.856994] LR is at smp_send_stop+0x4c/0xe4
[   42.861511] pc : [<00000000>]    lr : [<c00183a4>]    psr: 60000013
[   42.861511] sp : d6c85e70  ip : 00000000  fp : 00000000
[   42.873626] r10: 00000000  r9 : d6c84000  r8 : 00000002
[   42.879150] r7 : c07235a0  r6 : c06dd2d0  r5 : 000f4241  r4 : d6c85e74
[   42.886047] r3 : 00000000  r2 : 00000000  r1 : 00000006  r0 : d6c85e74
[   42.892944] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[   42.900482] Control: 10c5387d  Table: 97a74019  DAC: 00000015
[   42.906555] Process reboot (pid: 1166, stack limit = 0xd6c842f8)
[   42.912902] Stack: (0xd6c85e70 to 0xd6c86000)
[   42.917510] 5e60:                                     c07235a0 00000000 00000000 d6c84000
[   42.926177] 5e80: 01234567 c00143d0 4321fedc c00511bc d6c85ebc 00000168 00000460 00000000
[   42.934814] 5ea0: c1017950 a0000013 c1017900 d8014390 d7ec3858 c0498e48 c1017950 00000000
[   42.943481] 5ec0: d6ddde10 d6c85f78 00000003 00000000 d6ddde10 d6c84000 00000000 00000000
[   42.952117] 5ee0: 00000002 00000000 00000000 c0088c88 00000002 00000000 00000000 c00f4b90
[   42.960784] 5f00: 00000000 d6c85ebc d8014390 d7e311c8 60000013 00000103 00000002 d6c84000
[   42.969421] 5f20: c00f3274 d6e00a00 00000001 60000013 d6c84000 00000000 00000000 c00895d4
[   42.978057] 5f40: 00000002 d8007c80 d781f000 c00f6150 d8010cc0 c00f3274 d781f000 d6c84000
[   42.986694] 5f60: c0013020 d6e00a00 00000001 20000010 0001257c ef000000 00000000 c00895d4
[   42.995361] 5f80: 00000002 00000001 00000003 00000000 00000001 00000003 00000000 00000058
[   43.003997] 5fa0: c00130c8 c0012f00 00000001 00000003 fee1dead 28121969 01234567 00000002
[   43.012634] 5fc0: 00000001 00000003 00000000 00000058 00012584 0001257c 00000001 00000000
[   43.021270] 5fe0: 000124bc bec5cc6c 00008f9c 4a2f7c40 20000010 fee1dead 00000000 00000000
[   43.029968] [<c00183a4>] (smp_send_stop+0x4c/0xe4) from [<c00143d0>] (machine_restart+0xc/0x4c)
[   43.039154] [<c00143d0>] (machine_restart+0xc/0x4c) from [<c00511bc>] (sys_reboot+0x144/0x1f0)
[   43.048278] [<c00511bc>] (sys_reboot+0x144/0x1f0) from [<c0012f00>] (ret_fast_syscall+0x0/0x3c)
[   43.057464] Code: bad PC value
[   43.060760] ---[ end trace c3988d1dd0b8f0fb ]---

Add a check so smp_cross_call() is only called when there is more than one CPU on-line.

Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
---

Changes since v1:

- check for cpumask_empty() on arch/arm/kernel/smp.c instead for
  is_smp() on arch/arm/kernel/process.c

 arch/arm/kernel/smp.c |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 2c7217d..ea73045 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -563,7 +563,8 @@ void smp_send_stop(void)
 
 	cpumask_copy(&mask, cpu_online_mask);
 	cpumask_clear_cpu(smp_processor_id(), &mask);
-	smp_cross_call(&mask, IPI_CPU_STOP);
+	if (!cpumask_empty(&mask))
+		smp_cross_call(&mask, IPI_CPU_STOP);
 
 	/* Wait up to one second for other CPUs to stop */
 	timeout = USEC_PER_SEC;
-- 
1.7.7.6

Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Shawn Guo]

It seems the same patch has been there for a while.

http://thread.gmane.org/gmane.linux.kernel/1303115

Regards,
Shawn

On Sun, Jun 24, 2012 at 12:28:10PM +0200, Javier Martinez Canillas wrote:
> On reboot or poweroff (machine_shutdown()) a call to smp_send_stop() is
> made (to stop the others CPU's) when CONFIG_SMP=y.
> 
> arch/arm/kernel/process.c:
> 
> void machine_shutdown(void)
> {
>  #ifdef CONFIG_SMP
>        smp_send_stop();
>  #endif
> }
> 
> smp_send_stop() calls the function pointer smp_cross_call(), which is set
> on the smp_init_cpus() function for OMAP processors.
> 
> arch/arm/mach-omap2/omap-smp.c:
> 
> void __init smp_init_cpus(void)
> {
> ...
> 	set_smp_cross_call(gic_raise_softirq);
> ...
> }
> 
> But the ARM setup_arch() function only calls smp_init_cpus()
> if CONFIG_SMP=y && is_smp().
> 
> arm/kernel/setup.c:
> 
> void __init setup_arch(char **cmdline_p)
> {
> ...
>  #ifdef CONFIG_SMP
> 	if (is_smp())
> 		smp_init_cpus();
>  #endif
> ...
> }
> 
> Newer OMAP CPU's are SMP machines so omap2plus_defconfig sets
> CONFIG_SMP=y. Unfortunately on an OMAP UP machine is_smp()
> returns false and smp_init_cpus() is never called and the
> smp_cross_call() function remains NULL.
> 
> If the machine is rebooted or powered off, smp_send_stop() will
> be called (since CONFIG_SMP=y) leading to the following error:
> 
> [   42.815551] Restarting system.
> [   42.819030] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [   42.827667] pgd = d7a74000
> [   42.830566] [00000000] *pgd=96ce7831, *pte=00000000, *ppte=00000000
> [   42.837249] Internal error: Oops: 80000007 [#1] SMP ARM
> [   42.842773] Modules linked in:
> [   42.846008] CPU: 0    Not tainted  (3.5.0-rc3-next-20120622-00002-g62e87ba-dirty #44)
> [   42.854278] PC is at 0x0
> [   42.856994] LR is at smp_send_stop+0x4c/0xe4
> [   42.861511] pc : [<00000000>]    lr : [<c00183a4>]    psr: 60000013
> [   42.861511] sp : d6c85e70  ip : 00000000  fp : 00000000
> [   42.873626] r10: 00000000  r9 : d6c84000  r8 : 00000002
> [   42.879150] r7 : c07235a0  r6 : c06dd2d0  r5 : 000f4241  r4 : d6c85e74
> [   42.886047] r3 : 00000000  r2 : 00000000  r1 : 00000006  r0 : d6c85e74
> [   42.892944] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> [   42.900482] Control: 10c5387d  Table: 97a74019  DAC: 00000015
> [   42.906555] Process reboot (pid: 1166, stack limit = 0xd6c842f8)
> [   42.912902] Stack: (0xd6c85e70 to 0xd6c86000)
> [   42.917510] 5e60:                                     c07235a0 00000000 00000000 d6c84000
> [   42.926177] 5e80: 01234567 c00143d0 4321fedc c00511bc d6c85ebc 00000168 00000460 00000000
> [   42.934814] 5ea0: c1017950 a0000013 c1017900 d8014390 d7ec3858 c0498e48 c1017950 00000000
> [   42.943481] 5ec0: d6ddde10 d6c85f78 00000003 00000000 d6ddde10 d6c84000 00000000 00000000
> [   42.952117] 5ee0: 00000002 00000000 00000000 c0088c88 00000002 00000000 00000000 c00f4b90
> [   42.960784] 5f00: 00000000 d6c85ebc d8014390 d7e311c8 60000013 00000103 00000002 d6c84000
> [   42.969421] 5f20: c00f3274 d6e00a00 00000001 60000013 d6c84000 00000000 00000000 c00895d4
> [   42.978057] 5f40: 00000002 d8007c80 d781f000 c00f6150 d8010cc0 c00f3274 d781f000 d6c84000
> [   42.986694] 5f60: c0013020 d6e00a00 00000001 20000010 0001257c ef000000 00000000 c00895d4
> [   42.995361] 5f80: 00000002 00000001 00000003 00000000 00000001 00000003 00000000 00000058
> [   43.003997] 5fa0: c00130c8 c0012f00 00000001 00000003 fee1dead 28121969 01234567 00000002
> [   43.012634] 5fc0: 00000001 00000003 00000000 00000058 00012584 0001257c 00000001 00000000
> [   43.021270] 5fe0: 000124bc bec5cc6c 00008f9c 4a2f7c40 20000010 fee1dead 00000000 00000000
> [   43.029968] [<c00183a4>] (smp_send_stop+0x4c/0xe4) from [<c00143d0>] (machine_restart+0xc/0x4c)
> [   43.039154] [<c00143d0>] (machine_restart+0xc/0x4c) from [<c00511bc>] (sys_reboot+0x144/0x1f0)
> [   43.048278] [<c00511bc>] (sys_reboot+0x144/0x1f0) from [<c0012f00>] (ret_fast_syscall+0x0/0x3c)
> [   43.057464] Code: bad PC value
> [   43.060760] ---[ end trace c3988d1dd0b8f0fb ]---
> 
> Add a check so smp_cross_call() is only called when there is more than one CPU on-line.
> 
> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
> ---
> 
> Changes since v1:
> 
> - check for cpumask_empty() on arch/arm/kernel/smp.c instead for
>   is_smp() on arch/arm/kernel/process.c
> 
>  arch/arm/kernel/smp.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index 2c7217d..ea73045 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -563,7 +563,8 @@ void smp_send_stop(void)
>  
>  	cpumask_copy(&mask, cpu_online_mask);
>  	cpumask_clear_cpu(smp_processor_id(), &mask);
> -	smp_cross_call(&mask, IPI_CPU_STOP);
> +	if (!cpumask_empty(&mask))
> +		smp_cross_call(&mask, IPI_CPU_STOP);
>  
>  	/* Wait up to one second for other CPUs to stop */
>  	timeout = USEC_PER_SEC;
> -- 
> 1.7.7.6
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Shawn Guo]

It seems the same patch has been there for a while.

http://thread.gmane.org/gmane.linux.kernel/1303115

Regards,
Shawn

On Sun, Jun 24, 2012 at 12:28:10PM +0200, Javier Martinez Canillas wrote:
> On reboot or poweroff (machine_shutdown()) a call to smp_send_stop() is
> made (to stop the others CPU's) when CONFIG_SMP=y.
> 
> arch/arm/kernel/process.c:
> 
> void machine_shutdown(void)
> {
>  #ifdef CONFIG_SMP
>        smp_send_stop();
>  #endif
> }
> 
> smp_send_stop() calls the function pointer smp_cross_call(), which is set
> on the smp_init_cpus() function for OMAP processors.
> 
> arch/arm/mach-omap2/omap-smp.c:
> 
> void __init smp_init_cpus(void)
> {
> ...
> 	set_smp_cross_call(gic_raise_softirq);
> ...
> }
> 
> But the ARM setup_arch() function only calls smp_init_cpus()
> if CONFIG_SMP=y && is_smp().
> 
> arm/kernel/setup.c:
> 
> void __init setup_arch(char **cmdline_p)
> {
> ...
>  #ifdef CONFIG_SMP
> 	if (is_smp())
> 		smp_init_cpus();
>  #endif
> ...
> }
> 
> Newer OMAP CPU's are SMP machines so omap2plus_defconfig sets
> CONFIG_SMP=y. Unfortunately on an OMAP UP machine is_smp()
> returns false and smp_init_cpus() is never called and the
> smp_cross_call() function remains NULL.
> 
> If the machine is rebooted or powered off, smp_send_stop() will
> be called (since CONFIG_SMP=y) leading to the following error:
> 
> [   42.815551] Restarting system.
> [   42.819030] Unable to handle kernel NULL pointer dereference at virtual address 00000000
> [   42.827667] pgd = d7a74000
> [   42.830566] [00000000] *pgd=96ce7831, *pte=00000000, *ppte=00000000
> [   42.837249] Internal error: Oops: 80000007 [#1] SMP ARM
> [   42.842773] Modules linked in:
> [   42.846008] CPU: 0    Not tainted  (3.5.0-rc3-next-20120622-00002-g62e87ba-dirty #44)
> [   42.854278] PC is at 0x0
> [   42.856994] LR is at smp_send_stop+0x4c/0xe4
> [   42.861511] pc : [<00000000>]    lr : [<c00183a4>]    psr: 60000013
> [   42.861511] sp : d6c85e70  ip : 00000000  fp : 00000000
> [   42.873626] r10: 00000000  r9 : d6c84000  r8 : 00000002
> [   42.879150] r7 : c07235a0  r6 : c06dd2d0  r5 : 000f4241  r4 : d6c85e74
> [   42.886047] r3 : 00000000  r2 : 00000000  r1 : 00000006  r0 : d6c85e74
> [   42.892944] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> [   42.900482] Control: 10c5387d  Table: 97a74019  DAC: 00000015
> [   42.906555] Process reboot (pid: 1166, stack limit = 0xd6c842f8)
> [   42.912902] Stack: (0xd6c85e70 to 0xd6c86000)
> [   42.917510] 5e60:                                     c07235a0 00000000 00000000 d6c84000
> [   42.926177] 5e80: 01234567 c00143d0 4321fedc c00511bc d6c85ebc 00000168 00000460 00000000
> [   42.934814] 5ea0: c1017950 a0000013 c1017900 d8014390 d7ec3858 c0498e48 c1017950 00000000
> [   42.943481] 5ec0: d6ddde10 d6c85f78 00000003 00000000 d6ddde10 d6c84000 00000000 00000000
> [   42.952117] 5ee0: 00000002 00000000 00000000 c0088c88 00000002 00000000 00000000 c00f4b90
> [   42.960784] 5f00: 00000000 d6c85ebc d8014390 d7e311c8 60000013 00000103 00000002 d6c84000
> [   42.969421] 5f20: c00f3274 d6e00a00 00000001 60000013 d6c84000 00000000 00000000 c00895d4
> [   42.978057] 5f40: 00000002 d8007c80 d781f000 c00f6150 d8010cc0 c00f3274 d781f000 d6c84000
> [   42.986694] 5f60: c0013020 d6e00a00 00000001 20000010 0001257c ef000000 00000000 c00895d4
> [   42.995361] 5f80: 00000002 00000001 00000003 00000000 00000001 00000003 00000000 00000058
> [   43.003997] 5fa0: c00130c8 c0012f00 00000001 00000003 fee1dead 28121969 01234567 00000002
> [   43.012634] 5fc0: 00000001 00000003 00000000 00000058 00012584 0001257c 00000001 00000000
> [   43.021270] 5fe0: 000124bc bec5cc6c 00008f9c 4a2f7c40 20000010 fee1dead 00000000 00000000
> [   43.029968] [<c00183a4>] (smp_send_stop+0x4c/0xe4) from [<c00143d0>] (machine_restart+0xc/0x4c)
> [   43.039154] [<c00143d0>] (machine_restart+0xc/0x4c) from [<c00511bc>] (sys_reboot+0x144/0x1f0)
> [   43.048278] [<c00511bc>] (sys_reboot+0x144/0x1f0) from [<c0012f00>] (ret_fast_syscall+0x0/0x3c)
> [   43.057464] Code: bad PC value
> [   43.060760] ---[ end trace c3988d1dd0b8f0fb ]---
> 
> Add a check so smp_cross_call() is only called when there is more than one CPU on-line.
> 
> Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
> ---
> 
> Changes since v1:
> 
> - check for cpumask_empty() on arch/arm/kernel/smp.c instead for
>   is_smp() on arch/arm/kernel/process.c
> 
>  arch/arm/kernel/smp.c |    3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
> index 2c7217d..ea73045 100644
> --- a/arch/arm/kernel/smp.c
> +++ b/arch/arm/kernel/smp.c
> @@ -563,7 +563,8 @@ void smp_send_stop(void)
>  
>  	cpumask_copy(&mask, cpu_online_mask);
>  	cpumask_clear_cpu(smp_processor_id(), &mask);
> -	smp_cross_call(&mask, IPI_CPU_STOP);
> +	if (!cpumask_empty(&mask))
> +		smp_cross_call(&mask, IPI_CPU_STOP);
>  
>  	/* Wait up to one second for other CPUs to stop */
>  	timeout = USEC_PER_SEC;
> -- 
> 1.7.7.6
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Javier Martinez Canillas]

On Mon, Jun 25, 2012 at 2:51 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> It seems the same patch has been there for a while.
>
> http://thread.gmane.org/gmane.linux.kernel/1303115
>
> Regards,
> Shawn
>

Hi Shawn,

Thanks for the info, I first send this patch:
http://www.spinics.net/lists/linux-omap/msg72489.html but Russell
pointed me to the thread:
http://lists.arm.linux.org.uk/lurker/thread/20120523.200015.2fdfd505.en.html
and told me that no patch ever came from his response on the subject.
That's why I sent this patch with Russell suggested approach to solve
the issue. But as you said, it was sent but got lost.

That's a pity since the bug is pretty serious (it deterministically
crashes when trying to reboot the board).

Thanks a lot and best regards,
Javier

[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Javier Martinez Canillas]

On Mon, Jun 25, 2012 at 2:51 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> It seems the same patch has been there for a while.
>
> http://thread.gmane.org/gmane.linux.kernel/1303115
>
> Regards,
> Shawn
>

Hi Shawn,

Thanks for the info, I first send this patch:
http://www.spinics.net/lists/linux-omap/msg72489.html but Russell
pointed me to the thread:
http://lists.arm.linux.org.uk/lurker/thread/20120523.200015.2fdfd505.en.html
and told me that no patch ever came from his response on the subject.
That's why I sent this patch with Russell suggested approach to solve
the issue. But as you said, it was sent but got lost.

That's a pity since the bug is pretty serious (it deterministically
crashes when trying to reboot the board).

Thanks a lot and best regards,
Javier

Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Russell King - ARM Linux]

On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote:
> It seems the same patch has been there for a while.
> 
> http://thread.gmane.org/gmane.linux.kernel/1303115

Bah, why doesn't stuff like this get resent if nothing has happened for
a while?

[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Russell King - ARM Linux]

On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote:
> It seems the same patch has been there for a while.
> 
> http://thread.gmane.org/gmane.linux.kernel/1303115

Bah, why doesn't stuff like this get resent if nothing has happened for
a while?

Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Javier Martinez Canillas]

On Mon, Jun 25, 2012 at 10:49 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote:
>> It seems the same patch has been there for a while.
>>
>> http://thread.gmane.org/gmane.linux.kernel/1303115
>
> Bah, why doesn't stuff like this get resent if nothing has happened for
> a while?

Indeed. At least other people that face the same issue (like me) sends
similar patches to remind you :-)

Best regards,
Javier

[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Javier Martinez Canillas]

On Mon, Jun 25, 2012 at 10:49 AM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote:
>> It seems the same patch has been there for a while.
>>
>> http://thread.gmane.org/gmane.linux.kernel/1303115
>
> Bah, why doesn't stuff like this get resent if nothing has happened for
> a while?

Indeed. At least other people that face the same issue (like me) sends
similar patches to remind you :-)

Best regards,
Javier

Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Jon Hunter]

Hi Javier,

On 06/25/2012 05:31 AM, Javier Martinez Canillas wrote:
> On Mon, Jun 25, 2012 at 10:49 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote:
>>> It seems the same patch has been there for a while.
>>>
>>> http://thread.gmane.org/gmane.linux.kernel/1303115
>>
>> Bah, why doesn't stuff like this get resent if nothing has happened for
>> a while?
> 
> Indeed. At least other people that face the same issue (like me) sends
> similar patches to remind you :-)

I checked with Russell but this one is not in his patch tracking system
[1] and so still not queued. Can you submit this? Would be great to get
this one in.

Cheers
Jon

[1] http://www.arm.linux.org.uk/developer/patches/

[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Jon Hunter]

Hi Javier,

On 06/25/2012 05:31 AM, Javier Martinez Canillas wrote:
> On Mon, Jun 25, 2012 at 10:49 AM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote:
>>> It seems the same patch has been there for a while.
>>>
>>> http://thread.gmane.org/gmane.linux.kernel/1303115
>>
>> Bah, why doesn't stuff like this get resent if nothing has happened for
>> a while?
> 
> Indeed. At least other people that face the same issue (like me) sends
> similar patches to remind you :-)

I checked with Russell but this one is not in his patch tracking system
[1] and so still not queued. Can you submit this? Would be great to get
this one in.

Cheers
Jon

[1] http://www.arm.linux.org.uk/developer/patches/

Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Will Deacon]

On Fri, Jul 27, 2012 at 06:15:04PM +0100, Jon Hunter wrote:
> Hi Javier,
> 
> On 06/25/2012 05:31 AM, Javier Martinez Canillas wrote:
> > On Mon, Jun 25, 2012 at 10:49 AM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> >> On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote:
> >>> It seems the same patch has been there for a while.
> >>>
> >>> http://thread.gmane.org/gmane.linux.kernel/1303115
> >>
> >> Bah, why doesn't stuff like this get resent if nothing has happened for
> >> a while?
> > 
> > Indeed. At least other people that face the same issue (like me) sends
> > similar patches to remind you :-)
> 
> I checked with Russell but this one is not in his patch tracking system
> [1] and so still not queued. Can you submit this? Would be great to get
> this one in.

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.

Will

[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Will Deacon]

On Fri, Jul 27, 2012 at 06:15:04PM +0100, Jon Hunter wrote:
> Hi Javier,
> 
> On 06/25/2012 05:31 AM, Javier Martinez Canillas wrote:
> > On Mon, Jun 25, 2012 at 10:49 AM, Russell King - ARM Linux
> > <linux@arm.linux.org.uk> wrote:
> >> On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote:
> >>> It seems the same patch has been there for a while.
> >>>
> >>> http://thread.gmane.org/gmane.linux.kernel/1303115
> >>
> >> Bah, why doesn't stuff like this get resent if nothing has happened for
> >> a while?
> > 
> > Indeed. At least other people that face the same issue (like me) sends
> > similar patches to remind you :-)
> 
> I checked with Russell but this one is not in his patch tracking system
> [1] and so still not queued. Can you submit this? Would be great to get
> this one in.

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.

Will

Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Russell King - ARM Linux]

On Fri, Jul 27, 2012 at 09:44:47PM +0100, Will Deacon wrote:
> On Fri, Jul 27, 2012 at 06:15:04PM +0100, Jon Hunter wrote:
> > Hi Javier,
> > 
> > On 06/25/2012 05:31 AM, Javier Martinez Canillas wrote:
> > > On Mon, Jun 25, 2012 at 10:49 AM, Russell King - ARM Linux
> > > <linux@arm.linux.org.uk> wrote:
> > >> On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote:
> > >>> It seems the same patch has been there for a while.
> > >>>
> > >>> http://thread.gmane.org/gmane.linux.kernel/1303115
> > >>
> > >> Bah, why doesn't stuff like this get resent if nothing has happened for
> > >> a while?
> > > 
> > > Indeed. At least other people that face the same issue (like me) sends
> > > similar patches to remind you :-)
> > 
> > I checked with Russell but this one is not in his patch tracking system
> > [1] and so still not queued. Can you submit this? Would be great to get
> > this one in.
> 
> 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?

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.

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

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

[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Russell King - ARM Linux]

On Fri, Jul 27, 2012 at 09:44:47PM +0100, Will Deacon wrote:
> On Fri, Jul 27, 2012 at 06:15:04PM +0100, Jon Hunter wrote:
> > Hi Javier,
> > 
> > On 06/25/2012 05:31 AM, Javier Martinez Canillas wrote:
> > > On Mon, Jun 25, 2012 at 10:49 AM, Russell King - ARM Linux
> > > <linux@arm.linux.org.uk> wrote:
> > >> On Mon, Jun 25, 2012 at 08:51:37AM +0800, Shawn Guo wrote:
> > >>> It seems the same patch has been there for a while.
> > >>>
> > >>> http://thread.gmane.org/gmane.linux.kernel/1303115
> > >>
> > >> Bah, why doesn't stuff like this get resent if nothing has happened for
> > >> a while?
> > > 
> > > Indeed. At least other people that face the same issue (like me) sends
> > > similar patches to remind you :-)
> > 
> > I checked with Russell but this one is not in his patch tracking system
> > [1] and so still not queued. Can you submit this? Would be great to get
> > this one in.
> 
> 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?

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.

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

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

Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Will Deacon]

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

[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Will Deacon]

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

Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Russell King - ARM Linux]

On Fri, Jul 27, 2012 at 10:40:24PM +0100, Will Deacon wrote:
> On Fri, Jul 27, 2012 at 10:06:37PM +0100, Russell King - ARM Linux wrote:
> > 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.

We should not be even attempting to do any cross calls when there aren't
any other CPUs in the system - that's rather the point of leaving it as
a NULL pointer so it does explode on such systems.

. the scheduler won't call smp_send_reschedule() when there are no other
  CPUs in the system.
. timer ticks won't be broadcast to other CPUs if there are no other CPUs
  in the system.
. function calls will not be issued to other CPUs if there are no other
  CPUs in the system.

There is only one case where this doesn't happen, and that's the shutdown
path.

For instance, smp_call_function*() all check that the target CPUs are
marked online before the arch code is requested to issue an IPI to the
target CPU.

The only place which is missing this check is smp_send_stop().

Now, we could make machine_shutdown() do this instead:

	if (is_smp())
		smp_send_stop();

but why bother calling into smp_send_stop(), and ultimately end up with
the _only_ site which calls smp_cross_call() with an empty CPU mask when
we can avoid the call when the CPU mask is empty - and prevent this
special case of smp_cross_call() being called with an empty CPU mask
ever occuring.

[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Russell King - ARM Linux]

On Fri, Jul 27, 2012 at 10:40:24PM +0100, Will Deacon wrote:
> On Fri, Jul 27, 2012 at 10:06:37PM +0100, Russell King - ARM Linux wrote:
> > 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.

We should not be even attempting to do any cross calls when there aren't
any other CPUs in the system - that's rather the point of leaving it as
a NULL pointer so it does explode on such systems.

. the scheduler won't call smp_send_reschedule() when there are no other
  CPUs in the system.
. timer ticks won't be broadcast to other CPUs if there are no other CPUs
  in the system.
. function calls will not be issued to other CPUs if there are no other
  CPUs in the system.

There is only one case where this doesn't happen, and that's the shutdown
path.

For instance, smp_call_function*() all check that the target CPUs are
marked online before the arch code is requested to issue an IPI to the
target CPU.

The only place which is missing this check is smp_send_stop().

Now, we could make machine_shutdown() do this instead:

	if (is_smp())
		smp_send_stop();

but why bother calling into smp_send_stop(), and ultimately end up with
the _only_ site which calls smp_cross_call() with an empty CPU mask when
we can avoid the call when the CPU mask is empty - and prevent this
special case of smp_cross_call() being called with an empty CPU mask
ever occuring.

Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Will Deacon]

On Sat, Jul 28, 2012 at 11:08:31AM +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 27, 2012 at 10:40:24PM +0100, Will Deacon wrote:
> > On Fri, Jul 27, 2012 at 10:06:37PM +0100, Russell King - ARM Linux wrote:
> > > 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.
> 
> We should not be even attempting to do any cross calls when there aren't
> any other CPUs in the system - that's rather the point of leaving it as
> a NULL pointer so it does explode on such systems.
> 
> . the scheduler won't call smp_send_reschedule() when there are no other
>   CPUs in the system.
> . timer ticks won't be broadcast to other CPUs if there are no other CPUs
>   in the system.
> . function calls will not be issued to other CPUs if there are no other
>   CPUs in the system.
> 
> There is only one case where this doesn't happen, and that's the shutdown
> path.

Ok, that's a pretty compelling argument you've got there :)

> For instance, smp_call_function*() all check that the target CPUs are
> marked online before the arch code is requested to issue an IPI to the
> target CPU.

Yes, thanks for making the case for the original patch. Consistency is the
most important thing with these APIs, so I'll go full circle and offer my
ack for the original patch:

Acked-by: Will Deacon <will.deacon@arm.com>

The next question is: who's putting this into the patch system?

Will

[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Will Deacon]

On Sat, Jul 28, 2012 at 11:08:31AM +0100, Russell King - ARM Linux wrote:
> On Fri, Jul 27, 2012 at 10:40:24PM +0100, Will Deacon wrote:
> > On Fri, Jul 27, 2012 at 10:06:37PM +0100, Russell King - ARM Linux wrote:
> > > 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.
> 
> We should not be even attempting to do any cross calls when there aren't
> any other CPUs in the system - that's rather the point of leaving it as
> a NULL pointer so it does explode on such systems.
> 
> . the scheduler won't call smp_send_reschedule() when there are no other
>   CPUs in the system.
> . timer ticks won't be broadcast to other CPUs if there are no other CPUs
>   in the system.
> . function calls will not be issued to other CPUs if there are no other
>   CPUs in the system.
> 
> There is only one case where this doesn't happen, and that's the shutdown
> path.

Ok, that's a pretty compelling argument you've got there :)

> For instance, smp_call_function*() all check that the target CPUs are
> marked online before the arch code is requested to issue an IPI to the
> target CPU.

Yes, thanks for making the case for the original patch. Consistency is the
most important thing with these APIs, so I'll go full circle and offer my
ack for the original patch:

Acked-by: Will Deacon <will.deacon@arm.com>

The next question is: who's putting this into the patch system?

Will

Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Javier Martinez Canillas]

On Sat, Jul 28, 2012 at 2:11 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Sat, Jul 28, 2012 at 11:08:31AM +0100, Russell King - ARM Linux wrote:
>> On Fri, Jul 27, 2012 at 10:40:24PM +0100, Will Deacon wrote:
>> > On Fri, Jul 27, 2012 at 10:06:37PM +0100, Russell King - ARM Linux wrote:
>> > > 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.
>>
>> We should not be even attempting to do any cross calls when there aren't
>> any other CPUs in the system - that's rather the point of leaving it as
>> a NULL pointer so it does explode on such systems.
>>
>> . the scheduler won't call smp_send_reschedule() when there are no other
>>   CPUs in the system.
>> . timer ticks won't be broadcast to other CPUs if there are no other CPUs
>>   in the system.
>> . function calls will not be issued to other CPUs if there are no other
>>   CPUs in the system.
>>
>> There is only one case where this doesn't happen, and that's the shutdown
>> path.
>
> Ok, that's a pretty compelling argument you've got there :)
>
>> For instance, smp_call_function*() all check that the target CPUs are
>> marked online before the arch code is requested to issue an IPI to the
>> target CPU.
>
> Yes, thanks for making the case for the original patch. Consistency is the
> most important thing with these APIs, so I'll go full circle and offer my
> ack for the original patch:
>
> Acked-by: Will Deacon <will.deacon@arm.com>
>
> The next question is: who's putting this into the patch system?
>
> Will

Hi,

I just put the patch with Will's Acked-by on the patch system. It  was
accepted as patch 7480/1 [1].

The patch is on top of today's linux-next (next-20120727).

Thanks a lot and best regards,
Javier

[1] http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7480/1

[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Javier Martinez Canillas]

On Sat, Jul 28, 2012 at 2:11 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Sat, Jul 28, 2012 at 11:08:31AM +0100, Russell King - ARM Linux wrote:
>> On Fri, Jul 27, 2012 at 10:40:24PM +0100, Will Deacon wrote:
>> > On Fri, Jul 27, 2012 at 10:06:37PM +0100, Russell King - ARM Linux wrote:
>> > > 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.
>>
>> We should not be even attempting to do any cross calls when there aren't
>> any other CPUs in the system - that's rather the point of leaving it as
>> a NULL pointer so it does explode on such systems.
>>
>> . the scheduler won't call smp_send_reschedule() when there are no other
>>   CPUs in the system.
>> . timer ticks won't be broadcast to other CPUs if there are no other CPUs
>>   in the system.
>> . function calls will not be issued to other CPUs if there are no other
>>   CPUs in the system.
>>
>> There is only one case where this doesn't happen, and that's the shutdown
>> path.
>
> Ok, that's a pretty compelling argument you've got there :)
>
>> For instance, smp_call_function*() all check that the target CPUs are
>> marked online before the arch code is requested to issue an IPI to the
>> target CPU.
>
> Yes, thanks for making the case for the original patch. Consistency is the
> most important thing with these APIs, so I'll go full circle and offer my
> ack for the original patch:
>
> Acked-by: Will Deacon <will.deacon@arm.com>
>
> The next question is: who's putting this into the patch system?
>
> Will

Hi,

I just put the patch with Will's Acked-by on the patch system. It  was
accepted as patch 7480/1 [1].

The patch is on top of today's linux-next (next-20120727).

Thanks a lot and best regards,
Javier

[1] http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7480/1

Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Russell King - ARM Linux]

On Sat, Jul 28, 2012 at 04:26:28PM +0200, Javier Martinez Canillas wrote:
> On Sat, Jul 28, 2012 at 2:11 PM, Will Deacon <will.deacon@arm.com> wrote:
> > Acked-by: Will Deacon <will.deacon@arm.com>
> >
> > The next question is: who's putting this into the patch system?
> >
> > Will
> 
> Hi,
> 
> I just put the patch with Will's Acked-by on the patch system. It  was
> accepted as patch 7480/1 [1].
> 
> The patch is on top of today's linux-next (next-20120727).
> 
> Thanks a lot and best regards,
> Javier
> 
> [1] http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7480/1

Isn't this a candidate for stable kernels?

[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Russell King - ARM Linux]

On Sat, Jul 28, 2012 at 04:26:28PM +0200, Javier Martinez Canillas wrote:
> On Sat, Jul 28, 2012 at 2:11 PM, Will Deacon <will.deacon@arm.com> wrote:
> > Acked-by: Will Deacon <will.deacon@arm.com>
> >
> > The next question is: who's putting this into the patch system?
> >
> > Will
> 
> Hi,
> 
> I just put the patch with Will's Acked-by on the patch system. It  was
> accepted as patch 7480/1 [1].
> 
> The patch is on top of today's linux-next (next-20120727).
> 
> Thanks a lot and best regards,
> Javier
> 
> [1] http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7480/1

Isn't this a candidate for stable kernels?

Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Javier Martinez Canillas]

On Sun, Jul 29, 2012 at 11:31 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Jul 28, 2012 at 04:26:28PM +0200, Javier Martinez Canillas wrote:
>> On Sat, Jul 28, 2012 at 2:11 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > Acked-by: Will Deacon <will.deacon@arm.com>
>> >
>> > The next question is: who's putting this into the patch system?
>> >
>> > Will
>>
>> Hi,
>>
>> I just put the patch with Will's Acked-by on the patch system. It  was
>> accepted as patch 7480/1 [1].
>>
>> The patch is on top of today's linux-next (next-20120727).
>>
>> Thanks a lot and best regards,
>> Javier
>>
>> [1] http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7480/1
>
> Isn't this a candidate for stable kernels?

Yes, I forgot it, sorry for that.

Please let me know if I need to resubmit the patch cc'ing stable.

Best regards,
Javier

[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Javier Martinez Canillas]

On Sun, Jul 29, 2012 at 11:31 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Sat, Jul 28, 2012 at 04:26:28PM +0200, Javier Martinez Canillas wrote:
>> On Sat, Jul 28, 2012 at 2:11 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > Acked-by: Will Deacon <will.deacon@arm.com>
>> >
>> > The next question is: who's putting this into the patch system?
>> >
>> > Will
>>
>> Hi,
>>
>> I just put the patch with Will's Acked-by on the patch system. It  was
>> accepted as patch 7480/1 [1].
>>
>> The patch is on top of today's linux-next (next-20120727).
>>
>> Thanks a lot and best regards,
>> Javier
>>
>> [1] http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=7480/1
>
> Isn't this a candidate for stable kernels?

Yes, I forgot it, sorry for that.

Please let me know if I need to resubmit the patch cc'ing stable.

Best regards,
Javier

Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Russell King - ARM Linux]

On Mon, Jul 30, 2012 at 11:22:51AM +0200, Javier Martinez Canillas wrote:
> Yes, I forgot it, sorry for that.
> 
> Please let me know if I need to resubmit the patch cc'ing stable.

I can just add it to the commit.

[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Russell King - ARM Linux]

On Mon, Jul 30, 2012 at 11:22:51AM +0200, Javier Martinez Canillas wrote:
> Yes, I forgot it, sorry for that.
> 
> Please let me know if I need to resubmit the patch cc'ing stable.

I can just add it to the commit.

Re: [PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Javier Martinez Canillas]

On Mon, Jul 30, 2012 at 4:35 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Jul 30, 2012 at 11:22:51AM +0200, Javier Martinez Canillas wrote:
>> Yes, I forgot it, sorry for that.
>>
>> Please let me know if I need to resubmit the patch cc'ing stable.
>
> I can just add it to the commit.

Perfect, thanks a lot and sorry for missing that.

Best regards,
Javier

[PATCH 1/1 v2] ARM: only call smp_send_stop() on SMP

[Javier Martinez Canillas]

On Mon, Jul 30, 2012 at 4:35 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Jul 30, 2012 at 11:22:51AM +0200, Javier Martinez Canillas wrote:
>> Yes, I forgot it, sorry for that.
>>
>> Please let me know if I need to resubmit the patch cc'ing stable.
>
> I can just add it to the commit.

Perfect, thanks a lot and sorry for missing that.

Best regards,
Javier