Re: [Valgrind-developers] mmap strangeness on ppc32-linux

[John R. <jr...@Bi...>]

Julian Seward wrote:
> V's address space manager has a clear idea of what address ranges it 
> doesn't want the client to use, but it doesn't have a clear idea of what
> ranges the kernel might refuse.

It seems to me that there still may be some misunderstandings here.
These misunderstandings did cause me trouble in the past, particularly
with randomized placement for mmap() turned on by Fedora Core.

A pageframe that is mapped already is never ("re-")allocated by mmap(),
unless the mmap specifies MAP_FIXED and the interval covers that page.

The only reliable way to preserve an address range that V's address space
manager does not want the kernel to use, is to "reserve" it by using
mmap(addr, length, PROT_NONE, MAP_ANON|MAP_FIXED,,).  Otherwise the kernel
is free to use any portion of the interval [addr, length + addr) for
_any_ mmap(), hinted or not, as long as MAP_FIXED is not requested.
Randomization is allowed to ignore hints, and sometimes does [has].
On a 32-bit machine this may require the address space manager to
track all pageframes; but there are at most 1M pageframes [4KB pages],
so a 128KB bitmap suffices.  On a 64-bit machine the manager probably
must know something about segments anyway.

> ld.so asks for a hinted mapping at 0xFFFDE000, aspacemgr says "ok by me",
> ML_(generic_PRE_sys_mmap) duly presents that to the kernel, but now as
> MAP_FIXED, and the kernel refuses.  So the syscall wrapper for mmap hands
> the failure back to ld.so.

If the virtualizer changes the arguments to a system call, then the
virtualizer should handle internally any resulting error conditions
that are due to the changes.  The strategy above (handing the failure
of mmap(,,,MAP_FIXED,,) back to ld.so even though ld.so did not ask
for MAP_FIXED) violates this rule of good programming practice.  The code
might work today on some systems, but probably it will fail mysteriously
on other systems or in the future.

> My fix is: in ML_(generic_PRE_sys_mmap), if the kernel refuses what was
> originally a hinted mapping, try again as a non-hinted mapping.  That
> appears to fix the problem.

I agree that this is likely to work in many cases.  However, a kernel which
actively randomizes placement of mmap still will cause trouble by violating
the assumed reservations that the address space manager has not communicated
to the kernel.

--