Re: 2.6.28.4 regression: mmap fails if mlockall used

From: Hugh Dickins
Date: Sun Feb 08 2009 - 13:41:06 EST


On Sun, 8 Feb 2009, Sami Farin wrote:

> 2.6.28.2 + gcc-4.3.2-7 works.
> 2.6.28.4 + gcc-4.4.0-0.16 does not work.
> I run x86_64 SMP kernel.

If it's really a bug, in kernel or gcc, then it will help to know
how 2.6.28.4 + gcc-4.3.2-7 behaves. And are you using the respective
version of gcc to build both the kernel and the a.out?

>
> # strace ./a.out ntp
> 12:10:14.780726 mmap(NULL, 2147624, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = -1 EFAULT (Bad address) <0.000038>

I wonder where that 2147624 originates from. Because EFAULT is exactly
what you get on an mmap of a file, following an mlockall(MCL_FUTURE),
if the file is actually a page or more shorter than the size given:
the mlocking tries to fault in a non-existent page of the file, if
in userspace you'd get SIGBUS, but within the kernel it's EFAULT
returned from the mmap.

My suspicion is that the 2147624 is just wrong: is it a filesize,
but the file gets truncated before the mmap? or is it the size given
in an ELF section perhaps, but the file actually not that big?
Any ENOSPC in that filesystem recently?

> 12:10:14.780809 close(3) = 0 <0.000012>
> 12:10:14.780856 munmap(0x7f3476e0d000, 421232) = 0 <0.000145>
> 12:10:14.781054 write(2, "./a.out: getpwnam failed: Success\n"..., 34./a.out: getpwnam failed: Success
> ) = 34 <0.000015>
>
> I can do malloc(3000000), then mmap call is
> 12:50:20.694207 mmap(NULL, 3002368, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8a8d16b000 <0.003078>

Whereas in the case of anonymous, we don't have an underlying object
to fault in (or create the object in response to the mmap), so no
such problem.

I didn't manage to reproduce this here, but I wasn't using the same
version of gcc nor (I'd guess!) your kernel config nor your a.out.

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/