Conversation

This is a very good tweet.

Quote Tweet

Mar 23, 2021

Replying to @andy_kelley @saleemrash1d and 2 others

Basically, make a massive PROT_NONE mapping and then you allocate with mprotect to PROT_READ|PROT_WRITE and free by using MAP_FIXED mmap to replace a section with a new fresh PROT_NONE region. It prevents anything else from getting that via mmap outside of your own mmap usage.

Replying to

This is like the Windows notion of reserving vs. committing address space. Linux secretly has this too, when you disable overcommit, but overcommit culture is so prevalent that you can't get information like "committed memory usage" for a process.

Replying to

and

Quote Tweet

Replying to @lynn314159 @andy_kelley and 3 others

It won't work well in the default heuristic overcommit mode which gives you the worst of both worlds. It only works properly in the full overcommit mode. Linux has support for a memory accounting mode too, and it doesn't work for that, since rw anon memory is accountable.

Replying to

and

For context: that's in reply to someone suggesting using a rw mapping from the start, which won't work properly. Linux does essentially have the concept by default in the heuristic overcommit mode, but it's pretty arbitrary about when it gives an error and it's per-process.

12:49 AM · Mar 23, 2021Twitter Web App

Replying to

By the way, the documentation for MAP_NORESERVE in mmap(2) for linux-man-pages is completely wrong. The flag is a no-op in the full overcommit mode and the memory accounting mode. Sole function is to have heuristic overcommit mode ignore a mapping. It can't segfault as it claims.

Replying to

One of the fun parts of having the linux-man-pages act as the user-facing kernel documentation while not actually being developed as part of the kernel or by the kernel developers. The docs people read are wrong and Linux itself barely bothers to have any docs for anything.

Show replies