Re: pthread_atfork and locks

[Taylor R Campbell <campbell+netbsd-tech-userlevel%mumble.net@localhost>]

[FYI, in case it's not clear, in this thread when I have talked about
reinitializing or unlocking a mutex in the child, I assume that the
mutex was already locked by the forking thread in a pthread_atfork
prepare handler.  I'm not interested in messing with a mutex that
could have been held by just anyone in the parent.]

   Date: Mon, 23 Jun 2014 16:35:56 -0400
   From: Greg Troxel <gdt%ir.bbn.com@localhost>

   There is _malloc_prefork() which gets the lock.  I am not sure how
   that's hooked in, but I remember someone (Christos) adding this from FreeBSD.

Evidently it's not hooked in -- PR 47428 is still open.

   If the forking thread has the mutex, then the idea that some other
   thread would be trying and somehow causing trouble doesn't make sense.

Suppose mutex_lock looked like this:

void
mutex_lock(struct mutex *m)
{

        spin_lock(&m->mtx_spin);
        /* (*) */
        while (m->mtx_owner)
                cv_wait(&m->mtx_cv, &m->mtx_spin);
        m->mtx_owner = curthread();
        spin_unlock(&m->mtx_spin);
}

If the actual kernel-level fork happens at the time of (*), then even
if the thread calling fork() owns the mutex, the mutex's internal spin
lock would be held by a nonexistent thread in the child.  So if the
child ever tried to unlock the mutex, or do anything requiring taking
the internal spin lock, it would hang.

mutex_lock doesn't look like that, however.  My cursory analysis of
our actual mutex code suggests calling mutex_unlock in the child
should be safe, assuming the thread that forked in the parent held the
lock in the first place.  But I'm not sure, and pthread_atfork(3) man
page says pthread_* is unsafe in the child with no exception for
pthread_mutex_unlock, hence my inquiry to the list.

   > As far as I can tell, the intent in POSIX is that you should be able
   > to pthread_atfork(/*prepare*/lock, /*parent*/unlock, /*child*/unlock).
   > But I'm not confident we guarantee that to work in NetBSD, and we
   > ought to.

   I would think that is safe, just based on the implementation.   Do you
   find that it isn't?

rmind@ was sceptical when I asked him, but I couldn't find any way
that it could go wrong.