Re: [Qemu-devel] [PATCH v3 0/2] Produce better termination message

[Michal Privoznik <mprivozn@redhat.com>]

On 22.09.2016 18:43, Paolo Bonzini wrote:
> 
> 
> On 21/09/2016 18:27, Michal Privoznik wrote:
>> This is v2 of:
>> http://lists.nongnu.org/archive/html/qemu-devel/2016-09/msg05058.html
>>
>> Diff to v2:
>> - In 1/2 I've dropped stdio funcs in favour of g_file_get_contents() (thanks Dan!)
>>
>> Michal Privoznik (2):
>>   util: Introduce qemu_get_pid_name
>>   qemu_kill_report: Report PID name too
>>
>>  include/qemu/osdep.h | 10 ++++++++++
>>  util/oslib-posix.c   | 27 +++++++++++++++++++++++++++
>>  util/oslib-win32.c   |  7 +++++++
>>  vl.c                 |  8 ++++++--
>>  4 files changed, 50 insertions(+), 2 deletions(-)
>>
> 
> Patch 2/2 breaks "make check".  You cannot call malloc from a signal
> handler, and this shows as a deadlock in
> /x86_64/virtio/scsi/pci/hotplug.  You have to use the large buffer,
> _but_ I cannot just keep patch 2 because you also have to use
> open/read/close instead of stdio.

Huh, this has beacame more hairy than I initially thought. An
alternative suggestion might be to not call PID->name translate function
from the signal handler, but call it just from the qemu_kill_report().
Yes, this will increase the chances of reporting incorrect process name,
but there's no way to make this 100% correct. I mean even at the time
that our signal callback is ran, the sender might be dead already and
kernel might have spawn a different process under the same PID.
Therefore I guess there's no real harm in doing the translation later.
Moreover, if we want this to work on *BSD-s (where an libutil function
is called which does malloc), then we must call the translate function
from a safe place. On the other hand, malloc there could be reentrant.

Michal