Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Atomically open files with O_CLOEXEC where possible #27971

Merged
merged 1 commit into from
Aug 25, 2015

Conversation

tbu-
Copy link
Contributor

@tbu- tbu- commented Aug 24, 2015

On Linux the flag is just ignored if it is not supported:
https://lwn.net/Articles/588444/

Still needs the values of O_CLOEXEC on the BSDs.

Touches #24237.

@rust-highfive
Copy link
Collaborator

r? @alexcrichton

(rust_highfive has picked a reviewer for you, use r? to override)

@tbu-
Copy link
Contributor Author

tbu- commented Aug 24, 2015

If someone has access to the BSDs or OS X, I'd be grateful for the values of O_CLOEXEC.

@barosl
Copy link
Contributor

barosl commented Aug 24, 2015

On my OS X (10.10.5), its value is 16777216 (0x1000000).

@barosl
Copy link
Contributor

barosl commented Aug 24, 2015

FreeBSD 10.2: 1048576 (0x100000)
OpenBSD 5.7: 65536 (0x10000)
NetBSD 6.1.5: 4194304 (0x400000)
DragonFly 4.2.4: 131072 (0x20000)
Bitrig 1.0: 65536 (0x10000)

@tbu-
Copy link
Contributor Author

tbu- commented Aug 24, 2015

@barosl Thanks for the constants!

The PR should be ready to merge now.

@alexcrichton
Copy link
Member

Thanks! Can you also add a comment explaining why we even though we pass O_CLOEXEC we still end up calling ioctl with FIOCLEX?

@tbu-
Copy link
Contributor Author

tbu- commented Aug 24, 2015

@alexcrichton Done.

@alexcrichton
Copy link
Member

Thanks! Could you also squash the commits together?

On Linux the flag is just ignored if it is not supported:
https://lwn.net/Articles/588444/

Touches rust-lang#24237.
@tbu-
Copy link
Contributor Author

tbu- commented Aug 24, 2015

@alexcrichton Done.

@tamird
Copy link
Contributor

tamird commented Aug 24, 2015

Does this need a test? it would be good to grab the flags from the fd and assert that CLOEXEC is set (at least on the platforms that have bots).

@tbu-
Copy link
Contributor Author

tbu- commented Aug 24, 2015

If this needs a test, where do we put those IO tests?

@alexcrichton
Copy link
Member

@bors: r+ 6de7f60

We already have tests for CLOEXEC and it'd be very difficult to test this otherwise because we'd have to not call set_cloexec. Along those lines if this passes the bots and makes snapshots I'm happy with it.

@@ -269,6 +269,9 @@ impl File {
libc::open(path.as_ptr(), flags, opts.mode)
}));
let fd = FileDesc::new(fd);
// Even though we open with the O_CLOEXEC flag, still set CLOEXEC here,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hm, since @alexcrichton pointed out that there are tests for this, would it be appropriate to add [cfg(not(any(target_os = "freebsd", target_os = "dragonfly", ...)))]? perhaps pedantic, but it would assert that constants added here are correct

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In some cases an older version of any OS might not implement atomic option even if the constant is correct.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, thought of this and forgot to comment. Carry on :(

bors added a commit that referenced this pull request Aug 25, 2015
On Linux the flag is just ignored if it is not supported:
https://lwn.net/Articles/588444/

Still needs the values of O_CLOEXEC on the BSDs.

Touches #24237.
@bors
Copy link
Contributor

bors commented Aug 25, 2015

⌛ Testing commit 6de7f60 with merge e195aa8...

@bors bors merged commit 6de7f60 into rust-lang:master Aug 25, 2015
bors added a commit that referenced this pull request Feb 6, 2016
These commits finish up closing out #24237 by filling out all locations we create new file descriptors with variants that atomically create the file descriptor and set CLOEXEC where possible. Previous support for doing this in `File::open` was added in #27971 and support for `try_clone` was added in #27980. This commit fills out:

* `Socket::new` now passes `SOCK_CLOEXEC`
* `Socket::accept` now uses `accept4`
* `pipe2` is used instead of `pipe`

Unfortunately most of this support is Linux-specific, and most of it is post-2.6.18 (our oldest supported version), so all of the detection here is done dynamically. It looks like OSX does not have equivalent variants for these functions, so there's nothing more we can do there. Support for BSDs can be added over time if they also have these functions.

Closes #24237
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants