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 AA778C433F5 for ; Wed, 2 Mar 2022 20:38:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 121C98D0002; Wed, 2 Mar 2022 15:38:16 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A9968D0001; Wed, 2 Mar 2022 15:38:16 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E64148D0002; Wed, 2 Mar 2022 15:38:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0030.hostedemail.com [216.40.44.30]) by kanga.kvack.org (Postfix) with ESMTP id D27318D0001 for ; Wed, 2 Mar 2022 15:38:15 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 82F95181E7296 for ; Wed, 2 Mar 2022 20:38:15 +0000 (UTC) X-FDA: 79200608550.27.8D9ECD6 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf25.hostedemail.com (Postfix) with ESMTP id 1B488A0011 for ; Wed, 2 Mar 2022 20:38:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646253494; 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=nMsfn4Rs0wG7spUhGbyLnPRwbrnVAsF3QEAbPCpAwa0=; b=N/0AO/A+zAjeM1EVWvjs+Z0nFpDP/EsK4AawLZChMTeWojNQfx1Of5RirQIfMniFg8ghd6 k8YvbEkXc/rfLgndxoKs1tzEg8uR2ZnaXAqh2m9KMJ42B1OVqeWXrJBf0uuKqwfFndFsu8 GPiAFqTQN0sFBovm1fWXiQ0uBh5ZgKs= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-45-7FTXtzbcNaqhjLR4--uzhA-1; Wed, 02 Mar 2022 15:38:13 -0500 X-MC-Unique: 7FTXtzbcNaqhjLR4--uzhA-1 Received: by mail-wr1-f69.google.com with SMTP id a5-20020adfdd05000000b001f023fe32ffso1050233wrm.18 for ; Wed, 02 Mar 2022 12:38:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:cc:references:from:organization:subject :in-reply-to:content-transfer-encoding; bh=nMsfn4Rs0wG7spUhGbyLnPRwbrnVAsF3QEAbPCpAwa0=; b=61XoiKtbzLCIqZJf6o4QMW+kxOT+H5B/R+w8XCh/gMpL3MHj/ze7A0pcYchijva2h5 FZbSw4b7F3mJeS+ul30SDSpTwTxk2Gnd8+aMsNWK0k0itTcCmGmrQ7XOCFKxv7KrTe6N +22bK9mxdJnSGAeGSt2gmbC+CijRdvLUgjBkH6yLK8nE6tmJzHT723/HSJfe1KXUF+lV 5rDEwHU/Lc4Lm1EedRyq5V4L/Jm2+pImaa2h0vA1Ab8h/BFrK+audG6YnxO5+tUjdY3D b43OC253AMBFFZnJk+3CwiPIg4epL4USX12+R8JjFOu2UYS0Jw+8Yej31RZtJ0sw8kti peBg== X-Gm-Message-State: AOAM533Cpiq6taDrP1OvedUYEeVJUAuuO1bOejJAO/BRerUZGyszAIb1 wrMzpD6qx5z3Ij8oY+1SmE8mqON7k0+aRZDBk3odBmxNwP45lHkgphgR2U4PdeDaxwYGAJzsaiF CZAHsNPUQRAQ= X-Received: by 2002:a05:6000:2c9:b0:1f0:49aa:d347 with SMTP id o9-20020a05600002c900b001f049aad347mr1085002wry.453.1646253492125; Wed, 02 Mar 2022 12:38:12 -0800 (PST) X-Google-Smtp-Source: ABdhPJy9nsVwmkEM6/m/0SMuz52ZfnM1DW3UGN+YBkJuzcILW720TEYWY5MncvxoFHCV5hIHl1XqBA== X-Received: by 2002:a05:6000:2c9:b0:1f0:49aa:d347 with SMTP id o9-20020a05600002c900b001f049aad347mr1084964wry.453.1646253491815; Wed, 02 Mar 2022 12:38:11 -0800 (PST) Received: from ?IPV6:2003:cb:c709:be00:9509:b3b1:97e2:ef4c? (p200300cbc709be009509b3b197e2ef4c.dip0.t-ipconnect.de. [2003:cb:c709:be00:9509:b3b1:97e2:ef4c]) by smtp.gmail.com with ESMTPSA id p190-20020a1c29c7000000b00381227166b2sm68644wmp.41.2022.03.02.12.38.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Mar 2022 12:38:11 -0800 (PST) Message-ID: Date: Wed, 2 Mar 2022 21:38:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 To: Jason Gunthorpe Cc: linux-kernel@vger.kernel.org, Andrew Morton , Hugh Dickins , Linus Torvalds , David Rientjes , Shakeel Butt , John Hubbard , 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 , Liang Zhang , Pedro Gomes , Oded Gabbay , linux-mm@kvack.org References: <20220224122614.94921-1-david@redhat.com> <20220224122614.94921-13-david@redhat.com> <20220302165559.GU219866@nvidia.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH RFC 12/13] mm/gup: trigger FAULT_FLAG_UNSHARE when R/O-pinning a possibly shared anonymous page In-Reply-To: <20220302165559.GU219866@nvidia.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 1B488A0011 X-Stat-Signature: wjkmkey6tz4kozibsdtu9ggmuz75cga3 Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="N/0AO/A+"; spf=none (imf25.hostedemail.com: domain of david@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1646253494-909448 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 02.03.22 17:55, Jason Gunthorpe wrote: > On Thu, Feb 24, 2022 at 01:26:13PM +0100, David Hildenbrand wrote: >> Whenever GUP currently ends up taking a R/O pin on an anonymous page that >> might be shared -- mapped R/O and !PageAnonExclusive() -- any write fault >> on the page table entry will end up replacing the mapped anonymous page >> due to COW, resulting in the GUP pin no longer being consistent with the >> page actually mapped into the page table. >> >> The possible ways to deal with this situation are: >> (1) Ignore and pin -- what we do right now. >> (2) Fail to pin -- which would be rather surprising to callers and >> could break user space. >> (3) Trigger unsharing and pin the now exclusive page -- reliable R/O >> pins. > Hi Jason, > How does this mesh with the common FOLL_FORCE|FOLL_WRITE|FOLL_PIN > pattern used for requesting read access? Can they be converted to > just FOLL_WRITE|FOLL_PIN after this? Interesting question, I thought about this in detail yet, let me give it a try: IIRC, the sole purpose of FOLL_FORCE in the context of R/O pins is to enforce the eventual COW -- meaning we COW (via FOLL_WRITE) even if we don't have the permissions to write (via FOLL_FORCE), to make sure we most certainly have an exclusive anonymoous page in a MAP_PRIVATE mapping. Dropping only the FOLL_FORCE would make the FOLL_WRITE request fail if the mapping is currently !VM_WRITE (but is VM_MAYWRITE), so that wouldn't work. I recall that we don't allow pinning the zero page ("special pte", !vm_normal_page()). So if you have an ordinary MAP_PRIVATE|MAP_ANON mapping, you will now only need a "FOLL_READ" and have a reliable pin, even if not previously writing to every page. It would we different with other MAP_PRIVATE file mappings I remember: With FOLL_FORCE|FOLL_WRITE|FOLL_PIN we'd force placement of an anonymous page, resulting in the R/O (long-term ?) pin not observing consecutive file changes. With a pure FOLL_READ we'd still observe file changes as we don't trigger a write fault. BUT, once we actually write to the private mapping via the page table, the GUP pin would go out of sync with the now-anonymous page mapped into the page table. However, I'm having a hard time answering what's actually expected? It's really hard to tell what the user wants with MAP_PRIVATE file mappings and stumbles over a !anon page (no modifications so far): (a) I want a R/O pin to observe file modifications. (b) I want the R/O pin to *not* observe file modifications but observe my (eventual? if any) private modifications, Of course, if we already wrote to that page and now have an anon page, it's easy: we are already no longer following file changes. Maybe FOLL_PIN would already do now what we'd expect from a R/O pin -- (a), maybe not. I'm wondering if FOLL_LONGTERM could give us an indication whether (a) or (b) applies. -- Thanks, David / dhildenb