mmap.2: fix description of treatment of the hint
PATCH 1/1 mmap.2: fix description of treatment of the hint
The current manpage reads to me as if the kernel will always pick a free space close to the requested address, but that's not the case:
mmap(0x600000000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x600000000000mmap(0x600000000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f5042859000
You can also see this in the various implementations of ->get_unmapped_area() - if the specified address isn't available, the kernel basically ignores the hint (apart from the 5level paging hack).
Clarify how this works a bit.
--- man2/mmap.2 | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
man2/mmap.2 +6 -1
@@ -71,7 +71,12 @@ If .I addr is not NULL, then the kernel takes it as a hint about where to place the mapping; -on Linux, the mapping will be created at a nearby page boundary. +on Linux, the kernel will pick a nearby page boundary (but always above +or equal to the value specified by +.IR /proc/sys/vm/mmap_min_addr ) +and attempt to create the mapping there. +If another mapping already exists there, the kernel picks a new +address, independent of the hint. .\" Before Linux 2.6.24, the address was rounded up to the next page .\" boundary; since 2.6.24, it is rounded down! The address of the new mapping is returned as the result of the call.
Signature · 1 line
2.20.1.791.gb4d0f1c61a-goog
Quoted 8 lines · Jann Horn
The current manpage reads to me as if the kernel will always pick a free space close to the requested address, but that's not the case:
mmap(0x600000000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)=0x600000000000mmap(0x600000000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)=0x7f5042859000
Quoted 5 lines
You can also see this in the various implementations of ->get_unmapped_area() - if the specified address isn't available, the kernel basically ignores the hint (apart from the 5level paging hack).
Clarify how this works a bit.
Do we really want to be that specific? What if a future implementation would like to ignore the mapping even if there is no colliding mapping already? E.g. becuase of fragmentation avoidance or whatever other reason. If we are explicit about the current implementation we might give a receipt to userspace to depend on that behavior.
Quoted 25 lines
Signed-off-by Jann Horn <[email protected]>--- man2/mmap.2 | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)man2/mmap.2 +6
-1@@ -71,7 +71,12 @@ If .I addr is not NULL, then the kernel takes it as a hint about where to place the mapping; -on Linux, the mapping will be created at a nearby page boundary. +on Linux, the kernel will pick a nearby page boundary (but always above +or equal to the value specified by +.IR /proc/sys/vm/mmap_min_addr ) +and attempt to create the mapping there. +If another mapping already exists there, the kernel picks a new +address, independent of the hint. .\" Before Linux 2.6.24, the address was rounded up to the next page .\" boundary; since 2.6.24, it is rounded down! The address of the new mapping is returned as the result of the call.Signature · 1 line
2.20.1.791.gb4d0f1c61a-goog
Signature · 2 lines
Michal Hocko SUSE Labs
Quoted 13 lines · Michal Hocko
Quoted 12 lines · Jann Horn
The current manpage reads to me as if the kernel will always pick a free space close to the requested address, but that's not the case:
mmap(0x600000000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)=0x600000000000mmap(0x600000000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)=0x7f5042859000You can also see this in the various implementations of ->get_unmapped_area() - if the specified address isn't available, the kernel basically ignores the hint (apart from the 5level paging hack).
Quoted 7 lines
Quoted 1 line
Clarify how this works a bit.
Do we really want to be that specific? What if a future implementation would like to ignore the mapping even if there is no colliding mapping already? E.g. becuase of fragmentation avoidance or whatever other reason. If we are explicit about the current implementation we might give a receipt to userspace to depend on that behavior.
You have a point. So I guess we want something like this?
"If another mapping already exists there, the kernel picks a new address that may or may not depend on the hint."
Unless someone can come up with a nicer wording for this?
Quoted 22 lines · Jann Horn
Quoted 13 lines · Michal Hocko
Quoted 12 lines · Jann Horn
The current manpage reads to me as if the kernel will always pick a free space close to the requested address, but that's not the case:
mmap(0x600000000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)=0x600000000000mmap(0x600000000000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)=0x7f5042859000You can also see this in the various implementations of ->get_unmapped_area() - if the specified address isn't available, the kernel basically ignores the hint (apart from the 5level paging hack).
Quoted 7 lines
Quoted 1 line
Clarify how this works a bit.
Do we really want to be that specific? What if a future implementation would like to ignore the mapping even if there is no colliding mapping already? E.g. becuase of fragmentation avoidance or whatever other reason. If we are explicit about the current implementation we might give a receipt to userspace to depend on that behavior.
Quoted 4 lines
You have a point. So I guess we want something like this?
"If another mapping already exists there, the kernel picks a new address that may or may not depend on the hint."
Yes, this sounds good to me.
Signature · 2 lines
Michal Hocko SUSE Labs