From: Jamie Lokier <jamie@shareable.org>
To: Paul Brook <paul@codesourcery.com>
Cc: Michael Casadevall <mcasadevall@ubuntu.com>,
Riku Voipio <riku.voipio@iki.fi>,
Riku Voipio <riku.voipio@nokia.com>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/4] linux-user: add pselect syscall
Date: Sun, 28 Mar 2010 19:49:50 +0100 [thread overview]
Message-ID: <20100328184950.GH3417@shareable.org> (raw)
In-Reply-To: <201003262305.32156.paul@codesourcery.com>
Paul Brook wrote:
> >This patch adds support for the pselect syscall in linux-user emulation
> >and also adds several support functions required to translate the
> >timespec structs between the target and the host.
>
> IIUC the whole point of the pselect is that it should be atomic. By
> emulating this in a non-atomic fasion I think you're re-introducing
> the race condition that it is designed to avoid.
>
> Wouldn't it be better to just return ENOSYS and let the guest deal with the
> problem?
Imho, it's very important to return ENOSYS if the atomic behaviour is
not provided.
The patch actually calls the host's pselect() - it looks almost ok...
But actually, host's pselect() may be Glibc or some other equally
buggy libc, which "emulates" pselect wrongly. FreeBSD's pselect has
the same problem going back years - with a very recent patch to
support it in the kernel. It's not just Glibc.
Careful apps detect and avoid libc's bug by calling the pselect syscall
directly. If it returns ENOSYS, they just use a different (but
slightly slower) race-free technique, or abort - at least they don't
have a quiet corruption bug.
But here we're providing the kernel syscall to guest apps. There's no
way for them to detect if it's really atomic or not. And the ones
written carefully to avoid buggy libc will wrongly use it, because
they think it's a kernel call.
I think it's really important we don't pass on libc's buggy behaviour
to the emulated kernel interface, to even break careful apps.
Solution, Riku: Instead of calling pselect(...), qemu should call
syscall(SYS_pselect, ...), with a comment like:
/*
* Glibc and some other libcs unhelpfully "emulate" pselect()
* using select() when the real system call isn't available, and
* break the atomic guarantee which is the entire point of
* pselect(). To avoid these libc bugs, go straight to the host
* kernel using syscall(). If the host kernel doesn't support
* pselect() it will return ENOSYS, which is what we want to
* return to the guest.
*/
There might need to be some header file included to get syscall() and
SYS_pselect, which sometimes has other names like NR_pselect. And
unfortunately the call arguments aren't quite the same, at least on
Linux.
Same goes for ppoll() if that is ever added.
-- Jamie
prev parent reply other threads:[~2010-03-28 18:49 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-26 15:25 [Qemu-devel] [PATCH 0/4] linux-user patches for upstream Riku Voipio
2010-03-26 15:25 ` [Qemu-devel] [PATCH 1/4] linux-user: add pselect syscall Riku Voipio
2010-03-26 15:25 ` [Qemu-devel] [PATCH 2/4] linux-user: Add the syscall id for pselect6 on ARM Riku Voipio
2010-03-26 15:25 ` [Qemu-devel] [PATCH 3/4] Add inotify_init1 syscall support Riku Voipio
2010-03-26 15:25 ` [Qemu-devel] [PATCH 4/4] fix 0 sized write syscall Riku Voipio
2010-03-26 16:07 ` Richard Henderson
2010-03-26 22:14 ` [Qemu-devel] [PATCH 3/4] Add inotify_init1 syscall support Aurelien Jarno
2010-03-26 22:13 ` [Qemu-devel] [PATCH 2/4] linux-user: Add the syscall id for pselect6 on ARM Aurelien Jarno
2010-03-26 22:15 ` [Qemu-devel] [PATCH 1/4] linux-user: add pselect syscall Aurelien Jarno
2010-03-26 23:05 ` Paul Brook
2010-03-28 18:49 ` Jamie Lokier [this message]
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=20100328184950.GH3417@shareable.org \
--to=jamie@shareable.org \
--cc=mcasadevall@ubuntu.com \
--cc=paul@codesourcery.com \
--cc=qemu-devel@nongnu.org \
--cc=riku.voipio@iki.fi \
--cc=riku.voipio@nokia.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).