kern/47069: posix_spawn/t_spawnattr locks up the system

[julio+host-mini-jmmv%meroh.net@localhost]

>Number:         47069
>Category:       kern
>Synopsis:       posix_spawn/t_spawnattr locks up the system
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Oct 13 20:40:00 +0000 2012
>Originator:     julio+host-mini-jmmv%meroh.net@localhost
>Release:        NetBSD 6.99.12 -- Sources as of 20121013.
>Organization:
        
>Environment:
        
        
System: NetBSD mini.meroh.net 6.99.12 NetBSD 6.99.12 (MINI) #32: Sat Oct 13 
00:10:52 EDT 2012 
sysbuild%netbsd.meroh.net@localhost:/home/sysbuild/macppc/obj/home/sysbuild/src/sys/arch/macppc/compile/MINI
 macppc
Architecture: powerpc
Machine: macppc
>Description:
        The lib/libc/gen/posix_spawn/t_spawnattr test program locks my
        -current macppc machine consistently.  Whenever I run this test,
        the t_spawnattr process ends up being listed as state STOP in
        top.  At that time, the system "appears" up in the sense that I
        can continue to use everything that is running (X remains up,
        top gets updated with new data, the machine responds to network
        connections...).  However, attempts to run any new program result
        in "stuckness" of the caller program.

        At first, I thought that access to the disk was being locked, but
        I now think that the problem is that the process table is left
        locked for some reason and thus no new processes can be started.

        Upon inspecting the implementation of posix_spawn, I *suspect* the
        following: the STOP state means that posix_spawn never completed
        correctly, because one of the first things the function does is
        transition the process to STOPped while it's being set up.
        Therefore, I'm guessing that there might be some locking issue with
        the process table.  Note that t_spawn works well, so I'm further
        guessing that this is related to the attributes manipulation.

        Lastly, I'm filing this as "kern" rather than "port-macppc" because
        I don't see any obvious MD code in the syscall.  However, it's
        possible that this is still macppc-specific for some reason, in
        which case this should be reclassified.
>How-To-Repeat:
        On a macppc machine running current:

        # cd /usr/tests/lib/libc/gen/posix_spawn
        # atf-run t_spawnattr

        Witness a machine lockup.
>Fix:
        

>Unformatted: