[go: up one dir, main page]

|
|
Log in / Subscribe / Register

Close_range()

Close_range()

Posted May 23, 2019 14:41 UTC (Thu) by dskoll (subscriber, #1630)
Parent article: New system calls: pidfd_open() and close_range()

It would be handy if close_range took another argument of type fd_set * that contained a set of file descriptors you definitely want to keep open. One use case is if a parent process opens a PID file and wants to keep it open in the child / grandchild for locking purposes.

If you don't need this facility, just supply NULL where the fd_set * argument goes.


to post comments

Close_range()

Posted May 23, 2019 15:46 UTC (Thu) by ttuttle (subscriber, #51118) [Link] (3 responses)

Would it be possible to have close_set(fd_set* fds) instead/as well? (Or does that already exist?)

Close_range()

Posted May 23, 2019 17:35 UTC (Thu) by josh (subscriber, #17465) [Link] (2 responses)

close_set wouldn't be *substantially* faster than doing a series of close calls in userspace. It'd eliminate a bit of syscall overhead, but that alone doesn't seem worth it.

The advantage of close_range is that the kernel knows which file descriptors the process has, so instead of userspace closing thousands of *possible* descriptors, the kernel can quickly close the handful of *actual* descriptors.

Close_range()

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

This comes back to the question of "do you have /proc". Userspace can know what fds it has open by looking at /proc/self/fd. This is what rpm, zypper, and quite a few other programs do now (they used to loop over all possible file descriptors but it turns out this can be incredibly slow inside containers).

Close_range()

Posted Jul 24, 2019 22:39 UTC (Wed) by immibis (subscriber, #105511) [Link]

As I recall the problem with reading /proc/self/fd is that now you have to open a FD to know which FDs you can close.

It might be that you're out of file descriptors, so you need to close one in order to open /proc/self/fd in order to know which file descriptors you can close. But how do you know which one to close?

You could institute a rule like "always close the lowest numbered one that we aren't being asked to keep open". But that's not guaranteed to be an open file descriptor. Although FDs are usually small positive integers, they *could* be any positive integer up to 2^31. Will you loop through all descriptors up to 2^31, just so you can find one to close? (Worst case: the FD limit is 1, and the only FD that's open is 2^31-1).

You might need to close more than one FD. IIRC it's possible to open, say, 1000 FDs, and then set the resource limit much lower than 1000, and the process will have to close enough FDs to get under the limit before it can open /proc/self/fd.

There's also the possibility that /proc isn't mounted. It's not sensible that a filesystem should need to be mounted in order for a process to manage its own internal state.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds