diff options
author | Daniel P. Berrangé <berrange@redhat.com> | 2022-05-13 16:49:06 +0100 |
---|---|---|
committer | Thomas Huth <thuth@redhat.com> | 2022-05-18 08:54:22 +0200 |
commit | 6cbde91a27587ca27a3c1979fe7f5f0d28eb6db9 (patch) | |
tree | 04aa0823ded741ff55d6b225095c0972e3505003 /accel | |
parent | 83f79d4efc8dac7e511bc4375d0f9d90ff9db731 (diff) | |
download | qemu-6cbde91a27587ca27a3c1979fe7f5f0d28eb6db9.zip qemu-6cbde91a27587ca27a3c1979fe7f5f0d28eb6db9.tar.gz qemu-6cbde91a27587ca27a3c1979fe7f5f0d28eb6db9.tar.bz2 |
tests/qtest: use prctl(PR_SET_PDEATHSIG) as fallback to kill QEMU
Although we register a ABRT handler to kill off QEMU when g_assert()
triggers, we want an extra safety net. The QEMU process might be
non-functional and thus not have responded to SIGTERM. The test script
might also have crashed with SEGV, in which case the cleanup handlers
won't ever run.
Using the Linux specific prctl(PR_SET_PDEATHSIG) syscall, we
can ensure that QEMU gets sent SIGKILL as soon as the controlling
qtest exits, if nothing else has correctly told it to quit.
Note, technically the death signal is sent when the *thread* that
called fork() exits. IOW, if you are calling qtest_init() in one
thread, letting that thread exit, and then expecting to run
qtest_quit() in a different thread, things are not going to work
out. Fortunately that is not a scenario that exists in qtests,
as pairs of qtest_init and qtest_quit are always called from the
same thread.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Message-Id: <20220513154906.206715-3-berrange@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Thomas Huth <thuth@redhat.com>
Diffstat (limited to 'accel')
0 files changed, 0 insertions, 0 deletions