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

[Rtp]

Riku Voipio <address@hidden> writes:

> 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?

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