Re: sem_init: pshared=0 difference between Linux and NetBSD

[Greg Troxel <gdt%lexort.com@localhost>]

Thomas Klausner <wiz%netbsd.org@localhost> writes:

> 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"?

As the bumper sticker says: What Would Posix Say?

  https://pubs.opengroup.org/onlinepubs/9799919799/functions/sem_init.html

    The sem_init() function shall initialize the unnamed semaphore
    referred to by sem. The value of the initialized semaphore shall be
    value. Following a successful call to sem_init(), the semaphore can be
    used in subsequent calls to sem_clockwait(), sem_destroy(),
    sem_post(), sem_timedwait(), sem_trywait(), and sem_wait(). This
    semaphore shall remain usable until the semaphore is destroyed. An
    unnamed semaphore may be implemented using a file descriptor.

    If the pshared argument has a non-zero value, then the semaphore is
    shared between processes; in this case, any process that can access
    the semaphore sem can use sem for performing sem_clockwait(),
    sem_destroy(), sem_post(), sem_timedwait(), sem_trywait(), and
    sem_wait() operations.

    If the pshared argument is zero, then the semaphore is shared between
    threads of the process; any thread in this process can use sem for
    performing sem_clockwait(), sem_destroy(), sem_post(),
    sem_timedwait(), sem_trywait(), and sem_wait() operations.

That text doesn't strictly say that with pshared=0 that cross-process
accesses are blocked, but I'd say it is implied strongly enough to be
the only reasonable interpretation, to the point that I'd expect Austin
Group to reject a clarification as unnecessary.  I see "is shared
between the threads of a process" to exclude other sharing.

I think the NetBSD behavior is a bug.