From owner-freebsd-emulation@FreeBSD.ORG Sun Nov 4 17:53:38 2007 Return-Path: Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE00F16A419; Sun, 4 Nov 2007 17:53:38 +0000 (UTC) (envelope-from valera@chikalov.dp.ua) Received: from halik.com.ua (halik.com.ua [193.178.146.121]) by mx1.freebsd.org (Postfix) with ESMTP id 756AE13C4B0; Sun, 4 Nov 2007 17:53:38 +0000 (UTC) (envelope-from valera@chikalov.dp.ua) Received: from tiger.novakom.dp.ua (unknown [213.227.219.58]) by halik.com.ua (Postfix) with ESMTP id C3BCA5C032; Sun, 4 Nov 2007 19:53:05 +0200 (EET) Message-ID: <472E067A.5050601@chikalov.dp.ua> Date: Sun, 04 Nov 2007 19:50:50 +0200 From: "Valery V.Chikalov" User-Agent: Thunderbird 2.0.0.6 (X11/20070814) MIME-Version: 1.0 To: Kostik Belousov References: <4723A8D6.6020002@chikalov.dp.ua> <20071031180639.GA93259@cons.org> <47298F10.4050301@chikalov.dp.ua> <20071101152550.GA10868@cons.org> <472B0454.9040408@chikalov.dp.ua> <472B9CD1.1010607@chikalov.dp.ua> <472DAF60.9040008@chikalov.dp.ua> <20071104122023.GA5528@freebsd.org> <472DC7C3.3090105@chikalov.dp.ua> <20071104133518.GA7275@freebsd.org> <20071104171423.GL37471@deviant.kiev.zoral.com.ua> In-Reply-To: <20071104171423.GL37471@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-emulation@freebsd.org Subject: Re: Linux emulation on FreeBSD AMD64 X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2007 17:53:38 -0000 Kostik Belousov wrote: [...] >>> >>> This are only addresses which are arguments for linux_mprotect. >>> I have suspected linux_mmap_common but it not called either. >> the protection can be set from mmap(), can you see if there is a mmap call with 0x50....0 ? > > > SysV shm is mapped by the shmat(2) syscall. linux compat implementation, > linux_shmat(), calls shmat() (this shall be fixed to use kern_shmat). > > Look for the VM_PROT_READ_IS_EXEC in the sys/kern/sysv_shm.c. I think that > would explain both reason for the fault and missing mmap() calls. > > It should be fixed by acting as if VM_PROT_READ_IS_EXEC is enabled if > kern_shmat() is called from linux_shmat(). This might cause some > problems when shared segment is being attached both by freebsd and > linux processes. Yes, you are right. This issue was resolved already due to kindly help of rdivacky@. I just tried to know little more before posting the results. That is proposed by him patch: Index: vmparam.h =================================================================== RCS file: /home/ncvs/src/sys/amd64/include/vmparam.h,v retrieving revision 1.49 diff -u -r1.49 vmparam.h --- vmparam.h 25 Sep 2007 06:25:04 -0000 1.49 +++ vmparam.h 4 Nov 2007 14:43:39 -0000 @@ -45,6 +45,10 @@ #ifndef _MACHINE_VMPARAM_H_ #define _MACHINE_VMPARAM_H_ 1 +#ifdef COMPAT_IA32 +#define VM_PROT_READ_IS_EXEC /* if you can read -- then you can exec */ +#endif + /* * Machine dependent constants for AMD64. */ There are no more missing execute bits. But now I'm trying to investigate why from some time linux_ipc begin to return "-1 errno 34 Result too large", which results in oracle coredumps (as usual :-)) 1011 oracle CALL linux_ipc(0x15,0x30000,0,0xffffac08,0x50000000,0xffffac18) 1011 oracle RET linux_ipc 0 1011 oracle CALL linux_ipc(0x2,0,0x1,0x780,0,0xffffaca8) 1011 oracle RET linux_ipc 589824/0x90000 1011 oracle CALL linux_ipc(0x3,0x90000,0,0x10,0xffffac5c,0xffffaca8) 1011 oracle RET linux_ipc -1 errno 34 Result too large 1011 oracle CALL linux_ipc(0x3,0x90000,0,0x10,0xffffac5c,0xffffaca8) 1011 oracle RET linux_ipc -1 errno 34 Result too large 1011 oracle CALL linux_ipc(0x3,0x90000,0,0x10,0xffffac5c,0xffffaca8) Thank you for help. Valery.