[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC 2/2] qemu-thread: Don't block SEGV, ILL and FPE

From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [RFC 2/2] qemu-thread: Don't block SEGV, ILL and FPE
Date: Tue, 18 Dec 2018 10:31:33 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

On Mon, Dec 17, 2018 at 11:26:02PM +0300, Roman Bolshakov wrote:
> If any of these signals happen on macOS, they are not delivered to other
> threads and signalfd_compat receives nothing. Indeed, POSIX reference
> and sigprocmask(2) note that an attempt to block the signals results in
> undefined behaviour. SEGV and FPE can't also be received by signalfd(2)
> on Linux.
> An ability to retrieve SIGBUS via signalfd(2) is used by QEMU for
> memory preallocation therefore we can't unblock it without consequences.
> But it's important to leave a remark that the signal is lost on macOS.

Specifically Linux manpage says

   "If SIGBUS, SIGFPE, SIGILL, or SIGSEGV are generated while they
    are blocked, the result is undefined, unless the signal was 
    generated by kill(2), sigqueue(3), or raise(3)."

It appears as if Linux will deliver those signals to a different
thread where they're not blocked, but macOS will simply discard
the signals. Linux behaviour is more helpful, but both are
compliant since behaviour is explicitly undefined.

So really we should not have code that relies on being able to
block any of BUS, FPE, ILL or SEGV.

Allowing FPE, ILL & SEGV looks trivial since nothing in QEMU
tries to handle them, so it'll just trigger the OS default
signal handler which will abort.

As noted code is seeming to rely on catching BUS which is a
problem and I'm not clear how, or even if, we can remove
that and thus unblock the signals.

Copying Paolo, since this unconditional blocking of all signals
was added in

  commit 55541c8afc1a2d75de890c6ee858769d7d605526
  Author: Paolo Bonzini <address@hidden>
  Date:   Thu Jun 3 15:20:32 2010 +0200

    make qemu_thread_create block all signals
    All signals will thus be routed through the IO thread.
    Signed-off-by: Paolo Bonzini <address@hidden>
    Signed-off-by: Anthony Liguori <address@hidden>

> Signed-off-by: Roman Bolshakov <address@hidden>
> ---
>  util/qemu-thread-posix.c | 5 +++++
>  1 file changed, 5 insertions(+)
> diff --git a/util/qemu-thread-posix.c b/util/qemu-thread-posix.c
> index c6934bd22c..1bf5e65dea 100644
> --- a/util/qemu-thread-posix.c
> +++ b/util/qemu-thread-posix.c
> @@ -524,6 +524,11 @@ void qemu_thread_create(QemuThread *thread, const char 
> *name,
>      /* Leave signal handling to the iothread.  */
>      sigfillset(&set);
> +    /* Blocking the signals can result in undefined behaviour. */
> +    sigdelset(&set, SIGSEGV);
> +    sigdelset(&set, SIGFPE);
> +    sigdelset(&set, SIGILL);
> +    /* TODO avoid SIGBUS loss on macOS */
>      pthread_sigmask(SIG_SETMASK, &set, &oldset);

Regardless of what we do with SIGBUS, this addition looks fine to me
on its own so

Reviewed-by: Daniel P. Berrangé <address@hidden>

|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

reply via email to

[Prev in Thread] Current Thread [Next in Thread]