[Bug libc/10353] Methods for deleting all file descriptors greater than given integer

["adhemerval.zanella at linaro dot org" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=10353

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #8 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
To expand Florian answer, the main issue is that closefrom call is inherent
racy when trying to implement on libc without kernel support. 

The straightforward way to accomplish, and what python does, is to iterate over
all open file descriptors (either by walking through /proc/<pid>/fds or
sysconf(_SC_OPEN_MAX)) and issue a close on the file descriptor.

The problem with this approach does not guarantee on multithread environments
that a file descriptor would not be created in the iteration phase.  One option
would be to serialize a file descriptor creation routine (such as open, openat)
with close; but besides the fact it adds a large complexity and scalability
issue, it does not solve the issue of file descriptors being created by
bypassing the libc (by issuing the syscall instruction directly).

Both OpenBSD and Solaris implements it with syscalls, former with closefrom and
later with fcntl(..., F_CLOSEFROM). Also, Solaris documents its MT-unsafe. 

In fact, IMHO a closefrom syscall won't help much for posix_spawn. Current
implementation for Linux uses a clone(CLONE_VM, CLONE_VFORK) which means that
only the calling thread will be suspended while the helper thread issues
execlpe or _exit.  It means that a file action to issue a closefrom will also
be susceptible to race conditions in multi-thread environments.

That's why posix_spawn_file_actions_addclosefrom_np does not make much sense
unless you implement posix_spawn with fork+exec (which has its own scalability
issues).  The possible solutions are:

 1. Ensure all file descriptors are opened with O_CLOEXEC.

 2. Use a helper process to actually set up the required file descriptor close
steps and issue the target binary. This is in fact what OpenJDK does (check
src/java.base/unix/native/jspawnhelper/jspawnhelper.c and
src/java.base/unix/native/libjava/childproc.c).

So IMHO closefrom would be just a performance optimization on Linux, where
kernel will know exactly which file descriptor to close.

-- 
You are receiving this mail because:
You are on the CC list for the bug.