All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jann Horn <jannh@google.com>
To: Michal Hocko <mhocko@kernel.org>
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 12:53:15 +0100	[thread overview]
Message-ID: <CAG48ez2-Y-QuYOHvcEiBcgFq46C-ZeCqZg9+7KRaOhE-AmQ4mw@mail.gmail.com> (raw)
In-Reply-To: <20190213114724.GA4525@dhcp22.suse.cz>

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."

Unless someone can come up with a nicer wording for this?


  reply	other threads:[~2019-02-13 11:53 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 [this message]
2019-02-13 12:22     ` Michal Hocko

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=CAG48ez2-Y-QuYOHvcEiBcgFq46C-ZeCqZg9+7KRaOhE-AmQ4mw@mail.gmail.com \
    --to=jannh@google.com \
    --cc=linux-man@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.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.