kern/162374: posix_openpt wrongly removed O_CLOEXEC
jilles at stack.nl
Wed Mar 20 23:50:02 UTC 2013
The following reply was made to PR kern/162374; it has been noted by GNATS.
From: Jilles Tjoelker <jilles at stack.nl>
To: bug-followup at FreeBSD.org, naruse at airemix.jp, ed at FreeBSD.org
Subject: Re: kern/162374: posix_openpt wrongly removed O_CLOEXEC
Date: Thu, 21 Mar 2013 00:42:48 +0100
> [posix_openpt(O_RDWR | O_NOCTTY | O_CLOEXEC) fails with [EINVAL]]
While looking at all the atomic close-on-exec changes in
http://austingroupbugs.net/view.php?id=411, I found this PR. It seems to
make sense to allow O_CLOEXEC in posix_openpt(), so that this way of
creating a new file descriptor can also create it atomically
The O_CLOEXEC flag does not seem to have been "removed" as it was never
present in the first place (even stable/7's userland implementation
gives [EINVAL] for anything but O_RDWR and O_NOCTTY).
Ed, what do you think of this patch?
--- sys/kern/tty_pts.c (revision 248561)
+++ sys/kern/tty_pts.c (working copy)
@@ -825,10 +825,10 @@
* POSIX states it's unspecified when other flags are passed. We
* don't allow this.
- if (uap->flags & ~(O_RDWR|O_NOCTTY))
+ if (uap->flags & ~(O_RDWR|O_NOCTTY|O_CLOEXEC))
- error = falloc(td, &fp, &fd, 0);
+ error = falloc(td, &fp, &fd, uap->flags);
--- lib/libc/sys/posix_openpt.2 (revision 248561)
+++ lib/libc/sys/posix_openpt.2 (working copy)
@@ -71,7 +71,7 @@
are constructed by a bitwise-inclusive OR of flags from the following
list, defined in
.In fcntl.h :
-.Bl -tag -width ".Dv O_NOCTTY"
+.Bl -tag -width ".Dv O_CLOEXEC"
.It Dv O_RDWR
Open for reading and writing.
.It Dv O_NOCTTY
@@ -79,6 +79,8 @@
shall not cause the terminal device to become the controlling terminal
for the process.
+.It Dv O_CLOEXEC
+Set the close-on-exec flag for the new file descriptor.
More information about the freebsd-bugs