From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Roman Bolshakov <r.bolshakov@yadro.com>,
Paolo Bonzini <pbonzini@redhat.com>
Cc: qemu-devel@nongnu.org
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 [thread overview]
Message-ID: <20181218103133.GB22638@redhat.com> (raw)
In-Reply-To: <20181217202602.31113-3-r.bolshakov@yadro.com>
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 <pbonzini@redhat.com>
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 <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
>
> Signed-off-by: Roman Bolshakov <r.bolshakov@yadro.com>
> ---
> 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é <berrange@redhat.com>
Regards,
Daniel
--
|: 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 :|
next prev parent reply other threads:[~2018-12-18 10:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-17 20:26 [Qemu-devel] [RFC 0/2] Improve qemu-thread support on macOS Roman Bolshakov
2018-12-17 20:26 ` [Qemu-devel] [RFC 1/2] util: Implement debug-threads for macOS Roman Bolshakov
2018-12-18 10:25 ` Daniel P. Berrangé
2018-12-17 20:26 ` [Qemu-devel] [RFC 2/2] qemu-thread: Don't block SEGV, ILL and FPE Roman Bolshakov
2018-12-18 10:31 ` Daniel P. Berrangé [this message]
2019-01-08 14:53 ` [Qemu-devel] [RFC 0/2] Improve qemu-thread support on macOS Peter Maydell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181218103133.GB22638@redhat.com \
--to=berrange@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=r.bolshakov@yadro.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).