[Bug 221700] lang/python??: subprocess does not use closefrom, calls close(2) hundreds of thousands of times

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221700

--- Comment #13 from Conrad Meyer <cem at freebsd.org> ---
(In reply to Ed Maste from comment #10)
@Koobs (re: twitter), why would it not be async signal safe?

In general signal safety is more about interacting with userspace memory state
of ordinary non-signal contexts given arbitrary signal interruption.  I.e.,
classic example is stdio FILE objects, which may be locked or have corrupt,
half-modified state.  closefrom(2) is just a plain system call.

The original commit, r194262, just says:

> Note that this implementation of closefrom(2) does not make any effort to
> resolve userland races with open(2) in other threads.  As such, it is not
> multithread safe.

That is a comment on threading, not signals.  Signaled, single-threaded
programs are still single-threaded; the signal context and ordinary thread
context do not run concurrently.

And by definition, a user process cannot run code of any kind — signal-handler
or ordinary — while that user process is in the kernel.  So closefrom(2) in
signal handler cannot race with open(2) or other syscalls that create fds in
single-threaded programs.

The scenario the comment refers to is something like this:

- The program has two threads and fds 0-5 allocated.
- Concurrently, thread A and B attempt to:
  A: open() a new fd
  B: closefrom(3)
- The behavior is unpredictable and depends on which thread acquires the
fdesctable lock first.

[r194262]: https://svnweb.freebsd.org/base?view=revision&revision=194262

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