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 B4B97C433F5 for ; Thu, 16 Dec 2021 05:46:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EAB916B0074; Thu, 16 Dec 2021 00:45:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E34836B0075; Thu, 16 Dec 2021 00:45:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CAD926B0078; Thu, 16 Dec 2021 00:45:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0194.hostedemail.com [216.40.44.194]) by kanga.kvack.org (Postfix) with ESMTP id B45376B0074 for ; Thu, 16 Dec 2021 00:45:53 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 6DAB3180B7D47 for ; Thu, 16 Dec 2021 05:45:43 +0000 (UTC) X-FDA: 78922570566.08.E97029C Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf20.hostedemail.com (Postfix) with ESMTP id 515331C0019 for ; Thu, 16 Dec 2021 05:45:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1639633542; 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=ukexlmknN2bRyzPsMC8Ut5pZb/Whnh9Gt8bGl/njzhs=; b=cFLpFtWj5ak5pIGC6qmgo5P5QyAhODgvJFrn3hN8KwxT+HBk+jMc4L2mO3uaApvCbyWkHi 8VlP/0gIFf0sBOhmU2oi8Wc89Y1BTKxKksez9mwx5Gsesnh6ngQw63PnVV1IGcM8PxPMoG 2rlYi1Jqb5IOWgOLcLbe06B2mZqfI2o= 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-167-QXOszHoEOVa1mo3YnHMfDg-1; Thu, 16 Dec 2021 00:45:38 -0500 X-MC-Unique: QXOszHoEOVa1mo3YnHMfDg-1 Received: by mail-wr1-f69.google.com with SMTP id p15-20020adfaa0f000000b001a240b45c1fso218825wrd.4 for ; Wed, 15 Dec 2021 21:45:38 -0800 (PST) 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=ukexlmknN2bRyzPsMC8Ut5pZb/Whnh9Gt8bGl/njzhs=; b=Tmt6HkI9PvuzevR+JcGCYDzRjRePew7tZxcA7xUS5iv247LroTDAypnSXoSoG3yoBG TTbAyiTlTJKOh/z/kkBxZF6ZRXUQnIcHOSP00ja6pFMPOojLsCF+AQAHqQU+Bww98N4i PP6BKqD6QHIgxnA+GjYuFit7rDWWcV4cnXGngGoF/uuhxOdvSi7nuiYIPp6u+XtE7pBO nJ0Z4ir1yQqTfSYkOtthk6fotcNongmJtZ15TooAbNHwMtfz3g9DhuJDUgbBrAWJ/E83 UuciTb6oN+3zaBt2lk/5wHNcZxvoR8coiNbINb3VKjGOyOpazfFTO10D4cR1/5FCUyMn JDvw== X-Gm-Message-State: AOAM533Zl+JKfDuUn2wrw9gDN9lb3PO6KFrxTu4iP8+EuzjF2eSkHqXs mNw5EXJ3kNpdZmzEjvFHmmgohKgiS5AXOFPt2FIQx2L9Otcrke0TLGq0ePg+oRvvEZvE6PvnzC3 7nIkaAS1d4EI= X-Received: by 2002:adf:e4cc:: with SMTP id v12mr3343662wrm.653.1639633537355; Wed, 15 Dec 2021 21:45:37 -0800 (PST) X-Google-Smtp-Source: ABdhPJzQBc7M7omjm4rc1bX/tOyMmrpU90UBTk9xAd2dr7Ei2BweLZKTpAQzSQ0/9pSESzfXM8bPwg== X-Received: by 2002:adf:e4cc:: with SMTP id v12mr3343642wrm.653.1639633537135; Wed, 15 Dec 2021 21:45:37 -0800 (PST) Received: from xz-m1.local ([64.64.123.12]) by smtp.gmail.com with ESMTPSA id e1sm1681835wrc.74.2021.12.15.21.45.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Dec 2021 21:45:36 -0800 (PST) Date: Thu, 16 Dec 2021 13:45:28 +0800 From: Peter Xu To: Alistair Popple Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Axel Rasmussen , Nadav Amit , Mike Rapoport , Hugh Dickins , Mike Kravetz , "Kirill A . Shutemov" , Jerome Glisse , Matthew Wilcox , Andrew Morton , David Hildenbrand , Andrea Arcangeli Subject: Re: [PATCH v6 04/23] mm/uffd: PTE_MARKER_UFFD_WP Message-ID: References: <20211115075522.73795-1-peterx@redhat.com> <20211115075522.73795-5-peterx@redhat.com> <1966495.R0KUr5dvoW@nvdebian> MIME-Version: 1.0 In-Reply-To: <1966495.R0KUr5dvoW@nvdebian> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=cFLpFtWj; spf=none (imf20.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-Rspamd-Queue-Id: 515331C0019 X-Stat-Signature: yr6tsg4t53o5ppkw46enhqyn8aiddcqa X-Rspamd-Server: rspam04 X-HE-Tag: 1639633540-364116 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 Thu, Dec 16, 2021 at 04:18:50PM +1100, Alistair Popple wrote: > On Monday, 15 November 2021 6:55:03 PM AEDT Peter Xu wrote: > > [...] > > > +/* > > + * Returns true if this is a swap pte and was uffd-wp wr-protected in either > > + * forms (pte marker or a normal swap pte), false otherwise. > > + */ > > +static inline bool pte_swp_uffd_wp_any(pte_t pte) > > +{ > > +#ifdef CONFIG_PTE_MARKER_UFFD_WP > > + if (!is_swap_pte(pte)) > > + return false; > > + > > + if (pte_swp_uffd_wp(pte)) > > + return true; > > If I'm not mistaken normal swap uffd-wp ptes can still exist when > CONFIG_PTE_MARKER_UFFD_WP=n so shouldn't this be outside the #ifdef protection? > > In fact we could drop the #ifdef entirely here as it is safe to call > is_pte_marker_uffd_wp() without CONFIG_PTE_MARKER_UFFD_WP. But if CONFIG_PTE_MARKER_UFFD_WP=n then it means we don't support file-backed uffd-wp. The thing is pte_swp_uffd_wp_any() is only needed for file-backed.. Anonymous uffd-wp code never uses it. In other words, pte_swp_uffd_wp() is indeed still a valid helper, however this specific function (pte_swp_uffd_wp_any) may not really be necessary anymore. Keeping the "#ifdef" could still help, imho, to generate clean code for direct calls to pte_swp_uffd_wp_any() if someone wants to turn pte markers off, e.g. we could still have chance to optimize below: if (pte_swp_uffd_wp_any(pte) && !(zap_flags & ZAP_FLAG_DROP_MARKER)) set_huge_pte_at(mm, address, ptep, make_pte_marker(PTE_MARKER_UFFD_WP)); else huge_pte_clear(mm, address, ptep, sz); Into: huge_pte_clear(mm, address, ptep, sz); with any decent compiler. That's majorly why I still slightly prefer to keep it, and that's also one of the major reason to have the config knob, imho. Thanks, -- Peter Xu