Code change:
// However, since this is a variadic function, C integer promotion rules mean that on // the ABI level, this still gets passed as `c_int` (aka `u32` on Unix platforms). let fd = cvt_r(|| unsafe { open64(path.as_ptr(), flags, opts.mode as c_int) })?; <del> let fd = FileDesc::new(fd); // Currently the standard library supports Linux 2.6.18 which did not // have the O_CLOEXEC flag (passed above). If we're running on an older // Linux kernel then the flag is just ignored by the OS. After we open // the first file, we check whether it has CLOEXEC set. If it doesn't, // we will explicitly ask for a CLOEXEC fd for every further file we // open, if it does, we will skip that step. // // The CLOEXEC flag, however, is supported on versions of macOS/BSD/etc // that we support, so we only do this on Linux currently. #[cfg(target_os = "linux")] fn ensure_cloexec(fd: &FileDesc) -> io::Result<()> { use crate::sync::atomic::{AtomicUsize, Ordering}; const OPEN_CLOEXEC_UNKNOWN: usize = 0; const OPEN_CLOEXEC_SUPPORTED: usize = 1; const OPEN_CLOEXEC_NOTSUPPORTED: usize = 2; static OPEN_CLOEXEC: AtomicUsize = AtomicUsize::new(OPEN_CLOEXEC_UNKNOWN); let need_to_set; match OPEN_CLOEXEC.load(Ordering::Relaxed) { OPEN_CLOEXEC_UNKNOWN => { need_to_set = !fd.get_cloexec()?; OPEN_CLOEXEC.store( if need_to_set { OPEN_CLOEXEC_NOTSUPPORTED } else { OPEN_CLOEXEC_SUPPORTED }, Ordering::Relaxed, ); } OPEN_CLOEXEC_SUPPORTED => need_to_set = false, OPEN_CLOEXEC_NOTSUPPORTED => need_to_set = true, _ => unreachable!(), } if need_to_set { fd.set_cloexec()?; } Ok(()) } #[cfg(not(target_os = "linux"))] fn ensure_cloexec(_: &FileDesc) -> io::Result<()> { Ok(()) } ensure_cloexec(&fd)?; Ok(File(fd)) </del> <ins> Ok(File(FileDesc::new(fd))) </ins> } pub fn file_attr(&self) -> io::Result<FileAttr> {

Related discussion:
text: Good question! There are 6 workarounds in for older Linux versions (that I could find). Increasing the minimum version to 2.6.32 (aka 3rd Kernel LTS, aka RHEL 6) would fix 5 of them. Code links are inline: uses the flag with  (mentioned above, in 2.6.23) uses with  ( in 2.6.24, there is also the mention of a bug occuring on "some linux kernel at some point") uses  to atomically set the flag on the pipe fds ( in 2.6.27) uses with  ( in 2.6.27) uses  to permit use of ( in 2.6.28) ~ ( in 4.5, not fixed by this proposal)~ As you can see, the workarounds fixed by this proposal all have a similar flavor. Originally posted by in
Kernel updated in .
As noted, needs a much newer kernel 4.5, so we'll still need that fallback. But all the stuff should be ok to assume available now.
The new minimal version is 2.6.27 from what I can see, so "Socket::accept uses accept4(2) to permit use of SOCK_CLOEXEC" still needs a fallback, right?
The builder is using 2.6.32 headers, so I would call that our new minimum.
Ah right; I am actually not sure where I got the 27 from...
The title of suggested 2.6.27, but we went a little higher to match the actual distros in use.
I know this is ancient history, but do you recall the problem with ? You introduced that comment about "some kernel" in , and you were the last to update it in . If the problem kernels were before 2.6.32, then I'd like to clean that up now.
Just digging in kernel history, I did find one hiccup in , but that bug was introduced and resolved during the 3.7 development cycle, not in a release.
IIRC we just mirrored what musl did at the time, which looks like it : Looks like the original mailing list thread is gone and there's no comments in the musl source, and I don't recall what happened here. I suspect it would be safe to remove those workarounds and just assume works one the first try until someone says differently.