[Crash-utility] poisoned per_cpu data not handled on ppc64

Dave Anderson anderson at redhat.com
Thu Mar 9 19:47:51 UTC 2006


Haren Myneni wrote:

>
> Olaf,
>         I was looking in 2.6.16-rc5-git8, but did not find the patch that you mentioned.
>
>
> arch/powerpc/kernel/setup_64.c:
>
> #ifdef CONFIG_SMP
> void __init setup_per_cpu_areas(void)
> {
>         int i;
>         unsigned long size;
>         char *ptr;
>
>         /* Copy section for each CPU (we discard the original) */
>         size = ALIGN(__per_cpu_end - __per_cpu_start, SMP_CACHE_BYTES);
> #ifdef CONFIG_MODULES
>         if (size < PERCPU_ENOUGH_ROOM)
>                 size = PERCPU_ENOUGH_ROOM;
> #endif
>
>         for_each_cpu(i) {
>                 ptr = alloc_bootmem_node(NODE_DATA(cpu_to_node(i)), size);
>                 if (!ptr)
>                         panic("Cannot allocate cpu data for CPU %d\n", i);
>
>                 paca[i].data_offset = ptr - __per_cpu_start;
>                 memcpy(ptr, __per_cpu_start, __per_cpu_end - __per_cpu_start);
>      }
> }
>
>
>  Instead of depending on paca[#].data_offset, my fix will use cpu_online_map to read the valid cpu paca structs. But,
> if the kernel sets 0xeeeeeeeeeeeeeeeeULL, yes, using this value will be the better solution.
>
> Dave, the attached patch contains both fixes that Rachita reported.
>         - Report an error message if the thread is running in user space and print regs.
>         - Finding the valid per_cpu_offset values
>
> Thanks
> Haren
>

Haren,

Is this right?  NR_CPUS is hardcoded (in crash) to 32 for ppc64,
and BITS_FOR_LONG is 64, making it "ulong cpu_online_map[0]":

@@ -2282,21 +2298,22 @@ parse_cmdline_arg(void)
 static void
 ppc64_paca_init(void)
 {
+#define BITS_FOR_LONG sizeof(ulong)*8
        int i, cpus, nr_paca;
        char *cpu_paca_buf;
        ulong data_offset;
-       ulong per_cpu_offset;
-       ulong cpuid_offset;
-       signed short cpuid;
+       ulong cpu_online_map[NR_CPUS/BITS_FOR_LONG];

Or am I missing something obvious?

Also, I get a little nervous about depending upon the NR_CPUS
value compiled into crash being the same as the configured
NR_CPUS in the kernel.  As far as crash is concerned, NR_CPUS
means the "largest possible" cpu configuration that this version
of *crash* will support; it's not meant to be aligned with
the kernel's value.

But if you guys are happy with that, it's fine with me.

Dave

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/crash-utility/attachments/20060309/654af6b7/attachment.htm>


More information about the Crash-utility mailing list