All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ralf Ramsauer <ralf.ramsauer@oth-regensburg.de>
To: David Hildenbrand <david@redhat.com>, <linux-mm@kvack.org>
Cc: Wolfgang Mauerer <wolfgang.mauerer@oth-regensburg.de>,
	Mario Mintel <mario.mintel@st.oth-regensburg.de>
Subject: Re: [EXT] Re: COW in userspace
Date: Mon, 23 Aug 2021 12:16:27 +0200	[thread overview]
Message-ID: <bde0d9ae-4d29-13cf-8ecd-53f33bde6cc7@oth-regensburg.de> (raw)
In-Reply-To: <8bc6b208-2b4c-03d6-c9c3-c36daf55d3f7@redhat.com>



On 23/08/2021 10:02, David Hildenbrand wrote:
> On 20.08.21 15:13, Ralf Ramsauer wrote:
>> Dear mm folks,
>>
>> I have an issue, where it would be great to have a COW-backed virtual
>> memory area within an userspace process. I know there's the possibility
>> to have a file-backed MAP_SHARED vma, which is later duplicated with
>> MAP_PRIVATE, but that's not exactly what I'm looking for.
>>
>> Say I have an anonymous page-aligned VMA a, with MAP_PRIVATE and
>> PROT_RW. Userspace happily writes to/reads from it. At some point in
>> time, I want to 'snapshot' that single VMA within the context of the
>> process and without the need to fork(). Say there's something like
>>
>>    a = mmap(0, len, PROT_RW, MAP_ANON | MAP_POPULATE, -1, 0);
>>    [... fill a ...]
>>
>>    b = mmdup(a, len, PROT_READ);
>>
>> b shall be the new base pointer of a new VMA that is backed by COW
>> mechanisms. After mmdup, those regular COW mechanisms do the rest: both
>> VMAs (a and b) will fault on subsequent writes and duplicate the
>> previously shared physical mapping, pretty much what cow_fault or
>> shared_fault does.
>>
>> Afaict, this, or at least something like this is currently not supported
>> by the kernel. Is that correct? If so, why? Generally spoken, is it a
>> bad idea?
> 
> Not sure if it helps (most probably not), QEMU uses uffd-wp for
> background snapshots of VM memory. It's different, though, as you'll
> only have a single mapping and will be catching modifications to your
> single mapping, such that you can "safe away" relevant snapshot pages
> before any modifications.

Thanks for the pointer, David. I'll have a look.

> 
> You mention "both VMAs (a and b) will fault on subsequent writes", so
> would you actually be allowing PROT_WRITE access to b ("snapshot")?
> 

In general, yes, both should be allowed to be PROT_WRITE. So no matter
"which side" causes the fault, simply both will lead to duplication.

If it would make things easier, then it would also be absolutely fine to
have the snapshot PROT_READ, which would suffice my requirements as well.

Thanks
  Ralf


  reply	other threads:[~2021-08-23 10:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-20 13:13 COW in userspace Ralf Ramsauer
2021-08-20 23:12 ` Jerome Glisse
2021-08-23  8:02 ` David Hildenbrand
2021-08-23 10:16   ` Ralf Ramsauer [this message]
2021-08-23 10:33     ` [EXT] " David Hildenbrand
2021-08-23 10:49       ` Ralf Ramsauer

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=bde0d9ae-4d29-13cf-8ecd-53f33bde6cc7@oth-regensburg.de \
    --to=ralf.ramsauer@oth-regensburg.de \
    --cc=david@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=mario.mintel@st.oth-regensburg.de \
    --cc=wolfgang.mauerer@oth-regensburg.de \
    /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.