Re: kern/175674: sem_open() should use O_EXLOCK with open() inst

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

From: Jilles Tjoelker <jilles@stack.nl>
To: Giorgos Keramidas <keramida@FreeBSD.org>
Cc: Jukka Ukkonen <jau@iki.fi>, freebsd-gnats-submit@FreeBSD.org,
	davidxu@FreeBSD.org
Subject: Re: kern/175674: sem_open() should use O_EXLOCK with open() instead
 of a separate flock() call
Date: Tue, 12 Feb 2013 00:56:42 +0100

 On Sun, Feb 03, 2013 at 09:49:55PM +0100, Giorgos Keramidas wrote:
 > On 2013-02-03 21:20, Jilles Tjoelker <jilles@stack.nl> wrote:
 > > For a reason unknown to me, open(2) does not restart but always
 > > returns [EINTR] when a signal is caught. This is not POSIX-compliant.
 > > On the other hand, flock(2) is not broken in this way. So this change
 > > breaks sem_open(3) in the unlikely case that a signal with SA_RESTART
 > > arrives while it is waiting for the lock.

 > I see where kern_openat() returns an error when vn_open is interrupted:

 > 1083         error = vn_open(&nd, &flags, cmode, fp);
 > 1084         if (error) {
 > ....
 > 1109                 if (error == ERESTART)
 > 1110                         error = EINTR;
 > 1111                 goto bad;
 > 1112         }

 > > The best way to fix this is in kern_openat() in the kernel but this
 > > might cause compatibility issues.

 > Not sure if there would be serious compatibility problems if open()
 > would automatically restart instead of returning EINTR.  It definitely
 > seems a rather intrusive change though.

 As of r246472, open() is now sufficiently fixed that O_EXLOCK can be
 used.

 Although it is not a problem if a different thread than the file creator
 initializes the semaphore, the change reduces system calls and code
 size.

 On another note, the flock(fd, LOCK_UN) calls can go away because they
 are implicit in the close(fd).

 -- 
 Jilles Tjoelker
_______________________________________________
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org"