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 93E2FC433F5 for ; Tue, 19 Apr 2022 19:59:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E08266B0072; Tue, 19 Apr 2022 15:59:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DB8C66B0073; Tue, 19 Apr 2022 15:59:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C58C06B0074; Tue, 19 Apr 2022 15:59:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0231.hostedemail.com [216.40.44.231]) by kanga.kvack.org (Postfix) with ESMTP id B6CF56B0072 for ; Tue, 19 Apr 2022 15:59:27 -0400 (EDT) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 40897182B2520 for ; Tue, 19 Apr 2022 19:59:27 +0000 (UTC) X-FDA: 79374693174.29.57DE2F5 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf05.hostedemail.com (Postfix) with ESMTP id 9010E100016 for ; Tue, 19 Apr 2022 19:59:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1650398366; 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=Wj92nEsEZg3Y6UkMYCgSn6Q+5JappCRf7DvrTymuEMc=; b=Aw2n4SqIGxx4N8IUdRGtCN9L/WXiBpxSqLmhheOQQjOm3sxNUyr1eGQ6eEO0e9JCXJfFEq H1hnLUcKe3aAJr0JmqE0KN7BzP42slgvkM0Uyjzzb+2qbxe/GufY+qE1R1mMbak3k67hnu PyS1ur6m8DA5ILd1i/3tmNBjNFXzKnM= Received: from mail-io1-f71.google.com (mail-io1-f71.google.com [209.85.166.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-614-cBpFRzfWOAW03aZ4hWZj3Q-1; Tue, 19 Apr 2022 15:59:24 -0400 X-MC-Unique: cBpFRzfWOAW03aZ4hWZj3Q-1 Received: by mail-io1-f71.google.com with SMTP id g20-20020a056602151400b00654afb7ec5dso3297836iow.11 for ; Tue, 19 Apr 2022 12:59:24 -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=S7aPPGBaDUbNbBaEN9oGo4CeP1VF+epNol9mo0bOqDU=; b=GtYjaVWhMD4OND2ipAXgDAldbJOSTEHi/15hnsK2MeMXpQWTbuc+AJ3w972sVuXcYJ crQlpgeh1ZhFLS6jfZ5NDRoFS10aIjzhAorCQhR0S6kTGfaWaNHUWIqOHT+3UE45PLI2 ylMcbEstHV9MRxDAwQ/auzQoMCUI7mvFaj1NnQ/iWCVLr5cNZq5ZuRh0m9zkLAWw+TsZ zuk6VGaDrhR3l2gQMTyAc1e3cbdcDkkvn2pnln/JjiW9kncFsQLUBG4GE4LDP878wcXo utISViKnUMgVrRtOf/nOEpGIatbW6o11tFGGLQRxhByTOKocvKQepLzXEtVMMG7Wod/J TcZA== X-Gm-Message-State: AOAM5309TjVKO8qqYgO4HTBRy6AP2RgFMNsJBwmCwZnNc1WoWi8l3tWa CbiP4vK+7ywvkcRCOimh298CQwls2FiiM3dVjm9verkoxikq27BPAcPNuiuEpXjvurv6/Nl2Jkf nv/r1a7Ascnk= X-Received: by 2002:a05:6e02:2162:b0:2cc:2a35:f3c7 with SMTP id s2-20020a056e02216200b002cc2a35f3c7mr4998330ilv.184.1650398364099; Tue, 19 Apr 2022 12:59:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxRZ2hcYzocaccI5T4mLAlPr9viJJ8p6Q4kGuzhBEr50gjPumBpL+trrzVZwbyw5BUdGzj5PA== X-Received: by 2002:a05:6e02:2162:b0:2cc:2a35:f3c7 with SMTP id s2-20020a056e02216200b002cc2a35f3c7mr4998312ilv.184.1650398363826; Tue, 19 Apr 2022 12:59:23 -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 h24-20020a6bfb18000000b006497692016bsm10097741iog.15.2022.04.19.12.59.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Apr 2022 12:59:23 -0700 (PDT) Date: Tue, 19 Apr 2022 15:59:21 -0400 From: Peter Xu To: Johannes Weiner Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Mike Kravetz , Nadav Amit , Matthew Wilcox , Mike Rapoport , David Hildenbrand , Hugh Dickins , Jerome Glisse , "Kirill A . Shutemov" , Andrea Arcangeli , Andrew Morton , Axel Rasmussen , Alistair Popple Subject: Re: [PATCH v8 22/23] mm: Enable PTE markers by default Message-ID: References: <20220405014646.13522-1-peterx@redhat.com> <20220405014929.15158-1-peterx@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="VhobxqQN/RYdeTkm" Content-Disposition: inline X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 9010E100016 X-Stat-Signature: fonxsc389mgcw3kwq3yu75ghpkf417ku Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=Aw2n4SqI; spf=none (imf05.hostedemail.com: domain of peterx@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-HE-Tag: 1650398365-459877 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: --VhobxqQN/RYdeTkm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline On Tue, Apr 19, 2022 at 11:13:48AM -0400, Johannes Weiner wrote: > Hi Peter, Hi, Johannes, > > On Mon, Apr 04, 2022 at 09:49:29PM -0400, Peter Xu wrote: > > Enable PTE markers by default. On x86_64 it means it'll auto-enable > > PTE_MARKER_UFFD_WP as well. > > > > Signed-off-by: Peter Xu > > --- > > mm/Kconfig | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/mm/Kconfig b/mm/Kconfig > > index 6e7c2d59fa96..3eca34c864c5 100644 > > --- a/mm/Kconfig > > +++ b/mm/Kconfig > > @@ -911,12 +911,14 @@ config ANON_VMA_NAME > > > > config PTE_MARKER > > bool "Marker PTEs support" > > + default y > > > > help > > Allows to create marker PTEs for file-backed memory. > > make oldconfig just prompted me on these: > > --- > Marker PTEs support (PTE_MARKER) [Y/n/?] (NEW) ? > > CONFIG_PTE_MARKER: > > Allows to create marker PTEs for file-backed memory. > > Symbol: PTE_MARKER [=y] > Type : bool > Defined at mm/Kconfig:1046 > Prompt: Marker PTEs support > Location: > Main menu > -> Memory Management options > --- > > > config PTE_MARKER_UFFD_WP > > bool "Marker PTEs support for userfaultfd write protection" > > + default y > > depends on PTE_MARKER && HAVE_ARCH_USERFAULTFD_WP > > It's not possible to answer them without looking at the code. > > But after looking at the code, I'm still not sure why it asks > me. Isn't this infrastructure code? > > Wouldn't it make more sense to remove the prompt string and have > userfaultfd simply select those? > > If this is too experimental to enable per default, a more reasonable > question for the user would be a "userfaultfd file support" option or > something, and have *that* select the marker code. Thanks for raising this question. Actually it's right now enabled by default, so I kept the options just to make sure we can always explicitly disable those options when we want. That's majorly why I kept this patch standalone one so if we want we can even drop it. Said that, I fully agree with you that having two options seem to be an overkill, especially the PTE_MARKER option will be too challenging to be correctly understood by anyone not familiar with it. So after a 2nd thought I'm trying to refine what I want to achieve with the kbuild system on this new feature: - On supported systems (x86_64), should be by default y with "make olddefconfig", but able to turn it off using "make oldconfig" etc., so the user will have a choice when they want. - On not-supported systems (non-x86_64), should be always n without any prompt asking, and user won't even see this entry. - PTE_MARKER option should always be hidden for all archs I plan to post a patch that is attached (I also reworded the entry to not mention about pte markers). Does that look acceptable on your side? Thanks, -- Peter Xu --VhobxqQN/RYdeTkm Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="0001-mm-uffd-Hide-PTE_MARKER-option.patch" >From 5d25e9d685bf129a1730caa61c1545fb16c094bb Mon Sep 17 00:00:00 2001 From: Peter Xu Date: Tue, 19 Apr 2022 15:31:12 -0400 Subject: [PATCH] mm/uffd: Hide PTE_MARKER option Content-type: text/plain The PTE_MARKER option should not need to be exposed to the kernel builder, keep it internal and remove the prompt so it won't be seen. Instead, make the PTE_MARKER_UFFD_WP option to explicitly choose PTE_MARKER when necessary. While PTE_MARKER_UFFD_WP will still prompt to user, change the wording so that it'll not mention PTE_MARKER at all but renaming it to "Userfaultfd write protection support for shmem/hugetlbfs". Reported-by: Johannes Weiner Signed-off-by: Peter Xu --- mm/Kconfig | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/mm/Kconfig b/mm/Kconfig index 3eca34c864c5..d740e1ff3b2f 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -910,16 +910,16 @@ config ANON_VMA_NAME difference in their name. config PTE_MARKER - bool "Marker PTEs support" - default y + bool help Allows to create marker PTEs for file-backed memory. config PTE_MARKER_UFFD_WP - bool "Marker PTEs support for userfaultfd write protection" + bool "Userfaultfd write protection support for shmem/hugetlbfs" default y - depends on PTE_MARKER && HAVE_ARCH_USERFAULTFD_WP + depends on HAVE_ARCH_USERFAULTFD_WP + select PTE_MARKER help Allows to create marker PTEs for userfaultfd write protection -- 2.32.0 --VhobxqQN/RYdeTkm--