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 8FC24C432BE for ; Mon, 23 Aug 2021 08:02:38 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3C3696135A for ; Mon, 23 Aug 2021 08:02:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3C3696135A Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 7FDAD6B006C; Mon, 23 Aug 2021 04:02:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7AE1D6B0072; Mon, 23 Aug 2021 04:02:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 69C538D0001; Mon, 23 Aug 2021 04:02:37 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0233.hostedemail.com [216.40.44.233]) by kanga.kvack.org (Postfix) with ESMTP id 509DA6B006C for ; Mon, 23 Aug 2021 04:02:37 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E3E74253D9 for ; Mon, 23 Aug 2021 08:02:36 +0000 (UTC) X-FDA: 78505603512.33.A0FB5F1 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf23.hostedemail.com (Postfix) with ESMTP id 8DC4690000AD for ; Mon, 23 Aug 2021 08:02:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1629705756; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=gnWIJCOI4FCG5QsUEcfQXC1DyY+Nl/fxCM6/5b58lTw=; b=VZ8k/Y4bM5Ztg/lG4JAuG2PX812ZTVn9S89W0z1O4/ve53LKhU8ANMmjGAftKpoL79jC9X A8xzTpFuKgjE+ffrxWwnnSlphYIGS0F2ZwDV1EdBxwR+okal+keewJ3Axpuk4EhtkGa6OE PTMD9FzjYeka+LgRVcgTUb6n/Z7CHrI= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-454-tU6olAeXPzGi7CMzXdU4kA-1; Mon, 23 Aug 2021 04:02:34 -0400 X-MC-Unique: tU6olAeXPzGi7CMzXdU4kA-1 Received: by mail-wm1-f71.google.com with SMTP id 201-20020a1c01d2000000b002e72ba822dcso3783208wmb.6 for ; Mon, 23 Aug 2021 01:02:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:cc:references:from:organization:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=gnWIJCOI4FCG5QsUEcfQXC1DyY+Nl/fxCM6/5b58lTw=; b=L9fu0MuJ5AZmZInLd5q1T8kiJOr+bVx+TiJIgvQF/IBn3WZgtEbyztoz5fW3eLrGfK 7aN4mQFt1hfEN+EWvno4Hjp4vPZg5vrT1byxsCTotcSj8O2ShGyztHYyF/W4q5mFG8o5 xDd19+Qck47LkcOdY1a7uE/GsrnCauis37UgqeWam0IA+rjvsPT3Kj6qbYQcDwNm1wVg emaeKWATVJmJXd3AsLpgWnwHDzCQQnnp77xT06yppWor3beTQPdxfxyN8Eu6FdxeqPf3 vcCFptjLetCWUiKUnZ8nwZO/W/joe9OHYrz8R3D2pVW3Nvn275SH5xR40DQAfyqDiRKP VK8w== X-Gm-Message-State: AOAM532bkobGapGVhzU4o5u/cVqSvLDHmn/fw5P65mEZv8eWv3nUYG5L jEv4spDvr9IWfPA7ctoC4UByJIQLEYDMMYmaTPq01baEubNeDDah2UWADXhCV3G5RTKFtR/lLyE WkVjB3LgVCzY= X-Received: by 2002:a7b:c441:: with SMTP id l1mr15069026wmi.69.1629705753725; Mon, 23 Aug 2021 01:02:33 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxCs4zUossOIoc1EsVNehIQxS9c25y38zOyt/nGpR3HzvEknsa7aDaje6Vp8+OrlUawm6g/Qg== X-Received: by 2002:a7b:c441:: with SMTP id l1mr15069000wmi.69.1629705753498; Mon, 23 Aug 2021 01:02:33 -0700 (PDT) Received: from ?IPv6:2003:d8:2f0a:7f00:fad7:3bc9:69d:31f? (p200300d82f0a7f00fad73bc9069d031f.dip0.t-ipconnect.de. [2003:d8:2f0a:7f00:fad7:3bc9:69d:31f]) by smtp.gmail.com with ESMTPSA id i14sm12204222wmq.40.2021.08.23.01.02.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 23 Aug 2021 01:02:33 -0700 (PDT) To: Ralf Ramsauer , linux-mm@kvack.org Cc: Wolfgang Mauerer , Mario Mintel References: From: David Hildenbrand Organization: Red Hat Subject: Re: COW in userspace Message-ID: <8bc6b208-2b4c-03d6-c9c3-c36daf55d3f7@redhat.com> Date: Mon, 23 Aug 2021 10:02:32 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US X-Rspamd-Queue-Id: 8DC4690000AD Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="VZ8k/Y4b"; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf23.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=david@redhat.com X-Rspamd-Server: rspam01 X-Stat-Signature: gs9bguzqw8pbbqpu3enayjzpjk61gaaa X-HE-Tag: 1629705756-28038 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 20.08.21 15:13, Ralf Ramsauer wrote: > Dear mm folks, >=20 > 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. >=20 > 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 >=20 > a =3D mmap(0, len, PROT_RW, MAP_ANON | MAP_POPULATE, -1, 0); > [... fill a ...] >=20 > b =3D mmdup(a, len, PROT_READ); >=20 > 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. >=20 > Afaict, this, or at least something like this is currently not supporte= d > 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=20 background snapshots of VM memory. It's different, though, as you'll=20 only have a single mapping and will be catching modifications to your=20 single mapping, such that you can "safe away" relevant snapshot pages=20 before any modifications. You mention "both VMAs (a and b) will fault on subsequent writes", so=20 would you actually be allowing PROT_WRITE access to b ("snapshot")? --=20 Thanks, David / dhildenb