From: Riku Voipio <riku.voipio@iki.fi>
To: qemu-devel@nongnu.org
Cc: kirill@shutemov.name
Subject: Re: [Qemu-devel] [PATCH 04/10] fix IPCOP_sem* and implement sem*
Date: Mon, 6 Apr 2009 18:17:47 +0300 [thread overview]
Message-ID: <20090406151747.GA9881@kos.to> (raw)
In-Reply-To: <87ljqei229.fsf@lechat.rtp-net.org>
On Mon, Apr 06, 2009 at 11:06:22AM +0200, Arnaud Patard wrote:
> riku.voipio@iki.fi writes:
>
> Hi,
>
> > -static inline abi_long do_semctl(int first, int second, int third,
> > - abi_long ptr)
> > +static inline abi_long do_semctl(int semid, int semnum, int cmd,
> > + union target_semun target_su)
> > {
> > union semun arg;
> > struct semid_ds dsarg;
> > - int cmd = third&0xff;
> > - abi_long ret = 0;
> > + unsigned short *array;
> > + struct seminfo seminfo;
> > + abi_long ret = -TARGET_EINVAL;
> > + abi_long err;
> > + cmd &= 0xff;
> >
> > switch( cmd ) {
> I'm wondering if it's a good way of handling the IPC_64 flag. afaik this
> flag is set to indicate that we're using newer ipc version, so if it's
> set, the code may use things like 32bit uids.
> Taking this into account, is it possible that falling back to the old
> *ctl versions is breaking some applications ?
As far as I see the patch doesn't change qemu's behaviour in this respect?
I didn't see any failures in ltp testing with amd64/i386 hosts and arm
arm target. Would some other target/host combination be more suspectible
from errors of this behaviour? when running qemu-arm under i386, glibc
appears to add the IPC_64 flag when qemu is calling sem* functions.
--
"rm -rf" only sounds scary if you don't have backups
next prev parent reply other threads:[~2009-04-06 15:17 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-05 20:59 [Qemu-devel] [PATCH 00/10] misc userland patches [v2] riku.voipio
2009-04-05 20:59 ` [Qemu-devel] [PATCH 01/10] Fix fstatat64()/newfstatat() syscall implementation riku.voipio
2009-04-05 20:59 ` [Qemu-devel] [PATCH 02/10] Rewrite mmap_find_vma() to work fine on 64-bit hosts with 32-bit targets riku.voipio
2009-04-05 20:59 ` [Qemu-devel] [PATCH 03/10] Implement shm* syscalls and fix 64/32bit errors riku.voipio
2009-04-15 16:21 ` [Qemu-devel] [PATCH 02/10] Rewrite mmap_find_vma() to work fine on 64-bit hosts with 32-bit targets Aurelien Jarno
2009-04-05 20:59 ` [Qemu-devel] [PATCH 04/10] fix IPCOP_sem* and implement sem* riku.voipio
2009-04-06 9:06 ` Arnaud Patard
2009-04-06 15:17 ` Riku Voipio [this message]
2009-04-06 16:22 ` Arnaud Patard
2009-04-15 15:28 ` Aurelien Jarno
2009-04-16 14:23 ` Riku Voipio
2009-04-18 16:16 ` Aurelien Jarno
2009-04-05 20:59 ` [Qemu-devel] [PATCH 05/10] Added posix message queue syscalls except mq_notify riku.voipio
2009-04-15 16:13 ` Aurelien Jarno
2009-04-05 20:59 ` [Qemu-devel] [PATCH 06/10] Add support for passing contents of argv0 riku.voipio
2009-04-15 16:13 ` Aurelien Jarno
2009-04-05 20:59 ` [Qemu-devel] [PATCH 07/10] linux-user: unix sockets - fix running dbus riku.voipio
2009-04-15 16:14 ` Aurelien Jarno
2009-04-05 20:59 ` [Qemu-devel] [PATCH 08/10] linux-user: removed unnecessary MAX_SOCK_ADDR checks for socket syscalls riku.voipio
2009-04-15 16:14 ` Aurelien Jarno
2009-04-05 20:59 ` [Qemu-devel] [PATCH 09/10] Prefer glibc over direct syscalls riku.voipio
2009-04-15 16:14 ` Aurelien Jarno
2009-04-05 20:59 ` [Qemu-devel] [PATCH 10/10] linux-user: Proper exit code for uncaught signals riku.voipio
2009-04-15 16:19 ` Aurelien Jarno
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=20090406151747.GA9881@kos.to \
--to=riku.voipio@iki.fi \
--cc=kirill@shutemov.name \
--cc=qemu-devel@nongnu.org \
/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).