lib/59237: postfork mutex audit: mutex_init, not mutex_unlock

[campbell+netbsd%mumble.net@localhost]

>Number:         59237
>Category:       lib
>Synopsis:       postfork mutex audit: mutex_init, not mutex_unlock
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Mar 30 23:15:00 +0000 2025
>Originator:     Taylor R Campbell
>Release:        current, 10, 9, ...
>Organization:
The NetBSD Postforkation Lock
>Environment:
>Description:
Various pthread_atfork handlers use the following idiom:

prefork: mutex_lock(something)
postfork_parent: mutex_unlock(something)
postfork_child: mutex_unlock(something)

The mutex_unlock in the child is incorrect and may lead to hangs, crashes, or boogervorous demons.  Suppose this happens:

thread 1                thread 2
--------                --------
fork() library routine
   prefork
      mutex_lock(&lock)
                        mutex_lock(&lock) queues self for lock
   real fork syscall

When the process is actually forked via the real fork syscall, thread 2 may hold the internal spin lock or have itself on the internal queue.  So when the postfork_child handler runs, it will find a mutex in an inconsistent _internal_ state.
>How-To-Repeat:
code inspection
probably testable with a lot of patience for someone to win a race
>Fix:
Change postfork_child handlers to use mutex_init, not mutex_unlock -- that will clear any state potentially held by other threads, which don't exist in the child anyway, so there's nothing to be lost by forgetting about them.