kern/175674: sem_open() should use O_EXLOCK with open() instead of a separate flock() call
Jilles Tjoelker
jilles at stack.nl
Tue Feb 12 00:00:02 UTC 2013
The following reply was made to PR kern/175674; it has been noted by GNATS.
From: Jilles Tjoelker <jilles at stack.nl>
To: Giorgos Keramidas <keramida at FreeBSD.org>
Cc: Jukka Ukkonen <jau at iki.fi>, freebsd-gnats-submit at FreeBSD.org,
davidxu at 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 at 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
More information about the freebsd-bugs
mailing list