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