Re: kern/43452 (sem_close not possible after sem_unlink)

[Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>]

The following reply was made to PR kern/43452; it has been noted by GNATS.

From: Mindaugas Rasiukevicius <rmind%netbsd.org@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: kern-bug-people%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost, pooka%iki.fi@localhost
Subject: Re: kern/43452 (sem_close not possible after sem_unlink)
Date: Tue, 5 Apr 2011 12:31:08 +0100

 > >Number:         43452
 > >Category:       kern
 > >Synopsis:       sem_close not possible after sem_unlink
 > >Confidential:   no
 > >Severity:       non-critical
 > >Priority:       medium
 > >Responsible:    kern-bug-people
 > >State:          open
 > >Class:          sw-bug
 > >Submitter-Id:   net
 > >Arrival-Date:   Thu Jun 10 22:15:00 +0000 2010
 > >Originator:     Antti Kantee
 > >Release:        
 > >Organization:
 > >Environment:
 > >Description:
 > A semaphore for which sem_unlink() is called is supposed to retain
 > resources until sem_close() is called.  However, sem_close() returns
 > EINVAL due to sem_unlink() removing evidence of a named semaphore.
 
 Besides described problem, current semaphore has more issues such as:
 ksem_free() destroying the semaphore before making it invisible;
 ksem_unlink () not checking for permissions; excessive locking (when
 dropping the reference, and heavy RW-lock use), etc.
 
 Here is basically a rewritten POSIX semaphore - using file descriptor,
 quite more simplified, fixing the bugs:
 
 http://www.netbsd.org/~rmind/uipc_sem.diff
 http://www.netbsd.org/~rmind/uipc_sem.c 
 
 However, multiple sem_open(3) calls on the same path return different
 references (file descriptors), which contradicts to POSIX, which has
 unusual requirement here to return the same sem_t address.
 
 -- 
 Mindaugas