New system calls: pidfd_open() and close_range()

Posted May 23, 2019 20:31 UTC (Thu) by quotemstr (subscriber, #45331)
Parent article: New system calls: pidfd_open() and close_range()

Those longstanding unix conventions are terrible. Al is simply wrong here to fight to preserve them. O_CLOEXEC really is the right approach. This debate was settled a long time ago, when most system calls got O_CLOEXEC options. Let's not reopen it for pointless reasons.

to post comments

New system calls: pidfd_open() and close_range()

Posted May 23, 2019 20:57 UTC (Thu) by rweikusat2 (subscriber, #117920) [Link] (3 responses)

The reason for O_CLOEXEC options is that this flag needs to be set atomically if the process doing the open is multithreaded to prevent accidental inheritance of a file descriptor because another thread initiated a fork/exec after the open returned and before a fcntl calls setting FD_CLOEXEC was made.

Apart from that, there's no "wrong" and no "right" approach here. There are two choices for a default policy, namely inheritable or not inheritable, and which is better for a certain application depends on what the application is trying to do. Making the default policy a configurable per-process setting would probably make sense. Different default policies depending on whatever the person who implemented the syscall perferred for whatever reason just make the system more complicated without any benefit.

New system calls: pidfd_open() and close_range()

Posted May 23, 2019 23:45 UTC (Thu) by cyphar (subscriber, #110703) [Link] (2 responses)

Right, but the point is that you can always disable O_CLOEXEC safely through fnctl(2) but you cannot safely enable it. So really, making O_CLOEXEC the default seems to have no real downside other than inconsistencies with existing syscalls -- but open(2) is already inconsistent with almost every other syscall by ignoring unknown flags instead of giving -EINVAL.

New system calls: pidfd_open() and close_range()

Posted May 24, 2019 12:59 UTC (Fri) by rweikusat2 (subscriber, #117920) [Link] (1 responses)

These are three grammatically connected but unrelated statements.

The O_CLOEXEC file descriptor creation flag doesn't belong into this discussion.

The default policy for existing system calls is mandated by POSIX, hence, changing that is not an option. Different default policies for different system calls are still a bad idea as they make the system more difficult to program for no real benefit. A default policy which could be changed on a per-process basis could be a good idea. OTOH, file descriptor creation is a fairly rare occurence, hence, this might also not be worth the effort. But it would at least solve a problem and not create one.

That some aspects of open are different from every other system call is unsurprising. If this wasn't the case, an open syscall wouldn't exist.

New system calls: pidfd_open() and close_range()

Posted May 24, 2019 13:35 UTC (Fri) by cyphar (subscriber, #110703) [Link]

I guess we have different opinions on what APIs make the most sense. I agree that it does result in inconsistencies, though I disagree this makes systems significantly harder to program.

> That some aspects of open are different from every other system call is unsurprising. If this wasn't the case, an open syscall wouldn't exist.

I don't understand what you mean by this. open(2) is a syscall that must exist for reasons that should be abundantly obvious. However, the fact that open("foo", 0xFFFFFFFFFFFFFFFF, 0) works today -- despite many of those bits being undefined -- is not required for open(2) to exist. This is known as a bad practice -- no other syscall operates like this (and the kernel documentation explicitly tells you not to design syscalls or ioctls like this).