Diff Detail
- Lint
Lint Skipped - Unit
Tests Skipped
Event Timeline
| lib/libc/sys/mmap.2 | ||
|---|---|---|
| 204 | "within its address range" or "overapping its address range" or something like that? The guard prevents mappings without the MAP_FIXED flag from overlapping its address range. | |
| 209 | results in the SIGSEGV signal being delivered to the thread. | |
| 213 | Guards allow the reservations to be created in the address space, which can be replaced by actual mappings later on. For instance, the system uses guards to prevent the inadvertent use of regions into which stacks created with MAP_STACK will automatically grow. | |
| lib/libc/sys/mmap.2 | ||
|---|---|---|
| 203 | "a mapping" | |
| 204 | I would write this sentence as "mmap(2) will not create mappings in the address range of a guard unless the request specifies MAP_FIXED. Guards can be destroyed with munmap(2)." In particular, since we're being careful to distinguish between guards and mappings, it seems strange to state that a guard can be unmapped. | |
| 209 | "results in the delivery of a SIGSEGV signal to the thread" | |
| 213 | "Guards allow a process to create reservations in its address space, which..." | |
| 215 | "the system" | |
| lib/libc/sys/mmap.2 | ||
|---|---|---|
| 204 | Sounds good. | |
I combined the feedback, selecting the parts from each. I also added half-sentence mentioning that stacks are not mapped fully in advance.
| lib/libc/sys/mmap.2 | ||
|---|---|---|
| 215 | which can later be replaced by actual mappings. | |
Sounds good to me; if @wblock or other manpage folks have input it can be incorporated into the commit or as a follow-on.
I think that there are a few things missing here.
- If I'm using MAP_STACK, do I have to use MAP_GUARD in some way? I don't think the words "the system uses guards" are specific enough. That said, the way that I would handle this is to update the description of MAP_STACK.
- What happens if I specify MAP_GUARD in conjunction with a "prot" other than PROT_NONE or an "fd" other than -1?
- What happens to a guard on a fork()?
| lib/libc/sys/mmap.2 | ||
|---|---|---|
| 212 | I don't see the harm in tweaking the sentence to avoid any possible confusion: "Any memory access by a thread to the guarded range results in the delivery of a SIGSEGV to that thread." | |
| 216–219 | I would suggest moving this (minus the "For instance,") to the description of MAP_STACK. | |
Move note about MAP_STACK use of MAP_GUARD to MAP_STACK block.
Document EINVAL on invalid MAP_GUARD call, explicitely listing the requirements.
Also remove MAP_HASSEMAPHORE, this will be the preliminary conflict. The option is in sys/mman.h, it is not useful but AFAIK cannot be easily removed.
This needs updating:
[EINVAL] None of MAP_ANON, MAP_PRIVATE, MAP_SHARED, or
MAP_STACK was specified. At least one of these flags
must be included.Here is an unrelated typo in the map page:
"truncated and the process later accesses a pages that is wholly within"
"pages" should be "page".
| lib/libc/sys/mmap.2 | ||
|---|---|---|
| 335 | This is complex. Suggested: Stacks created with .Dv MAP_STACK automatically grow. Guards prevent inadvertent use of the regions into which those stacks can grow without requiring mapping the whole stack in advance. | |