linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] kexec, ppc64:  Wait for online/possible CPUs only.
@ 2010-06-08  7:38 Matt Evans
  2010-06-08 15:48 ` Michael Ellerman
  0 siblings, 1 reply; 2+ messages in thread
From: Matt Evans @ 2010-06-08  7:38 UTC (permalink / raw)
  To: linuxppc-dev, kexec

kexec_perpare_cpus_wait() iterates i through NR_CPUS to check
paca[i].kexec_state of each to make sure they have quiesced.
However now we have dynamic PACA allocation, paca[NR_CPUS] is not necessarily
valid and we overrun the array;  spurious "cpu is not possible, ignoring"
errors result.  This patch iterates for_each_online_cpu so stays
within the bounds of paca[] -- and every CPU is now 'possible'.

Signed-off-by: Matt Evans <matt@ozlabs.org>
---
 arch/powerpc/kernel/machine_kexec_64.c |   18 +-----------------
 1 files changed, 1 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
index 26f9900..ed31a29 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -182,28 +182,12 @@ static void kexec_prepare_cpus_wait(int wait_state)
 
 	my_cpu = get_cpu();
 	/* Make sure each CPU has atleast made it to the state we need */
-	for (i=0; i < NR_CPUS; i++) {
+	for_each_online_cpu(i) {
 		if (i == my_cpu)
 			continue;
 
 		while (paca[i].kexec_state < wait_state) {
 			barrier();
-			if (!cpu_possible(i)) {
-				printk("kexec: cpu %d hw_cpu_id %d is not"
-						" possible, ignoring\n",
-						i, paca[i].hw_cpu_id);
-				break;
-			}
-			if (!cpu_online(i)) {
-				/* Fixme: this can be spinning in
-				 * pSeries_secondary_wait with a paca
-				 * waiting for it to go online.
-				 */
-				printk("kexec: cpu %d hw_cpu_id %d is not"
-						" online, ignoring\n",
-						i, paca[i].hw_cpu_id);
-				break;
-			}
 			if (i != notified) {
 				printk( "kexec: waiting for cpu %d (physical"
 						" %d) to enter %i state\n",
-- 
1.6.3.3

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] kexec, ppc64:  Wait for online/possible CPUs only.
  2010-06-08  7:38 [PATCH] kexec, ppc64: Wait for online/possible CPUs only Matt Evans
@ 2010-06-08 15:48 ` Michael Ellerman
  0 siblings, 0 replies; 2+ messages in thread
From: Michael Ellerman @ 2010-06-08 15:48 UTC (permalink / raw)
  To: Matt Evans; +Cc: linuxppc-dev, kexec, Milton Miller

[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]

On Tue, 2010-06-08 at 17:38 +1000, Matt Evans wrote:
> kexec_perpare_cpus_wait() iterates i through NR_CPUS to check
> paca[i].kexec_state of each to make sure they have quiesced.
> However now we have dynamic PACA allocation, paca[NR_CPUS] is not necessarily
> valid and we overrun the array;  spurious "cpu is not possible, ignoring"
> errors result.  This patch iterates for_each_online_cpu so stays
> within the bounds of paca[] -- and every CPU is now 'possible'.
> 
> Signed-off-by: Matt Evans <matt@ozlabs.org>

Looks good ..

Cautiously-acked-by: Michael Ellerman <michael@ellerman.id.au>

> -			if (!cpu_online(i)) {
> -				/* Fixme: this can be spinning in
> -				 * pSeries_secondary_wait with a paca
> -				 * waiting for it to go online.
> -				 */
> -				printk("kexec: cpu %d hw_cpu_id %d is not"
> -						" online, ignoring\n",
> -						i, paca[i].hw_cpu_id);
> -				break;
> -			}

I don't see how the state in the Fixme could ever happen, but maybe
Milton can seeing I think he wrote it?

cheers


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2010-06-08 15:48 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-06-08  7:38 [PATCH] kexec, ppc64: Wait for online/possible CPUs only Matt Evans
2010-06-08 15:48 ` Michael Ellerman

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).