Re: remap_file_pages() use

[Jeff Smith]

>> Mirrored mapping is absolutely required by several
>> independent proprietary platforms I'm aware of, and remap_file_pages()
>> has historically been the only sane way to accomplish this. (i.e.,
>> shm_open(), mmap(NULL, 2^(n+1) pages), remap_file_pages() on 2nd
>> half).
>
> Em.. What's wrong with shm_open() + two mmap()s to cover both halfs?
>
> fd = shm_open();
> addr1 = mmap(NULL, 2*SIZE, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
> addr2 = mmap(addr1 + SIZE, PROT_READ|PROT_WRITE, MAP_SHARED | MAP_FIXED, fd, 0);
>
> Is there a reason why it doens't work?

Your addr2 mmap() call is a bit incorrect semantically and
syntactically (you skipped the length arg). The addr2 request will
fail because mmap() does not implicitly munmap() occupied virtual
address space. Even if you did that, the following still has a race
condition between the addr2 request and another thread grabbing the
same virtual space, which nothing short of a lock on all threads'
mmap()-ing logic can protect:

addr1 = mmap(NULL, 2*SIZE, PROT_READ, MAP_SHARED, fd, 0);
munmap(addr1 + SIZE, SIZE);
/* race on virtual address space here, but n/a for remap_file_pages() ... */
addr2 = mmap(addr1, SIZE, PROT_READ, MAP_SHARED | MAP_FIXED, fd, 0);

remap_file_pages() is not subject to this problem and allows the
creation of considerably cleaner code. Protecting the address space
corner cases with locks or arbitrarily bounded munmap()-and-retry
loops is a substantial burden over the historically provided approach.

>> but failing that, a reservation API would need
>> to be created (possibly a MAP_RESERVE flag) that would set aside a
>> region that could only be subsequently mapped via explicit
>> address-requesting mmap() calls.
>
> I don't get this part.

I'm proposing that a call along the lines of mmap(NULL, len, prot,
MAP_RESERVED | ..., fd, offset) could return a virtual address block
that is -not- actually mapped but -is- protected from other mmap()
calls not explicitly requesting the space via their addr parameters.
Unfortunately, you'd also need to define separate semantics to
un-reserving not-mapped space, etc.

The important issue is that users need to be able to trivially protect
themselves from transient virtual address space congestion problems
and only fail early on long-term exhaustion situations.
--
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/