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=-4.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 240DEC433E0 for ; Mon, 10 Aug 2020 16:47:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BFE02207FF for ; Mon, 10 Aug 2020 16:47:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="C/BnDPNL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BFE02207FF Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 210F76B0002; Mon, 10 Aug 2020 12:47:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1C1D46B0003; Mon, 10 Aug 2020 12:47:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D7D56B0006; Mon, 10 Aug 2020 12:47:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0253.hostedemail.com [216.40.44.253]) by kanga.kvack.org (Postfix) with ESMTP id ED66B6B0002 for ; Mon, 10 Aug 2020 12:47:43 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 572D24857 for ; Mon, 10 Aug 2020 16:47:43 +0000 (UTC) X-FDA: 77135240406.13.vase74_090eb9226fdb Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id 1999D18140B72 for ; Mon, 10 Aug 2020 16:47:43 +0000 (UTC) X-HE-Tag: vase74_090eb9226fdb X-Filterd-Recvd-Size: 5633 Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by imf31.hostedemail.com (Postfix) with ESMTP for ; Mon, 10 Aug 2020 16:47:42 +0000 (UTC) Received: by mail-lj1-f196.google.com with SMTP id w25so10314252ljo.12 for ; Mon, 10 Aug 2020 09:47:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FysGtb8inXqSIawN5ojOBaunBDDu9d2yxrSJc+Eh5Ik=; b=C/BnDPNLO6j29yT981hNypIvExpmF7gUDXGhgnPGt3Bkot3nAwqB7apErwKMe/ijP0 xB+rnSLzE2Euv1HRTA66M+lDKN7cAazwWhR/3MA7Zbvlf/LSXOrSBDSbY6pN5rCsHt1i QOil+ZLfX+hf6wzPRkMgEz9Irv6W18qws41mM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FysGtb8inXqSIawN5ojOBaunBDDu9d2yxrSJc+Eh5Ik=; b=Sw5WUCXY++ROzCuEw1dsj44rhe6lqzvASKkuwJPZUe+OdchZt0Fe1U5yizFLr1PuP4 i0ylwCTLLelYx9Z+RYh8dSgFc/vxqiwxy4VJTE29tUpzcaTHQEDxtp1D6UVvjboTJuB0 ng6BmWk9KyCZImQzscnw0lFnCp/QqMZ2XHJEt1DApfLLI49QvWLYzBZWHNN+VGwxCJBa jaGpsJziv/vKBXxtPrBIe2vcCLmFgYYmIilU7SYhjVff/r0xLUnl6Q7d96yo80x2Jkrw wpR7Yjshlh2jrr+G544Zl1IF5A7laEszVNb2oqebSPfbTp7n4k4h9Kn4nviL5vAa5Uo/ mfTg== X-Gm-Message-State: AOAM530j+9UZi8fg38sGQ68phvM1+gZ1B0GZIsLpJ17O00B7De2/h+E+ 76L4IvwrPGiBmFlyd9n9a66zdIHU7No= X-Google-Smtp-Source: ABdhPJyHRDvevsoGJ5VdiE0Oui3LsncB7vI8m6oQ5VUQAIsAoMChZiLsb60bgRENYKUjF7O/OqI1LA== X-Received: by 2002:a2e:7c15:: with SMTP id x21mr1017968ljc.211.1597078059961; Mon, 10 Aug 2020 09:47:39 -0700 (PDT) Received: from mail-lj1-f170.google.com (mail-lj1-f170.google.com. [209.85.208.170]) by smtp.gmail.com with ESMTPSA id a7sm9398805ljk.2.2020.08.10.09.47.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Aug 2020 09:47:39 -0700 (PDT) Received: by mail-lj1-f170.google.com with SMTP id z14so10369148ljm.1 for ; Mon, 10 Aug 2020 09:47:38 -0700 (PDT) X-Received: by 2002:a2e:9a11:: with SMTP id o17mr975125lji.314.1597078058439; Mon, 10 Aug 2020 09:47:38 -0700 (PDT) MIME-Version: 1.0 References: <20200810145701.129228-1-peterx@redhat.com> In-Reply-To: <20200810145701.129228-1-peterx@redhat.com> From: Linus Torvalds Date: Mon, 10 Aug 2020 09:47:22 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] mm/gup: Allow real explicit breaking of COW To: Peter Xu Cc: Linux-MM , Linux Kernel Mailing List , Andrew Morton , Marty Mcfadden , Andrea Arcangeli , Jann Horn , Christoph Hellwig , Oleg Nesterov , Kirill Shutemov , Jan Kara Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 1999D18140B72 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam03 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 Mon, Aug 10, 2020 at 7:57 AM Peter Xu wrote: > > One solution is actually already mentioned in commit 17839856fd58, which is to > provide an explicit BREAK_COW scemantics for enforced COW. Then we can still > use FAULT_FLAG_WRITE to identify whether this is a "real write request" or an > "enfornced COW (read) request". I think the patch is fine, but during discussions we also discussed having the flag the other way around, in order to have the default be "break COW", and the use cases that explicitly know they can handle the ambiguity would have to say so explicitly with a "don't break COW" bit. I don't think this matters in theory, but in practice I think it would be a good thing as documentation. Because FAULT_FLAG_BREAK_COW doesn't really tell you anything: breaking COW is "always safe". In contrast, a "FAULT_FLAG_DONT_COW" bit could be accompanied with a note like "I don't care which side I get - I'm not going to keep track of the page, I just want random data, and it's ok if I get it from another forked process". In fact, maybe it shouldn't be called "DONT_COW", but more along the lines of those semantics of "READ_WRONG_SIDE_COW_OK", so that people who use the bit have to _think_ about it. I think comments in general should be there. Looking at your patch, for example, I go "Hmm" when I see this part: - if (userfaultfd_pte_wp(vma, *vmf->pte)) { + if ((vmf->flags & FAULT_FLAG_WRITE) && + userfaultfd_pte_wp(vma, *vmf->pte)) { pte_unmap_unlock(vmf->pte, vmf->ptl); return handle_userfault(vmf, VM_UFFD_WP); } and I go "ok, for reads with COW breaking, we'll just silently break the COW and not do VM_UFFD_WP?" An explanation of why that is the right thing to do would be good. And no, I don't mean "UFFD doesn't want a WP fault in this case". I mean literally why "we do want the silent COW, but UFFD doesn't care about it". End result: I think the patch is fine, but the reason we had discussion about it and the reason it wasn't done initially was that you get all these kinds of subtle behavior differences, and I think they need clarifying. Linus