Clean up some workarounds after upgrading minimum kernel version

[tesuji]

Besides O_CLOEXEC, which other things would we be able to clean up?

Good question! There are 6 workarounds in libstd 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:

• File::open_c uses the O_CLOEXEC flag with open(2) (mentioned above, added in 2.6.23)
• FileDesc::duplicate uses F_DUPFD_CLOEXEC with fcntl(2) (added in 2.6.24, there is also the mention of a bug occuring on "some linux kernel at some point")
• pipe::anon_pipe uses pipe2(2) to atomically set the O_CLOEXEC flag on the pipe fds (added in 2.6.27)
• Socket::new_raw uses SOCK_CLOEXEC with socket(2) (added in 2.6.27)
• Socket::accept uses accept4(2) to permit use of SOCK_CLOEXEC (added in 2.6.28)
• fs::copy uses copy_file_range(2) (added 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 @josephlr in #62516 (comment)

[tesuji]

Kernel updated in #74163 .

[cuviper]

As noted, copy_file_range needs a much newer kernel 4.5, so we'll still need that fallback. But all the CLOEXEC stuff should be ok to assume available now.

[RalfJung]

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?

[cuviper]

The builder is using 2.6.32 headers, so I would call that our new minimum.

[RalfJung]

Ah right; I am actually not sure where I got the 27 from...

[cuviper]

The title of #62516 suggested 2.6.27, but we went a little higher to match the actual distros in use.

[cuviper]

@alexcrichton I know this is ancient history, but do you recall the problem with F_DUPFD_CLOEXEC? You introduced that comment about "some kernel" in 3d28b8b, and you were the last to update it in 0fff73b. If the problem kernels were before 2.6.32, then I'd like to clean that up now.

[cuviper]

Just digging in kernel history, I did find one hiccup in torvalds/linux@1219771, but that bug was introduced and resolved during the 3.7 development cycle, not in a release.

[alexcrichton]

IIRC we just mirrored what musl did at the time, which looks like it still does:

		int ret = __syscall(SYS_fcntl, fd, F_DUPFD_CLOEXEC, arg);
		if (ret != -EINVAL) {
			if (ret >= 0)
				__syscall(SYS_fcntl, ret, F_SETFD, FD_CLOEXEC);
			return __syscall_ret(ret);
		}

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 F_DUPFD_CLOEXEC works one the first try until someone says differently.