All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@kernel.org>
To: Jann Horn <jannh@google.com>
Cc: Michael Kerrisk-manpages <mtk.manpages@gmail.com>,
	linux-man <linux-man@vger.kernel.org>,
	Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH] mmap.2: fix description of treatment of the hint
Date: Wed, 13 Feb 2019 13:22:44 +0100	[thread overview]
Message-ID: <20190213122244.GE4525@dhcp22.suse.cz> (raw)
In-Reply-To: <CAG48ez2-Y-QuYOHvcEiBcgFq46C-ZeCqZg9+7KRaOhE-AmQ4mw@mail.gmail.com>

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


      reply	other threads:[~2019-02-13 12:22 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-11 16:32 [PATCH] mmap.2: fix description of treatment of the hint Jann Horn
2019-02-13 11:47 ` Michal Hocko
2019-02-13 11:53   ` Jann Horn
2019-02-13 12:22     ` Michal Hocko [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190213122244.GE4525@dhcp22.suse.cz \
    --to=mhocko@kernel.org \
    --cc=jannh@google.com \
    --cc=linux-man@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mtk.manpages@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.