Re: When should ralloc.c be used?

[Daniel Colascione]

Eli Zaretskii <address@hidden> writes:

>> Cc: address@hidden, address@hidden, address@hidden
>> From: Daniel Colascione <address@hidden>
>> Date: Fri, 28 Oct 2016 08:41:48 -0700
>> 
>> >> Reserving address space is useful for making sure you have a contiguous
>> >> range of virtual addresses that you can use later.
>> >
>> > But if committing more pages from the reserved range is not guaranteed
>> > to succeed, I cannot rely on getting that contiguous range of
>> > addresses, can I?
>> 
>> You already _have_ the range of addresses. You just can't do anything 
>> with them yet.
>
> It's no use "having" the addresses, in the above sense, if I can't
> rely on being able to do anything with them later.

You can rely on nobody else using that address space, though. This
exclusion in itself is valuable. It's like an electric company buying
right-of-way for a high-voltage transmission line.  Sure, the electric
company isn't doing anything with that long strip of land, but the value
is in nobody _else_ doing anything with it either.

>
>> Here's another use case: magic ring buffers. (Where you put two 
>> consecutive views of the same file in memory next to each other so that 
>> operations on the ring buffer don't need to be split even in cases where 
>> they'd wrap the end of the ring.)
>> 
>> Say on our 1GB RAM, 1GB swap system we want to memory-map a 5GB ring 
>> buffer log file. We can do it safely and atomically like this:
>> 
>> 1) Reserve 10GB of address space with an anonymous PROT_NONE mapping; 
>> the mapping is at $ADDR
>> 2) Memory-map our log file at $ADDR with PROT_READ|PROT_WRITE; (the 
>> mapping is file-backed, not anonymous, so it doesn't count against 
>> system commit charge)
>> 3) Memory-map the log file _again_ at $ADDR+5GB
>
> If 3) fails, what do you do?

Unmap the original mapping and mapping #2, then fail the higher-level
make_magic_ring_buffer operation. Any operation that allocates memory
can fail.

>
>> Now we have a nice mirrored view of our ring buffer, and thanks to the 
>> PROT_NONE mapping we set up in step one, no other thread was able to 
>> sneak in the middle and allocate something in the [$ADDR+5GB,$ADDR+10GB) 
>> range and spoil our ability to set up the mirroring.
>> 
>> In this instance, setting aside address space without allocating backing 
>> storage for it turned out to be very useful.
>
> Not if PROT_READ|PROT_WRITE call fails.
>
> But if, as Stefan says, this will "never" happen, then the problem
> doesn't exist in practice, and for all practical purposes what I
> thought should happen, does happen, even if in theory it can fail.

It's unlikely, but it's a legal failure mode.