From: Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>
To: qemu-devel@nongnu.org
Cc: kirill@shutemov.name
Subject: Re: [Qemu-devel] [PATCH 04/10] fix IPCOP_sem* and implement sem*
Date: Mon, 06 Apr 2009 18:22:50 +0200 [thread overview]
Message-ID: <87hc11iwf9.fsf@lechat.rtp-net.org> (raw)
In-Reply-To: <20090406151747.GA9881@kos.to> (Riku Voipio's message of "Mon\, 6 Apr 2009 18\:17\:47 +0300")
Riku Voipio <riku.voipio@iki.fi> writes:
> 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?
well, in case of semctl, it was broken so it does change the
behaviour. In case of shmctl, you're right it's changing nothing
> 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.
Well, it was an open question. I've seen the semctl breakage and then
your patch. When looking at it, I've noticed that it might break
something but I've no idea if it's breaking something in
practice. That's why I've asked.
Arnaud
next prev parent reply other threads:[~2009-04-06 16:22 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
2009-04-06 16:22 ` Arnaud Patard [this message]
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=87hc11iwf9.fsf@lechat.rtp-net.org \
--to=arnaud.patard@rtp-net.org \
--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).