port-powerpc/46591: Doing "ktrace -p <pid>" triggered panic

[he%NetBSD.org@localhost]

>Number:         46591
>Category:       port-powerpc
>Synopsis:       Doing "ktrace -p <pid>" triggered panic
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-powerpc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Jun 12 09:00:00 +0000 2012
>Originator:     Havard Eidnes
>Release:        NetBSD 6.0_BETA2
>Organization:
        None
>Environment:
System: NetBSD malus.urc.uninett.no 6.0_BETA2 NetBSD 6.0_BETA2 (GENERIC) #5: 
Wed May 30 20:32:20 CEST 2012  
he%malus.urc.uninett.no@localhost:/usr/obj/sys/arch/macppc/compile/GENERIC 
macppc
Architecture: powerpc
Machine: macppc
>Description:
        During a pkgsrc bulk build, an awk process appeared to be
        spinning on the CPU checking for "porbability" of a Bourne
        shell script.  I wanted to see if it was doing any system
        calls, and what they were, so did a

        ktrace -p <pid>

        on the process, something which triggered an instant panic.

        This was what was left in the messages file after the machine
        came back up again:

panic: cpu_uarea_alloc: uvm_pglistalloc failed: 12
cpu0: Begin traceback...
0xd9d5bc40: at panic+0x4c
0xd9d5bc80: at cpu_uarea_alloc+0x78
0xd9d5bcb0: at uarea_system_poolpage_alloc+0x20
0xd9d5bcc0: at pool_grow+0x48
0xd9d5bce0: at pool_get+0x58
0xd9d5bd00: at pool_cache_get_slow+0x1a4
0xd9d5bd50: at pool_cache_get_paddr+0x104
0xd9d5bd90: at uvm_uarea_system_alloc+0x1c
0xd9d5bda0: at kthread_create+0x60
0xd9d5be00: at ktrace_common+0x390
0xd9d5be40: at sys_ktrace+0xf4
0xd9d5bec0: at syscall_plain+0x1f0
0xd9d5bf20: user SC trap #45 by 0xfde8120c: srr1=0xd032
           r1=0xffffd760 cr=0x28000044 xer=0x20000000 ctr=0xfde81204
cpu0: End traceback...
dumpsys: TBD
rebooting

        Since there doesn't appear to be any code to dump kernel core,
        that's all I'm left with.

        12 is ENOMEM.

        ...and since uarea_system_poolpage_alloc() calls
        cpu_uarea_alloc with "true", it panics.  It appears that
        uarea_system_poolpage_alloc() is prepared to deal with a NULL
        return from cpu_uarea_alloc(), though, but on powerpc, it
        appears that cpu_uarea_alloc() will never return NULL, but
        will instead panic if called with system=true and there's a
        memory shortage "somewhere".

        This is different from x86, where the code doesn't check the
        "system" argument, and doesn't panic() inside
        cpu_uarea_alloc().

>How-To-Repeat:
        I'm not sure how repeatable this is...

>Fix:
        Sorry, don't know.