| Message ID | 20190214161836.184044-1-jannh@google.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] mmap.2: fix description of treatment of the hint | expand |
On Thu 14-02-19 17:18:36, Jann Horn wrote: > 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) = 0x600000000000 > mmap(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. > > Signed-off-by: Jann Horn <jannh@google.com> Acked-by: Michal Hocko <mhocko@suse.com> Thanks! > --- > changed in v2: > - be less specific about what the kernel does when the requested address > is unavailable to avoid constraining future behavior changes > (Michal Hocko) > > man2/mmap.2 | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/man2/mmap.2 b/man2/mmap.2 > index fccfb9b3e..dbcae59be 100644 > --- a/man2/mmap.2 > +++ b/man2/mmap.2 > @@ -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 that > +may or may not depend on 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. > -- > 2.21.0.rc0.258.g878e2cd30e-goog
On 2/14/19 5:18 PM, Jann Horn wrote: > 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) = 0x600000000000 > mmap(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. > > Signed-off-by: Jann Horn <jannh@google.com> Thanks, Jann. Patch applied. And thanks for the review, Michal. Cheers, Michael > --- > changed in v2: > - be less specific about what the kernel does when the requested address > is unavailable to avoid constraining future behavior changes > (Michal Hocko) > > man2/mmap.2 | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/man2/mmap.2 b/man2/mmap.2 > index fccfb9b3e..dbcae59be 100644 > --- a/man2/mmap.2 > +++ b/man2/mmap.2 > @@ -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 that > +may or may not depend on 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. >
Thanks for updating the man page!
Reviewed-by: William Kucharski <william.kucharski@oracle.com>
On Wed, 27 Feb 2019 at 15:37, William Kucharski <william.kucharski@oracle.com> wrote: > > > Thanks for updating the man page! > > Reviewed-by: William Kucharski <william.kucharski@oracle.com> Thanks for the review, William. Cheers, Michael
diff --git a/man2/mmap.2 b/man2/mmap.2 index fccfb9b3e..dbcae59be 100644 --- a/man2/mmap.2 +++ b/man2/mmap.2 @@ -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 that +may or may not depend on 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.
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) = 0x600000000000 mmap(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. Signed-off-by: Jann Horn <jannh@google.com> --- changed in v2: - be less specific about what the kernel does when the requested address is unavailable to avoid constraining future behavior changes (Michal Hocko) man2/mmap.2 | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)