QEMU mmap_min_addr issue Was: some possible fixes in the OE web pages

[Martin Jansa <martin.jansa@gmail.com>]

On Thu, May 13, 2010 at 11:23:20AM +0200, Martin Jansa wrote:
> On Thu, May 13, 2010 at 12:59:13PM +0400, Roman I Khimov wrote:
> > В сообщении от Четверг 13 мая 2010 12:46:33 автор Martin Jansa написал:
> > > On Thu, May 13, 2010 at 12:23:22PM +0400, Roman I Khimov wrote:
> > > > Well, as the problem is in the kernel really, I think everyone having
> > > > this problem should push distro maintainers to update kernels with the
> > > > tiny fix mentioned above. But as a workaround, yep, "0" setting might
> > > > work (beware that it might also not work as in here:
> > > > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/423513
> > > > ).
> > > 
> > > Another not tested workaround:
> > > 
> > > as qemu can work with (hopefully any) non-zero mmap_min_addr, maybe add
> > > patch to linux-user/main.c that if it cannot read
> > > /proc/sys/vm/mmap_min_addr then assume 65536 (ubuntu default)?
> > 
> > Fedora has the same default, so this should work.
> 
> Can we compare this simple test between working and non-working systems?
> 
> This is from working gentoo 2.6.34-rc7:
> 
> bitbake@jama ~/mmap-test $ wget http://build.shr-project.org/tests/jama/mmap-test.c
> bitbake@jama ~/mmap-test $ gcc mmap-test.c -o mmap-test
> bitbake@jama ~/mmap-test $ ./mmap-test
> cannot read value from /proc/sys/vm/mmap_min_addr
> bitbake@jama ~/mmap-test $ strace ./mmap-test
> execve("./mmap-test", ["./mmap-test"], [/* 26 vars */]) = 0
> brk(0)                                  = 0xded000
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7647150000
> access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
> open("/etc/ld.so.cache", O_RDONLY)      = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=22777, ...}) = 0
> mmap(NULL, 22777, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f764714a000
> close(3)                                = 0
> open("/lib/libc.so.6", O_RDONLY)        = 3
> read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\354\1\0\0\0\0\0"..., 832) = 832
> fstat(3, {st_mode=S_IFREG|0755, st_size=1424560, ...}) = 0
> mmap(NULL, 3533704, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f7646bd5000
> mprotect(0x7f7646d2a000, 2097152, PROT_NONE) = 0
> mmap(0x7f7646f2a000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x155000) = 0x7f7646f2a000
> mmap(0x7f7646f2f000, 19336, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f7646f2f000
> close(3)                                = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7647149000
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7647148000
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7647147000
> arch_prctl(ARCH_SET_FS, 0x7f7647148700) = 0
> mprotect(0x7f7646f2a000, 16384, PROT_READ) = 0
> mprotect(0x600000, 4096, PROT_READ)     = 0
> mprotect(0x7f7647151000, 4096, PROT_READ) = 0
> munmap(0x7f764714a000, 22777)           = 0
> brk(0)                                  = 0xded000
> brk(0xe0e000)                           = 0xe0e000
> open("/proc/sys/vm/mmap_min_addr", O_RDONLY) = 3
> fstat(3, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f764714f000
> read(3, 0x7f764714f000, 1024)           = -1 EPERM (Operation not permitted)
> fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 16), ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f764714e000
> write(1, "cannot read value from /proc/sys"..., 50cannot read value from /proc/sys/vm/mmap_min_addr
> ) = 50
> close(3)                                = 0
> munmap(0x7f764714f000, 4096)            = 0
> exit_group(0)                           = ?
> 
> Regards,

Another interesting test:
prepare rootfs of some image you have
I used: bitbake -c build -b ../dev/recipes/images/shr-image.bb

bitbake@jama ~/tmpdir-dev-shr/rootfs/shr-image $ qemu-arm -s 1048576 -r 2.6.24 -cpu arm926 -d exec  -L . bin/busybox >/dev/null
bitbake@jama ~/tmpdir-dev-shr/rootfs/shr-image $ cat /tmp/qemu.log
guest_base  0x0
start    end      size     prot
00008000-00070000 00068000 r-x
00070000-00071000 00001000 rw-
00071000-00073000 00002000 rwx
40000000-40100000 00100000 rw-
40100000-40101000 00001000 ---
40101000-4011c000 0001b000 r-x
4011c000-40123000 00007000 ---
40123000-40125000 00002000 rw-
40125000-42101000 01fdc000 ---
60000000-6223d000 0223d000 ---
63624000-6399e000 0037a000 ---
start_brk   0x00072b44
end_code    0x0006f6f4
start_code  0x00008000
start_data  0x00070000
end_data    0x00070824
start_stack 0x400ff268
brk         0x00072b44
entry       0x401017a0

and the same under root
jama shr-image # cat /tmp/qemu.log
host mmap_min_addr=0x1000
guest_base  0x0
start    end      size     prot
00008000-00070000 00068000 r-x
00070000-00071000 00001000 rw-
00071000-00073000 00002000 rwx
40000000-40100000 00100000 rw-
40100000-40101000 00001000 ---
40101000-4011c000 0001b000 r-x
4011c000-40123000 00007000 ---
40123000-40125000 00002000 rw-
40125000-42101000 01fdc000 ---
60000000-6223d000 0223d000 ---
630da000-63488000 003ae000 ---
start_brk   0x00072b44
end_code    0x0006f6f4
start_code  0x00008000
start_data  0x00070000
end_data    0x00070824
start_stack 0x400fef48
brk         0x00072b44
entry       0x401017a0

so here it also doesn't respect mmap_min_addr=0x1000 when using qemu-arm
under bitbake user.

Regards,

-- 
uin:136542059                jid:Martin.Jansa@gmail.com
Jansa Martin                 sip:jamasip@voip.wengo.fr 
JaMa