From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lqqa8-0002yI-5j for qemu-devel@nongnu.org; Mon, 06 Apr 2009 11:17:52 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lqqa6-0002xM-PG for qemu-devel@nongnu.org; Mon, 06 Apr 2009 11:17:51 -0400 Received: from [199.232.76.173] (port=33612 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lqqa6-0002xE-DW for qemu-devel@nongnu.org; Mon, 06 Apr 2009 11:17:50 -0400 Received: from naru.obs2.net ([84.20.150.76]:52077) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Lqqa6-0007ku-14 for qemu-devel@nongnu.org; Mon, 06 Apr 2009 11:17:50 -0400 Date: Mon, 6 Apr 2009 18:17:47 +0300 From: Riku Voipio Subject: Re: [Qemu-devel] [PATCH 04/10] fix IPCOP_sem* and implement sem* Message-ID: <20090406151747.GA9881@kos.to> References: <87ljqei229.fsf@lechat.rtp-net.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ljqei229.fsf@lechat.rtp-net.org> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: kirill@shutemov.name 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