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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.