From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 027A33E9C06 for ; Fri, 22 May 2026 11:51:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779450682; cv=none; b=drBR8gX17XjwYC8tC6M8gBtuT94lEAaDFASu8RmuBFSmQQQ4VSTBazVutEwbTe0crPuHo5cRknukpX9BuFV0IPgXNhS1wWZ/P/oo/5RrqObfPQZu/yFEyZTXS3Oeak/DYOqj1HdQH5Kpl/CUa4LCtmQI5jYfthRhn/0YMMgok3I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779450682; c=relaxed/simple; bh=muRkgjwO38S4SXvbIs3kFYWkJf7gwztLqAjDhEqnass=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=pcWBs1Dzc3+KJ4pLQCi9yMGTR4t1HGkZPjFH2KmpDynxs2khANehqZ69Cd36pwsmcljLz3IMWLpqC9CtndBC5/IV7Wu/716DD5DBQhdrp8zIQDeoE3P3Yq28LdCg6Bn+NLz5q0nLwHTuLkDEGdI1Y0fgNyUw3nooaVkTj9ShC6M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Wx/KGeJW; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Wx/KGeJW" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 59D051F00A3E; Fri, 22 May 2026 11:51:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779450680; bh=Mb5pSbbAGYerWjfqxHgQXJ81h4yET5l0OQn5Vn752FE=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=Wx/KGeJWlF2Zr6qrDmGOviCunxl1pvuPYJEtXPnsRc2sv+cGOfWuDkQYe19P/XgJF DV4ABfqKzI442PvPYQnd9Vmk9AxeGfMHFmWM/Wzl8bYf4qGE0bmWaF5sbfCG/WnhYd kKwiC4iHkWe+3F42VZBVVk6fmGl/kxOdyNplrMsBCf2xgwv3R+QWwmgUlKWMW1wUh6 jBzUqzZU7c/GwdKUhbtdHdjIZMYtAo0Ym4p2oGPJie57LP1Gw3XNGWdxDWYsLrXwLB Lb/gfSY7moaLGg5LTDQFGc2AG1Do73RgBKnbeWLhA9dUVxG7I2UEYsw0EekOxOBVkj IifVwtTpGehhA== Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfauth.phl.internal (Postfix) with ESMTP id AE3E0F40068; Fri, 22 May 2026 07:51:19 -0400 (EDT) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Fri, 22 May 2026 07:51:19 -0400 X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefhedrtddtgdduhedttdelucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucenucfjughrpeffhffvvefukfhfgggtuggjsehttdertd dttddvnecuhfhrohhmpefmihhrhihlucfuhhhuthhsvghmrghuuceokhgrsheskhgvrhhn vghlrdhorhhgqeenucggtffrrghtthgvrhhnpeeuieejieffkeehfeffffdtkeelfeelhe fhfefhudehjeehvdffleeuvddufefgkeenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehkihhrihhllhdomhgvshhmthhprghuthhhphgvrhhsoh hnrghlihhthidqudeiudduiedvieehhedqvdekgeeggeejvdekqdhkrghspeepkhgvrhhn vghlrdhorhhgsehshhhuthgvmhhovhdrnhgrmhgvpdhnsggprhgtphhtthhopeegiedpmh houggvpehsmhhtphhouhhtpdhrtghpthhtoheprhhpphhtsehkvghrnhgvlhdrohhrghdp rhgtphhtthhopegrkhhpmheslhhinhhugidqfhhouhhnuggrthhiohhnrdhorhhgpdhrtg hpthhtohepphgvthgvrhigsehrvgguhhgrthdrtghomhdprhgtphhtthhopegurghvihgu sehkvghrnhgvlhdrohhrghdprhgtphhtthhopehljhhssehkvghrnhgvlhdrohhrghdprh gtphhtthhopehsuhhrvghnsgesghhoohhglhgvrdgtohhmpdhrtghpthhtohepvhgsrggs khgrsehkvghrnhgvlhdrohhrghdprhgtphhtthhopehlihgrmhdrhhhofihlvghtthesoh hrrggtlhgvrdgtohhmpdhrtghpthhtohepiihihiesnhhvihguihgrrdgtohhm X-ME-Proxy: Feedback-ID: i10464835:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 22 May 2026 07:51:18 -0400 (EDT) Date: Fri, 22 May 2026 12:51:16 +0100 From: Kiryl Shutsemau To: Mike Rapoport Cc: akpm@linux-foundation.org, peterx@redhat.com, david@kernel.org, ljs@kernel.org, surenb@google.com, vbabka@kernel.org, Liam.Howlett@oracle.com, ziy@nvidia.com, corbet@lwn.net, skhan@linuxfoundation.org, seanjc@google.com, pbonzini@redhat.com, jthoughton@google.com, aarcange@redhat.com, sj@kernel.org, usama.arif@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, linux-kselftest@vger.kernel.org, kvm@vger.kernel.org, kernel-team@meta.com Subject: Re: [PATCH v2 09/14] mm/userfaultfd: add RWP fault delivery and expose UFFDIO_REGISTER_MODE_RWP Message-ID: References: <454b3381cb7ead65291b2d7e24c0bff62e55c41b.1778254670.git.kas@kernel.org> Precedence: bulk X-Mailing-List: linux-doc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, May 12, 2026 at 08:29:02PM +0300, Mike Rapoport wrote: > On Fri, May 08, 2026 at 04:55:21PM +0100, Kiryl Shutsemau (Meta) wrote: > > Wire the fault side of read-write protection tracking and turn the > > userspace interface on. > > > > An RWP-protected PTE is PAGE_NONE with the uffd bit set. The > > PROT_NONE triggers a fault on any access; the uffd bit distinguishes > > it from plain mprotect(PROT_NONE) or NUMA hinting. > > > > Fault dispatch, per level: > > > > PTE handle_pte_fault() -> do_uffd_rwp() > > PMD __handle_mm_fault() -> do_huge_pmd_uffd_rwp() > > hugetlb hugetlb_fault() -> hugetlb_handle_userfault() > > > > The RWP branches gate on userfaultfd_pte_rwp() / userfaultfd_huge_pmd_rwp() > > (VM_UFFD_RWP plus the uffd bit) and fall through to do_numa_page() / > > do_huge_pmd_numa_page() otherwise. Each delivers a > > UFFD_PAGEFAULT_FLAG_RWP message through handle_userfault(); the handler > > resolves it with UFFDIO_RWPROTECT clearing MODE_RWP. > > > > userfaultfd_must_wait() and userfaultfd_huge_must_wait() add matching > > protnone+uffd waiters so sync-mode fault handlers block correctly. > > > > Expose the UAPI: > > > > UFFDIO_REGISTER_MODE_RWP -> UFFD_API_REGISTER_MODES > > UFFD_FEATURE_RWP -> UFFD_API_FEATURES > > _UFFDIO_RWPROTECT -> UFFD_API_RANGE_IOCTLS > > UFFD_API_RANGE_IOCTLS_BASIC > > > > UFFD_FEATURE_RWP is masked out at UFFDIO_API time when PROT_NONE is > > not available or VM_UFFD_RWP aliases VM_NONE (32-bit), so userspace > > never sees an advertised-but-broken feature. > > > > Works on anonymous, shmem, and hugetlb memory. > > > > Signed-off-by: Kiryl Shutsemau > > Assisted-by: Claude:claude-opus-4-6 > > A small nit below, other than that > > Reviewed-by: Mike Rapoport (Microsoft) Thanks! > > @@ -347,6 +359,14 @@ static inline bool userfaultfd_must_wait(struct userfaultfd_ctx *ctx, > > */ > > if (!pte_write(ptent) && (reason & VM_UFFD_WP)) > > goto out; > > + /* > > + * PTE is still RW-protected (protnone with uffd bit), wait for > > + * userspace to resolve. Plain PROT_NONE without the marker is not > > + * an RWP fault. > > + */ > > + if (pte_protnone(ptent) && pte_uffd(ptent) && > > + (reason & VM_UFFD_RWP)) > > Nit: this fits even in 80-chars line Ack. -- Kiryl Shutsemau / Kirill A. Shutemov