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 184F4C433DF for ; Mon, 10 Aug 2020 20:52:12 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AFA222073E for ; Mon, 10 Aug 2020 20:52:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="hwkEnHVP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AFA222073E 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 278446B0002; Mon, 10 Aug 2020 16:52:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2278A6B0003; Mon, 10 Aug 2020 16:52:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 118286B0006; Mon, 10 Aug 2020 16:52:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0252.hostedemail.com [216.40.44.252]) by kanga.kvack.org (Postfix) with ESMTP id EFD646B0002 for ; Mon, 10 Aug 2020 16:52:10 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 799BA3620 for ; Mon, 10 Aug 2020 20:52:10 +0000 (UTC) X-FDA: 77135856420.03.meat85_27096e826fdd Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 4754728A4E8 for ; Mon, 10 Aug 2020 20:52:10 +0000 (UTC) X-HE-Tag: meat85_27096e826fdd X-Filterd-Recvd-Size: 6203 Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) by imf03.hostedemail.com (Postfix) with ESMTP for ; Mon, 10 Aug 2020 20:52:09 +0000 (UTC) Received: by mail-lf1-f66.google.com with SMTP id i80so5450974lfi.13 for ; Mon, 10 Aug 2020 13:52:09 -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=pPJOh2B8UqnDROYW3i9xOwYOYe8010p4GwF3JyYBmy8=; b=hwkEnHVPA+E+9rkWzxh4lStANcEMn0x+5pjB22oF01Rz3n6+aP273yOuBXeeH3qMZe wPV09IiK4VXqZDapL26ueSiQQ4i5VUG9H0Kl7MMigWmoKc//lQ+l4m/Ht/uMiYggKITQ xN83E6le55ewRr20mhhX/QL7u0YnKvAzApwbI= 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=pPJOh2B8UqnDROYW3i9xOwYOYe8010p4GwF3JyYBmy8=; b=psVUEuvqSjgcX46/j2tCqbFfrPCHGbpHj9y7RK87eQs9mAVqCuOzcTFVXA+SElWxTz hftB14+UMX0Fg570n0Y23v19stAQawzQs37/QWeMKSgmQF/K2Jon99XN8ns8aIfwJE0U iC8Izpuc7BYdrOzHYUxJYhjyF02ddCKMOORuVtwKa+xtwis3wylVy+r4b6i8Z5oDl2as GhtgkyyhExs+4vFSna2Ye0gx9+iO1FIPiggKwrEeffsYj02cay7JNarvg8wmZz3H/4ti e2s2+FnxgSa3M1x8iiCYMMCuveYAZiIul1OdaSnEw9+WOfEjf6k0EeUInqeml7cxT7qS wOig== X-Gm-Message-State: AOAM532ERE9ICg/MGYyygGMpAz4uiijHtJKR0kAgevUTbzyoNnLWde5p OTxr5z+XYVL6MTUTRfYc4UbVKmD/93A= X-Google-Smtp-Source: ABdhPJwYR5JCZaxXYEeFcyyVmzovJRPGMAfCVyExuSmzSIZ5B942bS8Bv3SBye393VquSuA3qVqS0g== X-Received: by 2002:a19:431c:: with SMTP id q28mr1452068lfa.211.1597092727113; Mon, 10 Aug 2020 13:52:07 -0700 (PDT) Received: from mail-lf1-f42.google.com (mail-lf1-f42.google.com. [209.85.167.42]) by smtp.gmail.com with ESMTPSA id c5sm11044173lfb.24.2020.08.10.13.52.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 Aug 2020 13:52:06 -0700 (PDT) Received: by mail-lf1-f42.google.com with SMTP id b11so5459327lfe.10 for ; Mon, 10 Aug 2020 13:52:05 -0700 (PDT) X-Received: by 2002:a05:6512:241:: with SMTP id b1mr1452946lfo.125.1597092725337; Mon, 10 Aug 2020 13:52:05 -0700 (PDT) MIME-Version: 1.0 References: <20200810145701.129228-1-peterx@redhat.com> <20200810191520.GA132381@xz-x1> In-Reply-To: <20200810191520.GA132381@xz-x1> From: Linus Torvalds Date: Mon, 10 Aug 2020 13:51:49 -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: 4754728A4E8 X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam02 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 12:15 PM Peter Xu wrote: > > My previous understanding was that although COW is always safe, we should still > avoid it when unnecessary because it's still expensive. Currently we will do > enforced COW only if should_force_cow_break() returns true, which seems to be a > good justification of when to ask for the enforcement. It's not the _enforcement_ I worry about. It's the _users_. So COW is always the safe thing to do, but as you say, it can be expensive (although we actually seemed to get a robot that claimed it sped up some test benchmark, it wasn't clear why). But because not breaking COW can be very subtly unsafe - considering that we had this behavior for over two decades - I think the users that decide to not break COW need to explain why it is safe for them. See what I'm saying? That's why an explicit FOLL_READ_WRONG_SIDE_COW_OK flag would be good, because it would force people to *think* about what they are doing, and explain why it's ok to do that unsafe thing, and get a page that may actually end up not being your page at all! > + * @FAULT_FLAG_BREAK_COW: Do COW explicitly for the fault (even for read). > + * Please read FOLL_BREAK_COW for more information. This comment is useless - because it's aimed at the wrong people. It's aimed at the people who already know they want to break COW. They understand, and they are doing the safe thing. The case I worry about is the people who do NOT say "break COW". Not because they are smart and know what they are doing, but because they don't think about the issue. > Userfaultfd-wp should not care about this because it's not a write operation, Ok, I will *definitely* not be applying tyhis patch, beause you don't even understand what the problem is. The fact is, A READ operation that doesn't break COW can GET THE WRONG ANSWER. Why? If you have two (threaded) processes A and B, who have that shared COW page, what can happen is: - A does a READ operation using get_follow_page, and gets the shared page - another thread in A ends up doing an unmap operation - B does write to the page, and causes a COW, but now doesn't see the A mapping at all any more, so takes over the page and writes to it - the original get_follow_page() thread in A is now holding a page that contains data that wasn't written by A See? That's the whole point. It doesn't _matter_ if you're only reading the data, without the COW you may be reading the _wrong_ data. So no. I will not be applying the patch, because you apparently didn't understand why reading needs to do a COW. Linus