All of lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Colascione <dancol@google.com>
To: Brian Geffon <bgeffon@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	"Michael S . Tsirkin" <mst@redhat.com>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-mm <linux-mm@kvack.org>,
	Linux API <linux-api@vger.kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Will Deacon <will@kernel.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Sonny Rao <sonnyrao@google.com>, Minchan Kim <minchan@kernel.org>,
	Joel Fernandes <joel@joelfernandes.org>,
	Yu Zhao <yuzhao@google.com>, Jesse Barnes <jsbarnes@google.com>,
	Nathan Chancellor <natechancellor@gmail.com>,
	Florian Weimer <fweimer@redhat.com>,
	"Kirill A . Shutemov" <kirill@shutemov.name>
Subject: Re: [PATCH v4] mm: Add MREMAP_DONTUNMAP to mremap().
Date: Tue, 11 Feb 2020 15:53:03 -0800	[thread overview]
Message-ID: <CAKOZuet-vDU=p0HN5904VAmb+BpePPk77R+35cp6eQNL7fJrYg@mail.gmail.com> (raw)
In-Reply-To: <CADyq12ySxau=SyyNp6VSbwmvRm6Kq1=Y62wTbQZoEAQ1XaXcuw@mail.gmail.com>

On Tue, Feb 11, 2020 at 3:32 PM Brian Geffon <bgeffon@google.com> wrote:
>
> Hi Daniel,
>
> > What about making the
> > left-behind mapping PROT_NONE? This way, we'll still solve the
> > address-space race in Lokesh's use case (because even a PROT_NONE
> > mapping reserves address space) but won't incur any additional commit
> > until someone calls mprotect(PROT_WRITE) on the left-behind mapping.
>
> This limits the usefulness of the feature IMO and really is too
> specific to that one use case, suppose you want to snapshot a memory
> region to disk without having to stop a thread you can
> mremap(MREMAP_DONTUNMAP) it to another location and safely write it to
> disk knowing the faulting thread will be stopped and you can handle it
> later if it was registered with userfaultfd, if we were to also change
> it to PROT_NONE that thread would see a SEGV. There are other examples
> where you can possibly use this flag instead of VM_UFFD_WP, but
> changing the protections of the mapping prevents you from being able
> to do this without a funny signal handler dance.

We seem to have identified two use cases which require contradictory
things. We can handle this with an option. Maybe the new region's
protection bits should be specified in the flags argument. The most
general API would accept any set of mmap flags to apply to the
left-behind region, but it's probably hard to squeeze that
functionality into the existing API.

WARNING: multiple messages have this Message-ID (diff)
From: Daniel Colascione <dancol-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
To: Brian Geffon <bgeffon-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Cc: Andrew Morton
	<akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
	"Michael S . Tsirkin"
	<mst-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	linux-kernel
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-mm <linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org>,
	Linux API <linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Andy Lutomirski <luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org>,
	Will Deacon <will-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Andrea Arcangeli
	<aarcange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	Sonny Rao <sonnyrao-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Minchan Kim <minchan-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
	Joel Fernandes
	<joel-QYYGw3jwrUn5owFQY34kdNi2O/JbrIOy@public.gmane.org>,
	Yu Zhao <yuzhao-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Jesse Barnes <jsbarnes-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
	Nathan Chancellor
	<natechancellor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Florian Weimer <fweimer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>,
	"Kirill A . Shutemov"
	<kirill-oKw7cIdHH8eLwutG50LtGA@public.gmane.org>
Subject: Re: [PATCH v4] mm: Add MREMAP_DONTUNMAP to mremap().
Date: Tue, 11 Feb 2020 15:53:03 -0800	[thread overview]
Message-ID: <CAKOZuet-vDU=p0HN5904VAmb+BpePPk77R+35cp6eQNL7fJrYg@mail.gmail.com> (raw)
In-Reply-To: <CADyq12ySxau=SyyNp6VSbwmvRm6Kq1=Y62wTbQZoEAQ1XaXcuw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

On Tue, Feb 11, 2020 at 3:32 PM Brian Geffon <bgeffon-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:
>
> Hi Daniel,
>
> > What about making the
> > left-behind mapping PROT_NONE? This way, we'll still solve the
> > address-space race in Lokesh's use case (because even a PROT_NONE
> > mapping reserves address space) but won't incur any additional commit
> > until someone calls mprotect(PROT_WRITE) on the left-behind mapping.
>
> This limits the usefulness of the feature IMO and really is too
> specific to that one use case, suppose you want to snapshot a memory
> region to disk without having to stop a thread you can
> mremap(MREMAP_DONTUNMAP) it to another location and safely write it to
> disk knowing the faulting thread will be stopped and you can handle it
> later if it was registered with userfaultfd, if we were to also change
> it to PROT_NONE that thread would see a SEGV. There are other examples
> where you can possibly use this flag instead of VM_UFFD_WP, but
> changing the protections of the mapping prevents you from being able
> to do this without a funny signal handler dance.

We seem to have identified two use cases which require contradictory
things. We can handle this with an option. Maybe the new region's
protection bits should be specified in the flags argument. The most
general API would accept any set of mmap flags to apply to the
left-behind region, but it's probably hard to squeeze that
functionality into the existing API.

  reply	other threads:[~2020-02-11 23:53 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-07 20:18 [PATCH v4] mm: Add MREMAP_DONTUNMAP to mremap() Brian Geffon
2020-02-07 20:18 ` Brian Geffon
2020-02-07 20:21 ` [PATCH] mremap.2: Add information for MREMAP_DONTUNMAP Brian Geffon
2020-02-07 20:21   ` Brian Geffon
2020-02-13 12:55   ` Christian Brauner
2020-02-10  1:21 ` [PATCH v4] mm: Add MREMAP_DONTUNMAP to mremap() Andrew Morton
2020-02-10  1:21   ` Andrew Morton
2020-02-10 18:38   ` Brian Geffon
2020-02-10 18:38     ` Brian Geffon
2020-02-10 18:38     ` Brian Geffon
2020-02-10 10:45 ` Kirill A. Shutemov
2020-02-10 14:12   ` Brian Geffon
2020-02-10 14:12     ` Brian Geffon
2020-02-13 12:08     ` Kirill A. Shutemov
2020-02-13 18:20       ` Brian Geffon
2020-02-13 18:20         ` Brian Geffon
2020-02-14  0:36         ` Kirill A. Shutemov
2020-02-11 23:13 ` Daniel Colascione
2020-02-11 23:13   ` Daniel Colascione
2020-02-11 23:32   ` Brian Geffon
2020-02-11 23:32     ` Brian Geffon
2020-02-11 23:32     ` Brian Geffon
2020-02-11 23:53     ` Daniel Colascione [this message]
2020-02-11 23:53       ` Daniel Colascione
2020-02-11 23:53       ` Daniel Colascione
2020-02-14  4:09 ` [PATCH v5 1/2] " Brian Geffon
2020-02-14  4:09   ` Brian Geffon
2020-02-14  4:09   ` [PATCH v5 2/2] selftest: Add MREMAP_DONTUNMAP selftest Brian Geffon
2020-02-14  4:09     ` Brian Geffon
2020-02-14 14:28   ` [PATCH v5 1/2] mm: Add MREMAP_DONTUNMAP to mremap() Kirill A. Shutemov
2020-02-14 18:46     ` Brian Geffon
2020-02-14 18:46       ` Brian Geffon

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='CAKOZuet-vDU=p0HN5904VAmb+BpePPk77R+35cp6eQNL7fJrYg@mail.gmail.com' \
    --to=dancol@google.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=bgeffon@google.com \
    --cc=fweimer@redhat.com \
    --cc=joel@joelfernandes.org \
    --cc=jsbarnes@google.com \
    --cc=kirill@shutemov.name \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@amacapital.net \
    --cc=minchan@kernel.org \
    --cc=mst@redhat.com \
    --cc=natechancellor@gmail.com \
    --cc=sonnyrao@google.com \
    --cc=will@kernel.org \
    --cc=yuzhao@google.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.