Date: Fri, 02 Nov 2007 23:55:29 +0200 From: "Valery V.Chikalov" <valera@chikalov.dp.ua> To: Martin Cracauer <cracauer@cons.org> Cc: freebsd-emulation@freebsd.org Subject: Re: Linux emulation on FreeBSD AMD64 Message-ID: <472B9CD1.1010607@chikalov.dp.ua> In-Reply-To: <472B0454.9040408@chikalov.dp.ua> References: <4721AB07.20708@novakom.com.ua> <fg05l9$n32$2@ger.gmane.org> <4723A8D6.6020002@chikalov.dp.ua> <20071031180639.GA93259@cons.org> <47298F10.4050301@chikalov.dp.ua> <20071101152550.GA10868@cons.org> <472B0454.9040408@chikalov.dp.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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/<pid>/map
>> and
>> /compat/linux/proc/<pid>/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/<PID>/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/<PID>/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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?472B9CD1.1010607>