From owner-freebsd-emulation@FreeBSD.ORG Fri Nov 2 21:58:09 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 6E0DA16A420 for ; Fri, 2 Nov 2007 21:58:09 +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 B90C313C4B7 for ; Fri, 2 Nov 2007 21:58:08 +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 8476D5C034; Fri, 2 Nov 2007 23:57:41 +0200 (EET) Message-ID: <472B9CD1.1010607@chikalov.dp.ua> Date: Fri, 02 Nov 2007 23:55:29 +0200 From: "Valery V.Chikalov" User-Agent: Thunderbird 2.0.0.6 (X11/20070814) MIME-Version: 1.0 To: Martin Cracauer References: <4721AB07.20708@novakom.com.ua> <4723A8D6.6020002@chikalov.dp.ua> <20071031180639.GA93259@cons.org> <47298F10.4050301@chikalov.dp.ua> <20071101152550.GA10868@cons.org> <472B0454.9040408@chikalov.dp.ua> In-Reply-To: <472B0454.9040408@chikalov.dp.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: Fri, 02 Nov 2007 21:58:09 -0000 Valery V.Chikalov wrote: > Martin Cracauer wrote: >> Valery V.Chikalov wrote on Thu, Nov 01, 2007 at 10:32:16AM +0200: >>> Martin Cracauer wrote: >>>> Valery V.Chikalov wrote on Sun, Oct 28, 2007 at 12:08:38AM +0300: >>>>> Oct 27 19:42:59 tiger kernel: mprotect addr:2a27d000, return 0 >>>>> Oct 27 19:42:59 tiger kernel: mprotect addr:2a7c1000, return 0 >>>>> Oct 27 19:42:59 tiger kernel: mprotect addr:2a7cd000, return 0 >>>>> Oct 27 19:42:59 tiger kernel: mprotect addr:2a7e2000, return 0 >>>>> Oct 27 19:42:59 tiger kernel: mprotect addr:2a7ef000, return 0 >>>>> Oct 27 19:43:09 tiger kernel: mprotect addr:55c00000, return 13 >>>>> Oct 27 19:43:09 tiger kernel: mprotect addr:55c81000, return 13 >>>> You need to check whether these is anything mapped there in the first >>>> place and what the permissions are. >>>> >>>> This is probably best done by changing your debugging code in the >>>> Linuxulator to print amessage, then sleep for 10 seconds giving you >>>> time to copy the memory map to a safe place, then look up what the >>>> mapping at the position was. >>>> >>>> Martin >>> Hi, Martin. >>> >>> Thank you for the hint. >>> But I'm not sure that I understanding you right. >>> I'm not a kernel hacker, just C-programmer with ability to read >>> documentation. :-) >>> Do the "memory map" about you told is some C-struct I can deal with >>> and which can be accessed by some system call, or that task ("copy >>> the memory map") can be achieved by some userland utility like "ipcs" >>> or "vmstat -m". >> >> No, you need the contents of /proc//map >> and >> /compat/linux/proc//maps >> > > Hi, Martin. > > Thank you for help. > You have reminded me about the /proc, which I have stopped using a long > time ago as "deprecated" in favor of sysctl. In this case it is really > useful. > >> This is why you hack up the kernel to wait a while, before the syscall >> is actually executed you want the time to grab both these files for >> the process and save them somewhere (cp /proc... /tmp/ is sufficient). >> > > I can use a little simpler method as I have perfectly running exemplar > of Oracle on another computer on FreeBSD in i386 mode. > > So in first place I'm getting: > > oerr ORA 27122 > 27122, 00000, "unable to protect memory" > // *Cause: mprotect() call failed > > After the diagnostic patch proposed by rdivacky@ to linux_machdep.c > > +#if 0 > if (bsd_args.prot & (PROT_READ | PROT_WRITE | PROT_EXEC)) > bsd_args.prot |= PROT_READ | PROT_EXEC; > +#endif > > I got started oracle and see expected difference between > /compat/linux/proc//maps: > (i386) > 2a846000-2a849000 rwxp 00003000 00:00 0 > 50000000-60000000 rwxp 10083000 00:00 0 > 60000000-60001000 r-xp 10083000 00:00 0 > 60001000-60081000 rwxp 10083000 00:00 0 > 60081000-60082000 r-xp 10083000 00:00 0 > 60082000-60083000 rwxp 10083000 00:00 0 > bf7e0000-bf800000 rwxp 00020000 00:00 0 > (AMD64) > 2a7c3000-2a804000 rwxp 00041000 00:00 0 > 50000000-55c00000 rw-p 05c83000 00:00 0 > 55c00000-55c01000 r--p 05c83000 00:00 0 > 55c01000-55c81000 rw-p 05c83000 00:00 0 > 55c81000-55c82000 r--p 05c83000 00:00 0 > 55c82000-55c83000 rw-p 05c83000 00:00 0 > fffdf000-fffff000 rwxp 00020000 00:00 0 > > Note absence of the execution bit. > > And then after some time Oracle coredumps > > quotation from rdivacky@ mail: > > >I think its quite obvious... oracle expects some memory is executable > >and tries to execute something in it but freebsd has non-exec bit set > >on that memory hence core dump... > > I tend to agree, but see below... > >> I suspect the difference between Linux and FreeBSD here is what kind > > My point is that we must look for the difference not between Linux and > FreeBSD, but between FreeBSD(i386) and FreeBSD(AMD64), or between Linux > and Linux emulation on FreeBSD *AMD64* and any explanations of this > artifact must contain an AMD64 specific. > > > of existing mapping you are allowed to change in permissions. Should > > be reasonably easy to fix once we know both side, what permissions you > > had before (from the maps) and where you want to go (from the > > syscall arguments). Might be more hairy if some special kind of > > memory is involved but we'll see. Ok, I have fond what is so special with this memory. Oracle uses SYSV shared memory, and comparing output from "ipcs -mb" and /compat/linux/proc//maps it's became clear that that suspiciously looking too high addresses of memory chunks with missed execution bit are SYSV shared memory areas. > 50000000-55c00000 rw-p 05c83000 00:00 0 - this is main chunk which can be seen in output of "show sga" sqlplus command > 55c00000-55c01000 r--p 05c83000 00:00 0 > 55c01000-55c81000 rw-p 05c83000 00:00 0 > 55c81000-55c82000 r--p 05c83000 00:00 0 > 55c82000-55c83000 rw-p 05c83000 00:00 0 - this are adjusted to the end small (4096) pieces So, the question is what is changed in AMD64 arch with respect to SYSV shared memory? Why vm_map_protect from /sys/vm/vm_mmap.c returns KERN_PROTECTION_FAILURE in attempts to change protection of such type of memory? Args are: vm_map_protect:addr:1438646272, addr+size:1438650368, prot:5 Thanks. Valery. > >> >> Martin > > > > _______________________________________________ > freebsd-emulation@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-emulation > To unsubscribe, send any mail to > "freebsd-emulation-unsubscribe@freebsd.org"