Re: [PATCH] mmap.2: fix description of treatment of the hint

[Michal Hocko <mhocko@kernel.org>]

On Wed 13-02-19 12:53:15, Jann Horn wrote:
> On Wed, Feb 13, 2019 at 12:47 PM Michal Hocko <mhocko@kernel.org> wrote:
> > On Mon 11-02-19 17:32:03, 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.
> >
> > 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."

Yes, this sounds good to me.
-- 
Michal Hocko
SUSE Labs