Re: [Qemu-devel] [PATCH] linux-user: add ppoll syscall support

2011-01-23 Thread Peter Maydell
On 23 January 2011 19:56, Mike Frysinger vap...@gentoo.org wrote:
 Some architectures (like Blackfin) only implement ppoll (and skip poll).
 So add support for it using existing poll code.

This looks wrong -- ppoll() is supposed to be atomic, but
your implementation isn't. Why can't we just implement this
by calling the host ppoll? (might need a configure test, but
that's straightforward.)

-- PMM



Re: [Qemu-devel] [PATCH] linux-user: add ppoll syscall support

2011-01-23 Thread Mike Frysinger
On Sun, Jan 23, 2011 at 16:25, Peter Maydell wrote:
 On 23 January 2011 19:56, Mike Frysinger wrote:
 Some architectures (like Blackfin) only implement ppoll (and skip poll).
 So add support for it using existing poll code.

 This looks wrong -- ppoll() is supposed to be atomic, but
 your implementation isn't. Why can't we just implement this
 by calling the host ppoll? (might need a configure test, but
 that's straightforward.)

it's atomic from the apps' point of view, so what does it matter ?
-mike



Re: [Qemu-devel] [PATCH] linux-user: add ppoll syscall support

2011-01-23 Thread Peter Maydell
On 23 January 2011 21:35, Mike Frysinger vap...@gentoo.org wrote:
 On Sun, Jan 23, 2011 at 16:25, Peter Maydell wrote:
 This looks wrong -- ppoll() is supposed to be atomic, but
 your implementation isn't. Why can't we just implement this
 by calling the host ppoll? (might need a configure test, but
 that's straightforward.)

 it's atomic from the apps' point of view, so what does it matter ?

It's not atomic because signals can arrive in the gaps
between your calls to sigaction and poll (even if qemu doesn't
deliver them to the guest until we're done). ppoll() is supposed
to return EINTR if interrupted by a signal, but if a signal arrives
before you call poll() then you won't notice it so you won't
return, and the app might hang.

Looks like this same issue came up with a proposed pselect
patch last year:
http://www.mail-archive.com/qemu-devel@nongnu.org/msg28339.html
(together with some remarks about it being better not to
trust buggy libcs and go straight for the host syscall.)

-- PMM



Re: [Qemu-devel] [PATCH] linux-user: add ppoll syscall support

2011-01-23 Thread Mike Frysinger
On Sun, Jan 23, 2011 at 17:35, Peter Maydell wrote:
 On 23 January 2011 21:35, Mike Frysinger wrote:
 On Sun, Jan 23, 2011 at 16:25, Peter Maydell wrote:
 This looks wrong -- ppoll() is supposed to be atomic, but
 your implementation isn't. Why can't we just implement this
 by calling the host ppoll? (might need a configure test, but
 that's straightforward.)

 it's atomic from the apps' point of view, so what does it matter ?

 It's not atomic because signals can arrive in the gaps
 between your calls to sigaction and poll (even if qemu doesn't
 deliver them to the guest until we're done). ppoll() is supposed
 to return EINTR if interrupted by a signal, but if a signal arrives
 before you call poll() then you won't notice it so you won't
 return, and the app might hang.

i know how host signals work, but my limited understanding of how qemu
works is that its guest signal handling would make this a non-issue.
if that isnt the case, then i can trivially convert it to ppoll.

 Looks like this same issue came up with a proposed pselect
 patch last year:
 http://www.mail-archive.com/qemu-devel@nongnu.org/msg28339.html
 (together with some remarks about it being better not to
 trust buggy libcs and go straight for the host syscall.)

i also need pselect, and i have a local patch to support it (the same
way i've implemented ppoll).  returning ENOSYS is unacceptable as it
assumes the port in question can fall back to another select variant.
but if the arch *only* supports pselect6, then there is nothing to
fall back to if select/newselect are not supported by the arch.
-mike