qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 04/10] fix IPCOP_sem* and implement sem*


From: Riku Voipio
Subject: Re: [Qemu-devel] [PATCH 04/10] fix IPCOP_sem* and implement sem*
Date: Mon, 6 Apr 2009 18:17:47 +0300
User-agent: Mutt/1.5.18 (2008-05-17)

On Mon, Apr 06, 2009 at 11:06:22AM +0200, Arnaud Patard wrote:
> address@hidden 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]