Re: When should ralloc.c be used?

[Jérémie Courrèges-Anglas]

Eli Zaretskii <address@hidden> writes:

>> Cc: address@hidden, address@hidden, address@hidden
>> From: Daniel Colascione <address@hidden>
>> Date: Fri, 28 Oct 2016 01:11:08 -0700
>> 
>> Say I mmap (anonymously, for simplicity) a page PROT_NONE. After the 
>> initial mapping, that address space is unavailable for other uses. But 
>> because the page protections are PROT_NONE, my program has no legal 
>> right to access that page, so the OS doesn't have to guarantee that it 
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> can find a physical page to back that page I've mmaped. In this state, 
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is what I think is a problem in your reasoning.  "Doesn't have to
guarantee" doesn't mean that the kernel *should not* actually check the
available memory and resource limits.

>> the memory is reserved.
>> 
>> The 20GB PROT_NONE address space reservation itself requires very little 
>> memory. It's just a note in the kernel's VM interval tree that says "the 
>> addresses in range [0x20000, 0x500020000) are reserved". Virtual memory is
>> 
>> Now imagine I change the protections to PROT_READ|PROT_WRITE --- once 
>> the PROT_READ|PROT_WRITE mprotect succeeds, my program has every right 
>> to access that page; under a strict accounting scheme (that is, without 
>> overcommit), the OS has to guarantee that it'll be able to go find a 
>> physical page to back that virtual page. In this state, the memory is 
>> committed -- the kernel has committed to finding backing storage for 
>> that page at some point when the current process tries to access it.
>
> I'm with you up to here.  My question is whether PROT_READ|PROT_WRITE
> call could fail after PROT_NONE succeeded.  You seem to say it could;
> I thought it couldn't.

I wouldn't have thought that PROT_NONE vs PROT_READ|PROT_WRITE would
have changed anything here, but on *some* OSes it does, however it is
not portable.  At least OpenBSD doesn't behave like what you describe.
IMHO people who rely on this kind of reservations rely on
implementation-defined behavior.

Also, sanity wise, I'd prefer having mmap(2) fail right away rather than
having mprotect(2) fail, much later.  *If* mprotect(2) actually fails ;
of course, you don't want to play russian roulette with your OS's
flavor of the OOM-killer either.

>> Say you have a strict-accounting system with 1GB of RAM and 1GB of swap. 
>> I can write a program that reserves 20GB of address space.
>
> I thought such a reservation should fail, because you don't have
> enough virtual memory for 20GB of addresses.  IOW, I thought the
> ability to reserve address space is restricted by the actual amount of
> virtual memory available on the system at the time of the call.  You
> seem to say I was wrong.


-- 
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE