From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B97E0C4320A for ; Mon, 23 Aug 2021 10:16:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3538361246 for ; Mon, 23 Aug 2021 10:16:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3538361246 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=oth-regensburg.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id B12D76B006C; Mon, 23 Aug 2021 06:16:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AC2726B0072; Mon, 23 Aug 2021 06:16:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9B16B8D0001; Mon, 23 Aug 2021 06:16:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0169.hostedemail.com [216.40.44.169]) by kanga.kvack.org (Postfix) with ESMTP id 7E5E06B006C for ; Mon, 23 Aug 2021 06:16:31 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 163538249980 for ; Mon, 23 Aug 2021 10:16:31 +0000 (UTC) X-FDA: 78505940982.13.75E7B29 Received: from mta01.hs-regensburg.de (mta01.hs-regensburg.de [194.95.104.11]) by imf09.hostedemail.com (Postfix) with ESMTP id 1B8063000112 for ; Mon, 23 Aug 2021 10:16:29 +0000 (UTC) Received: from E16S03.hs-regensburg.de (e16s03.hs-regensburg.de [IPv6:2001:638:a01:8013::93]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "E16S03", Issuer "E16S03" (not verified)) by mta01.hs-regensburg.de (Postfix) with ESMTPS id 4GtSnl58fmzy2y; Mon, 23 Aug 2021 12:16:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oth-regensburg.de; s=mta01-20160622; t=1629713787; bh=S1DPDdRm5TwLKRHx84zzNuul+0ufIO+a7Wp2t0HUe5I=; h=Subject:To:CC:References:From:Date:In-Reply-To:From; b=C9yOsEgCXuck9Xjt8Nzbj6lGUm2sLEdR4bqKum9q/mKpWR3oL41h6XRacdLa3j6Qt QB37n9IhkR1ec/Doy2xD5hEhHG50Me2it0z7LThAtKQwDd1WUKNyqxh/6vr1qFIjGP qSK1c0k0ZvV61izeZZMfOypo+MG3wjZUXKCiypqnEPvIUVVGY7tic34b7YNT3leGpw 3T6w7lnRz2nKK33Mft0R5fk07pl3XGgocpFJMayPUoXwnYcukhS1fKyBOFMDOAZutQ tXaDX50pVvoajd9WhCtM7lOE+rgDBqywrtO/w1GRE5pVK9iH0zsugmG5cSt8W6EHa1 cNipSSt2Mb/Yg== Received: from [IPv6:2001:638:a01:8061:5c51:6883:5436:5db] (2001:638:a01:8013::138) by E16S03.hs-regensburg.de (2001:638:a01:8013::93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Mon, 23 Aug 2021 12:16:27 +0200 Subject: Re: [EXT] Re: COW in userspace To: David Hildenbrand , CC: Wolfgang Mauerer , Mario Mintel References: <8bc6b208-2b4c-03d6-c9c3-c36daf55d3f7@redhat.com> From: Ralf Ramsauer Message-ID: Date: Mon, 23 Aug 2021 12:16:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <8bc6b208-2b4c-03d6-c9c3-c36daf55d3f7@redhat.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-US X-Originating-IP: [2001:638:a01:8013::138] X-ClientProxiedBy: E16S02.hs-regensburg.de (2001:638:a01:8013::92) To E16S03.hs-regensburg.de (2001:638:a01:8013::93) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=oth-regensburg.de header.s=mta01-20160622 header.b=C9yOsEgC; dmarc=pass (policy=none) header.from=oth-regensburg.de; spf=pass (imf09.hostedemail.com: domain of ralf.ramsauer@oth-regensburg.de designates 194.95.104.11 as permitted sender) smtp.mailfrom=ralf.ramsauer@oth-regensburg.de X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 1B8063000112 X-Stat-Signature: piu19d85ep8tu86n44fifzg88yyertde X-HE-Tag: 1629713789-274565 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 possibilit= y >> 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 >> >> =C2=A0=C2=A0 a =3D mmap(0, len, PROT_RW, MAP_ANON | MAP_POPULATE, -1, = 0); >> =C2=A0=C2=A0 [... fill a ...] >> >> =C2=A0=C2=A0 b =3D 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: bot= h >> 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 support= ed >> by the kernel. Is that correct? If so, why? Generally spoken, is it a >> bad idea? >=20 > 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. >=20 > You mention "both VMAs (a and b) will fault on subsequent writes", so > would you actually be allowing PROT_WRITE access to b ("snapshot")? >=20 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