In a lengthy Zulip discussion, it was discovered that there are modes of use of mmap that are perfectly fine within the scope of Rust's memory model, but not supported by Miri's current implementation:
do an initial big reservation with MAP_NORESERVE, letting the kernel pick a suitable memory range and reserve that address space. (Yes, MAP_NORESERVE still reserves the address space. Talk about confusing flag names...) This may overcommit if permitted by the kernel (that's what "noreserve" refers to), but the memory is now all read/write accessible.
then later do smaller mmap in that range that actually "reserves" the memory (no more overcommit). This may set some flags to get huge tables if possible. It will (may?) also erase the previous contents of the re-mapped ranges, but doesn't change the range of memory that is read/write accessible, so it's fine with our current memory model.
See here for some example code. Thanks to Nils for helping with the exploration here!
In a lengthy Zulip discussion, it was discovered that there are modes of use of mmap that are perfectly fine within the scope of Rust's memory model, but not supported by Miri's current implementation:
See here for some example code. Thanks to Nils for helping with the exploration here!