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 (man-pages)" <mtk.manpages@gmail.com>,
	John Hubbard <jhubbard@nvidia.com>,
	linux-man <linux-man@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux-MM <linux-mm@kvack.org>,
	lkml <linux-kernel@vger.kernel.org>,
	Linux API <linux-api@vger.kernel.org>
Subject: Re: [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved
Date: Fri, 13 Apr 2018 18:05:24 +0200	[thread overview]
Message-ID: <CAG48ez3-xtmAt2EpRFR8GNKKPcsDsyg7XdwQ=D5w3Ym6w4Krjw@mail.gmail.com> (raw)
In-Reply-To: <20180413160435.GA17484@dhcp22.suse.cz>

On Fri, Apr 13, 2018 at 6:04 PM, Michal Hocko <mhocko@kernel.org> wrote:
> On Fri 13-04-18 17:04:09, Jann Horn wrote:
>> On Fri, Apr 13, 2018 at 8:49 AM, Michal Hocko <mhocko@kernel.org> wrote:
>> > On Fri 13-04-18 08:43:27, Michael Kerrisk wrote:
>> > [...]
>> >> So, you mean remove this entire paragraph:
>> >>
>> >>               For cases in which the specified memory region has not been
>> >>               reserved using an existing mapping,  newer  kernels  (Linux
>> >>               4.17  and later) provide an option MAP_FIXED_NOREPLACE that
>> >>               should be used instead; older kernels require the caller to
>> >>               use addr as a hint (without MAP_FIXED) and take appropriate
>> >>               action if the kernel places the new mapping at a  different
>> >>               address.
>> >>
>> >> It seems like some version of the first half of the paragraph is worth
>> >> keeping, though, so as to point the reader in the direction of a remedy.
>> >> How about replacing that text with the following:
>> >>
>> >>               Since  Linux 4.17, the MAP_FIXED_NOREPLACE flag can be used
>> >>               in a multithreaded program to avoid  the  hazard  described
>> >>               above.
>> >
>> > Yes, that sounds reasonable to me.
>>
>> But that kind of sounds as if you can't avoid it before Linux 4.17,
>> when actually, you just have to call mmap() with the address as hint,
>> and if mmap() returns a different address, munmap() it and go on your
>> normal error path.
>
> This is still racy in multithreaded application which is the main point
> of the whole section, no?

No, it isn't.

  reply	other threads:[~2018-04-13 16:05 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-12 15:39 [PATCH] mmap.2: MAP_FIXED is okay if the address range has been reserved Jann Horn
2018-04-12 15:39 ` Jann Horn
2018-04-12 15:39 ` Jann Horn
2018-04-12 18:32 ` Michael Kerrisk (man-pages)
2018-04-12 18:33 ` John Hubbard
2018-04-12 18:33   ` John Hubbard
2018-04-12 18:37   ` Michael Kerrisk (man-pages)
2018-04-12 18:49     ` Jann Horn
2018-04-12 18:59       ` John Hubbard
2018-04-12 19:18         ` Jann Horn
2018-04-12 19:24           ` John Hubbard
2018-04-13  6:43             ` Michael Kerrisk (man-pages)
2018-04-13  6:49               ` Michal Hocko
2018-04-13 15:04                 ` Jann Horn
2018-04-13 16:04                   ` Michal Hocko
2018-04-13 16:05                     ` Jann Horn [this message]
2018-04-13 16:17                       ` Jann Horn
2018-04-16 10:07                         ` Michal Hocko
2018-04-16 13:55                           ` Jann Horn
2018-04-16 19:18                             ` Michal Hocko
2018-04-16 19:30                               ` Jann Horn
2018-04-16 19:57                                 ` Michal Hocko
2018-04-16 20:17                                   ` Jann Horn
2018-04-16 21:11                                     ` Michal Hocko
2018-04-16 21:12                                       ` Jann Horn
2018-04-17  6:23                                         ` Michal Hocko
2018-05-02 13:06                                       ` Michael Kerrisk (man-pages)

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='CAG48ez3-xtmAt2EpRFR8GNKKPcsDsyg7XdwQ=D5w3Ym6w4Krjw@mail.gmail.com' \
    --to=jannh@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=jhubbard@nvidia.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --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.