Linux emulation on FreeBSD AMD64

[Valery V.Chikalov]

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.

Thanks.
Valery.

> 
> Martin