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=-14.8 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1, USER_IN_DEF_DKIM_WL 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 C1723C63777 for ; Thu, 3 Dec 2020 05:37:02 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id F13E120BED for ; Thu, 3 Dec 2020 05:37:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F13E120BED Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DF41E6B005C; Thu, 3 Dec 2020 00:37:00 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D7B2E6B005D; Thu, 3 Dec 2020 00:37:00 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C6A5B6B0068; Thu, 3 Dec 2020 00:37:00 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0203.hostedemail.com [216.40.44.203]) by kanga.kvack.org (Postfix) with ESMTP id AC7446B005C for ; Thu, 3 Dec 2020 00:37:00 -0500 (EST) Received: from smtpin07.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 72C7A1EE6 for ; Thu, 3 Dec 2020 05:37:00 +0000 (UTC) X-FDA: 77550862200.07.slope17_2c0ff1c273b9 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin07.hostedemail.com (Postfix) with ESMTP id 5733A1803F9AC for ; Thu, 3 Dec 2020 05:37:00 +0000 (UTC) X-HE-Tag: slope17_2c0ff1c273b9 X-Filterd-Recvd-Size: 5742 Received: from mail-ot1-f67.google.com (mail-ot1-f67.google.com [209.85.210.67]) by imf45.hostedemail.com (Postfix) with ESMTP for ; Thu, 3 Dec 2020 05:36:59 +0000 (UTC) Received: by mail-ot1-f67.google.com with SMTP id b62so711171otc.5 for ; Wed, 02 Dec 2020 21:36:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=9cw/bjqotF2vwQmETaOHufIj7nZd76v7wUjUpgL4QyE=; b=kNzEbJ/RtYRjNF8qQ577G5fUf/dItIJhDicyhOkL6p8Hw/ONcBdmiwFQrDhKoBvEG/ hpB7FWNfD/8eb1w2wO4oUtthh7jEI9L2ebxQgcPv/ggDBeQxANSL6Tee/YeZOO92ECsg 8WCV3Z8Pi44W8Qhg5B9MaGGOIbTU5B32PBkW34Nyx12jHOe1uqZal1R6qxGbTVsTK2os rSjU1qyUxGmbpUzycKEmPqxa0NZPzBLnPeuFhdNaQjJ9bYyWWfZ02dC7a/SguGu1TErg Y0RrNGeYLsUbsaUjyBN7PER/VSTou2gBUEQVBUJDYhb1LsxP5ygBocRVb3qOWwytvxIn lOrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:in-reply-to:message-id :references:user-agent:mime-version; bh=9cw/bjqotF2vwQmETaOHufIj7nZd76v7wUjUpgL4QyE=; b=Yc7A2Wqj4Brk+CuVcx9m/7igOtFNW7yE+P8KroQ4t9t+mpbuwiOT3QwHMpCOXrEJRM qG/PryewIalSStkcBp3Dv6bsJ9TryWNnuxMQrHdFV1XiULHnKbK73XBjFsDRoh0Lu4gT v7LkMwGs/ibRPUuJN8zQwGtTL0Uy9zkIJ1g+WhPhHYJTm3Hp9dfL4c7M8hKlhtzJIwha EprtikFzGXvzad4FjjdZVKFo1IqubKXrNSm6gsf9AnGXyQUOgtrj7OiVAxeyltZNB3uH maE2EdMgQ+acI71v2z0riIXN1+cVms2diDyDTQQ8QwvbBYK3eFwkOVURS3GBeDR5u9Ol 5P4Q== X-Gm-Message-State: AOAM531bcLuiZ+envBKl76fNkM7odj2nvy02kcxA+5eX3YK4+VYJILS8 +eNkpipxDh8KcGGzi0b9cHP2KA== X-Google-Smtp-Source: ABdhPJxkE5M9jbZNtgHUOQe8EXbxGoVtxKmZFcrrGGYHPCcUpVVlB0nDWwo3S98JqAEJL+l1zOeiBg== X-Received: by 2002:a9d:6d05:: with SMTP id o5mr1008914otp.158.1606973818985; Wed, 02 Dec 2020 21:36:58 -0800 (PST) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id i24sm9382ood.0.2020.12.02.21.36.57 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Wed, 02 Dec 2020 21:36:58 -0800 (PST) Date: Wed, 2 Dec 2020 21:36:45 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Peter Xu cc: Hugh Dickins , Andrea Arcangeli , Matthew Wilcox , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Andrew Morton , Mike Rapoport , David Hildenbrand Subject: Re: [PATCH v2] mm: Don't fault around userfaultfd-registered regions on reads In-Reply-To: <20201202234117.GD108496@xz-x1> Message-ID: References: <20201130230603.46187-1-peterx@redhat.com> <20201201125927.GB11935@casper.infradead.org> <20201201223033.GG3277@xz-x1> <20201202234117.GD108496@xz-x1> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Wed, 2 Dec 2020, Peter Xu wrote: > On Wed, Dec 02, 2020 at 02:37:33PM -0800, Hugh Dickins wrote: > > On Tue, 1 Dec 2020, Andrea Arcangeli wrote: > > > > > > Any suggestions on how to have the per-vaddr per-mm _PAGE_UFFD_WP bit > > > survive the pte invalidates in a way that remains associated to a > > > certain vaddr in a single mm (so it can shoot itself in the foot if it > > > wants, but it can't interfere with all other mm sharing the shmem > > > file) would be welcome... > > > > I think it has to be a new variety of swap-like non_swap_entry() pte, > > see include/linux/swapops.h. Anything else would be more troublesome. > > > > Search for non_swap_entry and for migration_entry, to find places that > > might need to learn about this new variety. > > > > IIUC you only need a single value, no need to carve out another whole > > swp_type: could probably be swp_offset 0 of any swp_type other than 0. > > > > Note that fork's copy_page_range() does not "copy ptes where a page > > fault will fill them correctly", so would in effect put a pte_none > > into the child where the parent has this uffd_wp entry. I don't know > > anything about uffd versus fork, whether that would pose a problem. > > Thanks for the idea, Hugh! > > I thought about something similar today, but instead of swap entries, I was > thinking about constantly filling in a pte with a value of "_PAGE_PROTNONE | > _PAGE_UFFD_WP" when e.g. we'd like to zap a page with shmem+uffd-wp. I feel > like the fundamental idea is similar - we can somehow keep the pte with uffd-wp > information even if zapped/swapped-out, so as long as the shmem access will > fruther trap into the fault handler, then we can operate on that pte and read > that information out, like recover that pte into a normal pte (with swap/page > cache, and vma/addr information, we'll be able to) and then we can retry the > fault. Yes, I think that should work too: I can't predict which way would cause less trouble. We usually tend to keep away from protnone games, because NUMA balancing use of protnone is already confusing enough. But those ptes will be pte_present(), so you must provide a pfn, and I think if you use the zero_pfn, vm_normal_page() will return false on it, and avoid special casing (and reference counting) it in various places. Hugh