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 A6F52C433EF for ; Thu, 12 May 2022 16:34:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E92296B0074; Thu, 12 May 2022 12:34:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E1A0C6B0075; Thu, 12 May 2022 12:34:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C92C66B0078; Thu, 12 May 2022 12:34:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id B30F86B0074 for ; Thu, 12 May 2022 12:34:43 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8A78932550 for ; Thu, 12 May 2022 16:34:43 +0000 (UTC) X-FDA: 79457639646.21.1F754CE Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf21.hostedemail.com (Postfix) with ESMTP id D31AF1C00B9 for ; Thu, 12 May 2022 16:34:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1652373282; 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: in-reply-to:in-reply-to:references:references; bh=IgNwvZiNKQbPzzXRivhIk29V2U2Bsc1enjkVdinryPo=; b=g8H3PN/lwQI/b5zdlqoO8a2yMGZg9vKD1esZPAfwwaMs6ke7Aao7yWFE8+XrVFcLuolmqp P62YejNg+VXGdfhti+ngVIv7Qbig2hmR/5nG9Eha5EPrz3z2AQLrwrYrlEFyp4Jx0rxYnA rEp1mNrjEdfjFLoEDglR/31YI7Vve64= Received: from mail-il1-f197.google.com (mail-il1-f197.google.com [209.85.166.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-55-YMtPviL9MoiWQNspLffOgw-1; Thu, 12 May 2022 12:34:41 -0400 X-MC-Unique: YMtPviL9MoiWQNspLffOgw-1 Received: by mail-il1-f197.google.com with SMTP id h1-20020a056e021d8100b002d0eca04dbaso953786ila.2 for ; Thu, 12 May 2022 09:34:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=IgNwvZiNKQbPzzXRivhIk29V2U2Bsc1enjkVdinryPo=; b=pkN4gbE2GFiH6xvfdqZ88BnJ+TSRO98DBHu9wcsKj2KGSAPJ/4lhqwzK3kvTBdUIC1 /292NdCtZ8zsdmHZu6Sq6UQ5qnwmLBNxxJa9h9Yt9PGBGUk90nbWWtS1Ts3uma601QMj FaIlectKO0CvQuGz2DM26TFMV0z0qee5RI+LQhKB6qwiVUqCvMQm11p0nnvI9+EpSQWv f1lM/Q4QU9lSk3+Fd67GFCxWCzd5YZtebArnUwlKPUEZHMO284iqh0MyuPYi9qDFUN0M 6QfYP4qHIwsGBLYron+zTRQ+vghWhDHg1i6/giypQI5wUuVBH/ylt7NdCZ4iNB/SQsSW o6cg== X-Gm-Message-State: AOAM531DKfGgK4mU9R6UFMEmjJg/h/+Asp6Xz+P/5Z6QisgHISupNxoT xy8hG8C7FLUvIpzDBctGeF4oweD51FkuN7/JtHTDKHTytSAaZ5l7MvsfGGZPv6TJSrAzhgG5R5N WTEqOeXVFoBM= X-Received: by 2002:a05:6e02:5a2:b0:2cf:8e6e:a5ab with SMTP id k2-20020a056e0205a200b002cf8e6ea5abmr474787ils.63.1652373280373; Thu, 12 May 2022 09:34:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxnYLcElP3RubY+gmeBqxhu3mbpK6fQq97iY6aWfy2ptM8oqCoh3b//Ce/oaarAzKkPNvK9Bw== X-Received: by 2002:a05:6e02:5a2:b0:2cf:8e6e:a5ab with SMTP id k2-20020a056e0205a200b002cf8e6ea5abmr474771ils.63.1652373280155; Thu, 12 May 2022 09:34:40 -0700 (PDT) Received: from xz-m1.local (cpec09435e3e0ee-cmc09435e3e0ec.cpe.net.cable.rogers.com. [99.241.198.116]) by smtp.gmail.com with ESMTPSA id x1-20020a029481000000b0032b3a7817b2sm1525119jah.118.2022.05.12.09.34.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 May 2022 09:34:39 -0700 (PDT) Date: Thu, 12 May 2022 12:34:38 -0400 From: Peter Xu To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Mike Kravetz , Nadav Amit , Matthew Wilcox , Mike Rapoport , Hugh Dickins , Jerome Glisse , "Kirill A . Shutemov" , Andrea Arcangeli , Andrew Morton , Axel Rasmussen , Alistair Popple Subject: Re: [PATCH v8 06/23] mm/shmem: Handle uffd-wp special pte in page fault handler Message-ID: References: <20220405014646.13522-1-peterx@redhat.com> <20220405014844.14239-1-peterx@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: D31AF1C00B9 X-Stat-Signature: a9ubaua3x5s6r5tbijirfobz3ixx9z93 X-Rspam-User: Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="g8H3PN/l"; spf=none (imf21.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1652373274-979023 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, May 11, 2022 at 06:30:59PM +0200, David Hildenbrand wrote: > > +/* > > + * This is actually a page-missing access, but with uffd-wp special pte > > + * installed. It means this pte was wr-protected before being unmapped. > > + */ > > +static vm_fault_t pte_marker_handle_uffd_wp(struct vm_fault *vmf) > > +{ > > + /* > > + * Just in case there're leftover special ptes even after the region > > + * got unregistered - we can simply clear them. We can also do that > > + * proactively when e.g. when we do UFFDIO_UNREGISTER upon some uffd-wp > > + * ranges, but it should be more efficient to be done lazily here. > > + */ > > + if (unlikely(!userfaultfd_wp(vmf->vma) || vma_is_anonymous(vmf->vma))) > > + return pte_marker_clear(vmf); > > What would happen if we do a unregister followed by a register? IMHO we > should start with a clean uffd-wp slate then. Your comment makes ma > assume that we could receive stale WP events, which would be wrong? I'd say it's not wrong, but it's true and actually expected. Firstly, userfaultfd (by design) always allows false positives (getting same message multiple times) but no tolerance on false negatives (missing event, which is data corrupt). The latter should be obvious. For the former, the simplest example is when two threads access the same missing page the same time, two same messages will be generated. Same applies to wr-protect faults. And it'll be non-trivial (or say, impossible.. IMHO) to avoid those. In this specific case, it's about when to drop the uffd-wp bits when unregister. Two obvious options: (1) during unregister, or (2) lazy. Here I chose the lazy way because unregister could be slowed down by this, and that's when program quits. In short with current approach we quit fast. We could have leftovers, but we'll take care of them when needed. One important thing is leftover ptes should not be the major way uffd-wp should be used by the normal register -> wr-protect -> unprotect -> unregister sequence. Normally the process won't unregister probably until it quits, so the leftover does no harm to anyone. Meanwhile, any user who wants to avoid the lazy way can simply do a whole-round unprotect before unregister. So we leave more choice for the user and by default we make sure no syscall will be easily slowed down. Hope that answers, thanks! -- Peter Xu