New system calls: pidfd_open() and close_range()

Posted May 23, 2019 23:45 UTC (Thu) by cyphar (subscriber, #110703)
In reply to: New system calls: pidfd_open() and close_range() by rweikusat2
Parent article: New system calls: pidfd_open() and close_range()

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.

to post comments

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).