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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 37F1FC433EF for ; Sat, 18 Dec 2021 23:06:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 81BB06B0074; Sat, 18 Dec 2021 18:06:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7A3D16B0075; Sat, 18 Dec 2021 18:06:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 61DFA6B0078; Sat, 18 Dec 2021 18:06:35 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0089.hostedemail.com [216.40.44.89]) by kanga.kvack.org (Postfix) with ESMTP id 4B6696B0074 for ; Sat, 18 Dec 2021 18:06:35 -0500 (EST) Received: from smtpin31.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 058E8180FF4D5 for ; Sat, 18 Dec 2021 23:06:25 +0000 (UTC) X-FDA: 78932450730.31.4E6A926 Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com [209.85.208.41]) by imf22.hostedemail.com (Postfix) with ESMTP id 20C51C003A for ; Sat, 18 Dec 2021 23:06:24 +0000 (UTC) Received: by mail-ed1-f41.google.com with SMTP id o20so22371347eds.10 for ; Sat, 18 Dec 2021 15:06:24 -0800 (PST) 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=GyKRP/I6esBlhYrEjQLh8BM6N5zOayyRIq/pW8rIAMo=; b=fsSA+hM1gQ3dj9V0r6PVdcqg8GIMnU0H2LArYw6UfIkmSDWA7xyVG7fNKpz/dEkoEQ SxpEjrlIEqHKNjkl7T6pCX2g5eSPHmzbO0hZDxnUt0UDbVn1IlADDl8KoulkmMpTXprj XC5VDGy1beoXsKOs8RdX7NwWeePSeaw8DuiSI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GyKRP/I6esBlhYrEjQLh8BM6N5zOayyRIq/pW8rIAMo=; b=Q3H3hY0U/TvqlL8GiUu3HMyb9kUQ1RBeVdOfWKEf+p/SzsxN1ZmBgupDYWRrqiPfO6 M1AivOySfPGiYxNDaJR1CV3SHmT9s0ZXvCd4tgt0wragywzcnUKp9V1ffq2Sq2NS3aqg npWBcyLnZbpWIbtuA74l/C6CgNMtENqfPHewvJ2I0BXUWjgZ/s0K5Z95evMf7Qix6NQT hbWCI5L61JGEHaxm+CBXAQrB1FaCEWBC19Yuhd91RyjjMSk5+4ThZCDrRq2vbOIdtcmE VlKHijXY0gwEcA05g9pO6ef0U5U88hpW2PIxAvsCzYzVv8ozeQi+Dp+e5PXziODUZ0xx NNIA== X-Gm-Message-State: AOAM533je8baCIM7aSDb0YMhVY00Z0K9D2OYtk7ohyUm0sDfisUG2UR0 ExFdvrAgNXrEJJVMTx9CQzrExwmrcPMy9137o0o= X-Google-Smtp-Source: ABdhPJztEkEf/qi6DK3JrGNSZ9uXxvX+QdbFCIE/ew+PyorRKw+Mj42P9RGVN9WpCMPB2UFhAMc8YQ== X-Received: by 2002:a17:906:b24a:: with SMTP id ce10mr7463152ejb.20.1639868783237; Sat, 18 Dec 2021 15:06:23 -0800 (PST) Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com. [209.85.221.41]) by smtp.gmail.com with ESMTPSA id 24sm3920120ejg.47.2021.12.18.15.06.22 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Dec 2021 15:06:23 -0800 (PST) Received: by mail-wr1-f41.google.com with SMTP id q16so11586227wrg.7 for ; Sat, 18 Dec 2021 15:06:22 -0800 (PST) X-Received: by 2002:adf:f54e:: with SMTP id j14mr7529281wrp.442.1639868771784; Sat, 18 Dec 2021 15:06:11 -0800 (PST) MIME-Version: 1.0 References: <20211217113049.23850-1-david@redhat.com> <20211217113049.23850-7-david@redhat.com> <54c492d7-ddcd-dcd0-7209-efb2847adf7c@redhat.com> <17bfb2fd-da51-1264-513f-f9e928ec36c6@redhat.com> <20211218225211.epa4u6mtjnvgkw4x@box.shutemov.name> In-Reply-To: <20211218225211.epa4u6mtjnvgkw4x@box.shutemov.name> From: Linus Torvalds Date: Sat, 18 Dec 2021 15:05:55 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v1 06/11] mm: support GUP-triggered unsharing via FAULT_FLAG_UNSHARE (!hugetlb) To: "Kirill A. Shutemov" Cc: David Hildenbrand , Linux Kernel Mailing List , Andrew Morton , Hugh Dickins , David Rientjes , Shakeel Butt , John Hubbard , Jason Gunthorpe , Mike Kravetz , Mike Rapoport , Yang Shi , "Kirill A . Shutemov" , Matthew Wilcox , Vlastimil Babka , Jann Horn , Michal Hocko , Nadav Amit , Rik van Riel , Roman Gushchin , Andrea Arcangeli , Peter Xu , Donald Dutile , Christoph Hellwig , Oleg Nesterov , Jan Kara , Linux-MM , "open list:KERNEL SELFTEST FRAMEWORK" , "open list:DOCUMENTATION" Content-Type: text/plain; charset="UTF-8" Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=fsSA+hM1; spf=pass (imf22.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.208.41 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org; dmarc=none X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 20C51C003A X-Stat-Signature: 3yr4gou5ie5wdhiizysrz5dhcy93i9jm X-HE-Tag: 1639868784-7721 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 Sat, Dec 18, 2021 at 2:52 PM Kirill A. Shutemov wrote: > > So you are saying that if a GUP user wants to see changes made by > userspace to the page after the GUP it must ask for FOLL_WRITE, even if it > doesn't have intend to write to the page? Yup. Put the onus very clearly on GUP. It's a very special operation, and it's one of the operations that cause a lot of problems for the VM code. It's by no means the _only_ one - we've got a lot of other things that cause issues - but I think it's very clear that GUP is very very special, and nobody should say "I want GUP to do whatever". There are two cases for GUP: - look up the page as it is *NOW* - look up the page in order to see any future state on it (and possibly modify it) that "any future state" is a fundamentally much heavier operation. It's the one that really *has* to get rid of any sharing, and it has to make sure no sharing happens in the future either. So ii it is an anonymous page, it basically needs to act like a write. Even if that page is then used only for reading. Note that here that "if it's anonymous" is kind of a big deal. If it's a shared file-mapped page, at that point it's "just another reference". It's potentially problematic even in that case (think of "truncate()" that tries to force-unmap all pages from VM's), but for the shared case the answer is "if you truncate it and disassociate the page from the mapping, it's _your_ problem. And once it acts as a write, and once it does that COW and we have exclusive access to it, it might as well be just writable and dirty. You've done the expensive part already. You've forced it to be private to that VM. And this was all triggered by the user doing something very special, so no amount of "but POSIX" or whatever matters. GUP is not great. If you use GUP, you get to deal with the downsides. Linus