Date: Sun, 04 Nov 2007 19:50:50 +0200 From: "Valery V.Chikalov" <valera@chikalov.dp.ua> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-emulation@freebsd.org Subject: Re: Linux emulation on FreeBSD AMD64 Message-ID: <472E067A.5050601@chikalov.dp.ua> In-Reply-To: <20071104171423.GL37471@deviant.kiev.zoral.com.ua> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?472E067A.5050601>