sem_init: pshared=0 difference between Linux and NetBSD

[Thomas Klausner <wiz%netbsd.org@localhost>]

Hi!

There is a locking problem in the latest gnupg, and upstream debugged
this and found a difference in the semantics of sem_init() on NetBSD
and Linux.

Linux documents the pshared  parameter of sem_init() as follows:

https://www.man7.org/linux/man-pages/man3/sem_init.3.html

       The pshared argument indicates whether this semaphore is to be
       shared between the threads of a process, or between processes.

       If pshared has the value 0, then the semaphore is shared between
       the threads of a process, and should be located at some address
       that is visible to all threads (e.g., a global variable, or a
       variable allocated dynamically on the heap).

       If pshared is nonzero, then the semaphore is shared between
       processes, and should be located in a region of shared memory (see
       shm_open(3), mmap(2), and shmget(2)).  (Since a child created by
       fork(2) inherits its parent's memory mappings, it can also access
       the semaphore.)  Any process that can access the shared memory
       region can operate on the semaphore using sem_post(3),
       sem_wait(3), and so on.

While the NetBSD man page says:

https://man.netbsd.org/sem_init.3

     The sem_init() function initializes the unnamed semaphore pointed to by
     sem to have the value value.  A non-zero value for pshared specifies a
     shared semaphore that can be used by multiple processes.

Upstream found that even when pshared=0, the POSIX semaphore on NetBSD
is shared among processes (i.e. across fork).

https://dev.gnupg.org/rE20c673e15bd772ee39f626f8203427b5f47601b7

Is this a bug in the NetBSD implementation, or are we just in the
undefined space of the specification and it's an "implementation
difference"?

Cheers,
 Thomas