[libvirt] [PATCH 3/3] virCommand: use procfs to learn opened FDs

[Florian Weimer]

* Eric Blake:

> On 7/15/19 12:01 PM, Florian Weimer wrote:
>
>>>>>> glibc supports malloc after multi-threaded fork as an extension (or as
>>>>>> a bug, because it makes malloc not async-signal-safe).
>>>>>
>>>>> It's not a bug for glibc to provide guarantees above what POSIX
>>>>> requires, but IS a bug for applications to depend on those guarantees
>>>>> without realizing they are non-portable.
>>>>
>>>> It's a bug because it makes malloc not async-signal-safe (as required by
>>>> POSIX) in our current implementation of malloc.
>>>
>>> Huh? malloc() is NOT required by POSIX to be async-signal-safe (it is
>>> NOT in the list at
>> 
>> Sorry, I mistyped.  I meant to write fork.  It's on the list.
>
> Ah, that makes much more sense.  In other words, the manner in which
> glibc guarantees that malloc() can be called after fork() is enough to
> simultaneously break the POSIX requirement that fork() can be called
> from a signal handler without risking deadlock (because whatever glibc
> does to make malloc safe after fork is not re-entrant enough if a signal
> handler tries to fork while glibc was already in the middle of preparing
> for fork).

It's taking all the malloc locks, so interrupting malloc is sufficient
to trigger a deadlock with fork.  There are a bunch of other locks as
well, but the malloc locks is the most prominent one.

> Is it worth opening a bug against POSIX to try to strike or reduce the
> requirement that fork() be async-signal safe?  For a single-threaded
> app, fork()ing in a signal handler might have made sense, but as POSIX
> already says:

fork is commonly used in in-process crash handlers.  I suspect this is
in part because it allows one to stop all other threads.  I do not think
this is the proper way to write crash handlers (at least not on Linux),
but it's still very much current practice.  I would certainly welcome a
different requirement from POSIX, but then maybe POSIX does not want to
act as the driver of change on our behalf like this.

Thanks,
Florian