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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 76C22CD5BD2 for ; Mon, 25 May 2026 13:53:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9CFFB6B0005; Mon, 25 May 2026 09:53:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9597F6B0088; Mon, 25 May 2026 09:53:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 820E06B008A; Mon, 25 May 2026 09:53:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 698FE6B0005 for ; Mon, 25 May 2026 09:53:23 -0400 (EDT) Received: from smtpin09.hostedemail.com (lb01a-stub [10.200.18.249]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E7981C019A for ; Mon, 25 May 2026 13:53:22 +0000 (UTC) X-FDA: 84806084244.09.4BC5692 Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by imf16.hostedemail.com (Postfix) with ESMTP id 42F0F18000B for ; Mon, 25 May 2026 13:53:21 +0000 (UTC) Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20260515 header.b=OVFJ8wef; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of alx@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=alx@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1779717201; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+JF/WiUWbktSKvTkm8E2dxKd/mlSjV3lWUPcFVG/YLs=; b=XZrvr6MClOSTMmbO+D3uMxrwG1ZMAxPpx33iICJpe+TXcZtmIifpb/lqIb3IWOflb0zyPg t7nMtacFsO72XxPOcjwERM/PHUyD4rLdC8ur1BA9XAiTTwpPQ0iPE9PpcjkIMeNj4V7OBo kbAbObViCnbxAuly3qK6y/1OypO9rPg= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20260515 header.b=OVFJ8wef; dmarc=pass (policy=quarantine) header.from=kernel.org; spf=pass (imf16.hostedemail.com: domain of alx@kernel.org designates 172.234.252.31 as permitted sender) smtp.mailfrom=alx@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1779717201; a=rsa-sha256; cv=none; b=vz2fDQx8Rv82h9ap/7Xeshpbg8LE146rB8MtSqHFiQiDg0TT6gRjD8ulocLM4pzm1244F5 oX4yHYALd5DO4u7gpkJGjyiIWtjkXXESdwlyEzxxor5FmiD0Hzt32izT42g8nr+lbjqT1t 1SZSw6wIOnFtHmsakgWosKMRm33cn7A= Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 39AE243E9D; Mon, 25 May 2026 13:53:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0FD8E1F000E9; Mon, 25 May 2026 13:53:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1779717200; bh=+JF/WiUWbktSKvTkm8E2dxKd/mlSjV3lWUPcFVG/YLs=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=OVFJ8wefvVqAVoz8sPMNZmDAueuv8M4d5157TYa9OnFNH++odjs2GPpdmKhDkRfYx d3dKfA1HVBrpJqxwjsnx76CcskAweZslHt5xq7EIFnJ6jUUB77xSWAovfdQzOyYk5b QKX+neB6oe83zYsT3XpWkaq+Ib5Q1nP8lgBzNjsWu8CH7Rvsp6CzLn7Pyk0vofeIQZ 4o1585MeSjghgjrnJcgGgKR1J6Ce2My6weqgA6Fk2h+nfp8AXbBa4L7tpaXktSBMzf GHO2ckkC1s4WqYTUZTBIKQdQ1AehVzZ0ycCxYG2ZL/wVtM31HFwG+pt7HkhSsHoAp2 4iFnTfkLanoKQ== Date: Mon, 25 May 2026 15:53:15 +0200 From: Alejandro Colomar To: Kiryl Shutsemau Cc: linux-man@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, rppt@kernel.org, peterx@redhat.com, david@kernel.org, kernel-team@meta.com, "Kiryl Shutsemau (Meta)" , "G. Branden Robinson" Subject: Re: [PATCH man-pages v1 1/6] userfaultfd.2: Add read-write protect mode Message-ID: References: <20260525122816.1956804-1-kirill@shutemov.name> <20260525122816.1956804-2-kirill@shutemov.name> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uhxldcna4n6vmaqa" Content-Disposition: inline In-Reply-To: <20260525122816.1956804-2-kirill@shutemov.name> X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 42F0F18000B X-Stat-Signature: zwkn5u7jo9qiq8u4do5pf8frcf7fkuaq X-Rspam-User: X-HE-Tag: 1779717201-589132 X-HE-Meta: U2FsdGVkX1/otkSJagPXlSb0k0Nu8FhJIGMBEUYVOUvqatzYLTdRdn30Qwrqw4kfRw1Y84K0dXO/MZB1FMxODfmzA3/dojvuVj/Jvpb2mQxgG1c28EbmqqDNmjJpSkLo5CVW0VW+iqfxvD0Z1kexghiz1PTOF7O4VuP72JwBrw55Vru2INAI8Nr3sPDfoEj8NtrJNZVlx2B0acybFWAt1LD9fwSM2KEU9enfwwMTT1xQ3GdlxQWEiJuwldrSnBgX5knUOtIWE11jJI0loZwaakfs51JSBzrd+DnqKtrYb7Wxc42UPb+LTeoYm7S2Dkltc2L5wuSneRxmdYsj2CzDMUN0F+O5k+7tvnEadt3lOZZdvuarv/6XTpNhzHYdPrtDdRm2gipBj6zpHsYVhEyQkXLM9D9n10ynNYGCAwbrzncDXPkyLoBv9yHi6UF5q8XRWHdPx2RoN3hBYSuvij4ew5qvYZeC6wMLxt25rH9KiTg8hMsbwSymF7chKYE1v4Xlzl/4JEKdi3AiG26mdTtQ8K4w5ZQoFDbqJwcw5sSy8rthRCr83ZUirFXAnSi7Rl7iA03rXzq1QGWX/C1Sh/l8SfF9nWHEKYwdbfMRd33syTLCQWRfxqqwuj+pQon7x7r4AWlPij5vKJQJnXkI4JBpw4CsCtmEgOZIZcyFoOsfeYlvLO1JWraaY4Yxavb5FNhWy5G3+TEtJ2sXF0Plb1VNe2Q2kszxdcX0CW2UghEFX7hD8je+WP/Ln3wYdtF58fLG4ZL6jsPfCjdBUFSbLBp1k9TrHpIrRJRnbUBZQqLbvZib4qBbqS1N9qsPSqXJPSvV69+BY+jTkq7mSAy/S5DmduJ5qGkKm2qwAYGLhTBH2MYM9W5lKByka9DbkU41+CvXy3l/pZVvRBKt1w+VejCpIZUZ1GBrTCz/VvEOxJ/OCcfijbDGoaDUUjNgE0HHbLsf0gcqXl9KRWj59O0vsqP Bl0csTJs 25XnJ1Z98th9XB2WI0RWwtNgflUBDcBE9p+XkfGBvnp5LPXYmZ7Z5K01ZplaCwcL5vQCrklTdsqQpxv05AvbSRrQcDzW8uK7ekzrkgPV0diZqblC/VKX/u89+7XVTOszWWZ/lRZSvkN83G7pO3DfiVoY9dwuWCse3sX0VKxpmia3+IM3czcBovBEgnaxpA3br+SQJA0x8xXhZU7Wik4gzcw565cbIVSBHnHKp6fJWE0lCz8MKJ0nfdBWiypFS7xoQ9SqMDMqTXxi84mur5OPWy19B5+FkY+GrzHzaFD5jyCbmZQXN3sc7BYAnCCmQY6mrAvs6r423OxVPB6lZNMEEjTaK+6O8U3DfuZzkd2Yx8MMfBZGFbrdmVuvctSB62u1kUp5JMpoTu6ci7EA+3gE4f3NiUmWfDks/9/zseSwgFS4SthdmVa+YHtDV9ejKy2mR6Lv0tGyh76Q/uVkkVFKt9Ezz7cyjjMibvNQ0+o3wS8ezCDq35GbR3Od9c07EhMRPuib0 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: --uhxldcna4n6vmaqa Content-Type: text/plain; protected-headers=v1; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable From: Alejandro Colomar To: Kiryl Shutsemau Cc: linux-man@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, rppt@kernel.org, peterx@redhat.com, david@kernel.org, kernel-team@meta.com, "Kiryl Shutsemau (Meta)" , "G. Branden Robinson" Subject: Re: [PATCH man-pages v1 1/6] userfaultfd.2: Add read-write protect mode Message-ID: References: <20260525122816.1956804-1-kirill@shutemov.name> <20260525122816.1956804-2-kirill@shutemov.name> MIME-Version: 1.0 In-Reply-To: <20260525122816.1956804-2-kirill@shutemov.name> Hi Kiryl, On 2026-05-25T13:28:11+0100, Kiryl Shutsemau wrote: > From: "Kiryl Shutsemau (Meta)" >=20 > Read-write protect mode (UFFDIO_REGISTER_MODE_RWP) is supported starting > from Linux 7.2. It traps every access -- read or write -- to a present > page within a registered range. The matching UAPI consists of: >=20 > - UFFDIO_REGISTER_MODE_RWP registration-mode bit > - UFFD_FEATURE_RWP capability bit > - UFFD_FEATURE_RWP_ASYNC async (in-kernel) fault resolution > - UFFDIO_RWPROTECT install / remove RWP on a range > - UFFDIO_SET_MODE runtime sync/async toggle > - UFFD_PAGEFAULT_FLAG_RWP new pagefault.flags bit >=20 > Document the new registration-mode entry, the "Userfaultfd read-write > protect mode" section, the new pagefault flag, and a VERSIONS line. >=20 > Signed-off-by: Kiryl Shutsemau > --- > man/man2/userfaultfd.2 | 152 +++++++++++++++++++++++++++++++++++++++-- > 1 file changed, 148 insertions(+), 4 deletions(-) >=20 > diff --git a/man/man2/userfaultfd.2 b/man/man2/userfaultfd.2 > index 6d56085f1534..a179660f4105 100644 > --- a/man/man2/userfaultfd.2 > +++ b/man/man2/userfaultfd.2 > @@ -111,6 +111,28 @@ The faulted thread will be stopped from execution Please have a look at the CONTRIBUTING file, and the CONTRIBUTING.d directory. In particular, it would be nice to see more useful hunk contexts, which can be done following this documentation: > until user-space write-unprotects the page using an > .B UFFDIO_WRITEPROTECT > ioctl. > +.TP > +.BR UFFDIO_REGISTER_MODE_RWP " (since Linux 7.2)" > +When registered with > +.B UFFDIO_REGISTER_MODE_RWP > +mode, user-space will receive a page-fault notification > +on any access \(em read or write \(em to a present page within the range. Please use \[em] instead of \(em, and use spaces around them as if they were parentheses --like this--. Also, please use semantic newlines. See man-pages(7): $ MANWIDTH=3D64 man man-pages | awk '/Use semantic newlines/,/^$/' Use semantic newlines In the source of a manual page, new sentences should be started on new lines, long sentences should be split into lines at clause breaks (commas, semicolons, colons, and so on), and long clauses should be split at phrase bound=E2=80=90 aries. This convention, sometimes known as "semantic new=E2=80=90 lines", makes it easier to see the effect of patches, which often operate at the level of individual sentences, clauses, or phrases. That would be: When registered with .B UFFDIO_REGISTER_MODE_RWP mode, user-space will receive a page-fault notification on any access \[em]read or write\[em] to a present page within the range. BTW, about the last line, I think you may want to mean s/present page/page present/, with inverted order of the words, that is, the page is present within the range, right? > +By default the faulted thread will be stopped from execution until 'By default' should be followed by a comma. Also, because of semantic newlines, I'd move 'until' to the next line. Thus: By default, the faulted thread will be stopped from execution until user space removes the protection using a > +user-space removes the protection using a We say user space, as two words. 'user-space' is used when it works as a compound adjective (usual English rules). > +.B UFFDIO_RWPROTECT > +ioctl; > +if > +.B UFFD_FEATURE_RWP_ASYNC > +was negotiated, the kernel restores access in place and the faulted > +thread continues without blocking. Again semantic newlines: ... was negotiated, the kernel restores access in place and the faulted thread continues without blocking. A rule of thumb when separating lines semantically is that it should be relatively easy to understand full lines without reading the surrounding lines. > +.IP > +.B UFFDIO_REGISTER_MODE_RWP > +and > +.B UFFDIO_REGISTER_MODE_WP > +cannot be combined on the same range; attempting to register with both Please break the line after the ';' (semantic newlines). > +bits set returns s/returns/fails with/ I user space, we transform the return value to an errno code, and return -1. > +.BR EINVAL . > +See the "Userfaultfd read-write protect mode" section below. This should probably be read-write-protect mode, for consistency with write-prtect mode. Or maybe read/write-protect mode. > .P > Multiple modes can be enabled at the same time for the same memory range. > .P > @@ -192,6 +214,21 @@ The user needs to resolve the page fault by unprotec= ting the faulted page and > kicking the faulted thread to continue. > For more information, > please refer to the "Userfaultfd write-protect mode" section. > +.PP We changed to using .P some years ago. It works exactly the same, and is easier to type. > +Since Linux 7.2, userfaultfd can do read-write protection tracking, which > +traps every access (read or write) to a present page within a registered > +range. > +One should check against the feature bit > +.B UFFD_FEATURE_RWP > +before using this feature, and optionally negotiate > +.B UFFD_FEATURE_RWP_ASYNC > +to have the kernel auto-restore page permissions on fault without > +delivering a notification. > +This mode is intended for working-set tracking by VM memory managers and > +similar callers; cold pages can then be evicted using independent kernel > +interfaces. > +For more information, > +please refer to the "Userfaultfd read-write protect mode" section. A lot of semantic newlines needed above. > .\" > .SS Userfaultfd operation > After the userfaultfd object is created with > @@ -387,6 +424,99 @@ wakes up the faulting thread(s). > Minor fault mode supports only hugetlbfs-backed (since Linux 5.13) > and shmem-backed (since Linux 5.14) memory. > .\" > +.SS Userfaultfd read-write protect mode (since Linux 7.2) > +Since Linux 7.2, userfaultfd supports read-write protect mode. > +Unlike write-protect mode, every access \(em read or write \(em to a Same thing about \[em] and spacing. > +protected present page generates a userfaultfd notification. > +It works on anonymous, shmem, and hugetlbfs mappings. > +.P > +The user needs to first check availability of this feature using the > +.B UFFDIO_API > +ioctl against the feature bit > +.B UFFD_FEATURE_RWP > +before using this mode. > +See > +.BR UFFDIO_API (2const) > +for the recommended discovery sequence. > +.P > +To register with userfaultfd read-write protect mode, the user needs to > +initiate the > +.B UFFDIO_REGISTER > +ioctl with mode > +.B UFFDIO_REGISTER_MODE_RWP > +set. > +.B UFFDIO_REGISTER_MODE_RWP > +cannot be combined with > +.BR UFFDIO_REGISTER_MODE_WP ; > +however it can be combined with > +.B UFFDIO_REGISTER_MODE_MISSING > +when the caller also wants notifications for fresh page populations. > +.P > +After registration, the user can read-write-protect any existing memory > +within the range using the > +.B UFFDIO_RWPROTECT > +ioctl where > +.I uffdio_rwprotect.mode > +is set to > +.BR UFFDIO_RWPROTECT_MODE_RWP . > +Read-write protection only affects pages that are currently populated > +in the range; unpopulated addresses remain unpopulated and fall through > +to the normal missing-page path on first access. > +.P > +For anonymous mappings, protection is preserved across page reclaim > +(the marker rides on the swap entry) and migration. > +For shmem and file-backed mappings, protection is dropped when the > +backing page is reclaimed and must be re-armed by the caller. > +Protection is also > +.I not > +preserved across operations that explicitly drop the underlying page > +.RB ( "MADV_DONTNEED " "on anonymous memory, hole-punch on shmem," Huh, this is weird. Why did you write it this way? > +truncation of a file mapping). > +Callers must re-arm the range with > +.B UFFDIO_RWPROTECT > +after any such operation. > +.P > +When an access fault happens against a protected page, user-space will > +receive a page-fault notification whose > +.I uffd_msg.pagefault.flags > +field has the > +.B UFFD_PAGEFAULT_FLAG_RWP > +bit set. > +.P > +To resolve a read-write-protect page fault, the user initiates another > +.B UFFDIO_RWPROTECT > +ioctl whose > +.I uffdio_rwprotect.mode > +has the > +.B UFFDIO_RWPROTECT_MODE_RWP > +flag cleared. > +This restores the original VMA permissions on the affected pages and > +wakes any blocked threads (unless > +.B UFFDIO_RWPROTECT_MODE_DONTWAKE > +is also set). > +.P > +If > +.B UFFD_FEATURE_RWP_ASYNC > +was negotiated alongside > +.BR UFFD_FEATURE_RWP , > +the kernel resolves access faults in place without delivering a > +notification: page permissions are restored automatically and the > +faulting thread continues. > +Callers can later reconstruct which pages were touched by inspecting the > +.B PAGE_IS_ACCESSED > +bit returned by the > +.B PAGEMAP_SCAN > +ioctl described in > +.BR ioctl_userfaultfd (2) > +and > +.IR Documentation/admin\-guide/mm/pagemap.rst > +in the Linux kernel source. > +.P > +The async mode can be toggled at runtime using the > +.B UFFDIO_SET_MODE > +ioctl, which lets a single userfaultfd switch between async detection > +and synchronous eviction without re-registering the range. > +.\" > .SS Reading from the userfaultfd structure > Each > .BR read (2) > @@ -531,13 +661,17 @@ If this flag is set, then the fault was a write-pro= tect fault. > .B UFFD_PAGEFAULT_FLAG_MINOR > If this flag is set, then the fault was a minor fault. > .TP > +.BR UFFD_PAGEFAULT_FLAG_RWP " (since Linux 7.2)" > +If this flag is set, then the fault was a read-write-protect fault. > +.TP > .B UFFD_PAGEFAULT_FLAG_WRITE > If this flag is set, then the fault was a write fault. > .P > -If neither > -.B UFFD_PAGEFAULT_FLAG_WP > -nor > -.B UFFD_PAGEFAULT_FLAG_MINOR > +If none of > +.BR UFFD_PAGEFAULT_FLAG_WP , > +.BR UFFD_PAGEFAULT_FLAG_MINOR , > +or > +.B UFFD_PAGEFAULT_FLAG_RWP > are set, then the fault was a missing fault. > .RE > .TP > @@ -640,6 +774,16 @@ Linux 4.3. > .P > Support for hugetlbfs and shared memory areas and > non-page-fault events was added in Linux 4.11 > +.P > +Read-write protect mode > +.RB ( UFFDIO_REGISTER_MODE_RWP ", " UFFD_FEATURE_RWP ", " This is weird again. Please don't have more than one identifier per line. Have a lovely day! Alex > +.BR UFFDIO_RWPROTECT ) > +was added in Linux 7.2, > +together with > +.B UFFD_FEATURE_RWP_ASYNC > +and the > +.B UFFDIO_SET_MODE > +runtime mode toggle. > .SH NOTES > The userfaultfd mechanism can be used as an alternative to > traditional user-space paging techniques based on the use of the > --=20 > 2.54.0 >=20 >=20 --=20 --uhxldcna4n6vmaqa Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEES7Jt9u9GbmlWADAi64mZXMKQwqkFAmoUVEAACgkQ64mZXMKQ wqlU2xAAtUs3SkDf6rA2WBgkZgdfw3E4odZx2d4HMPOKk0o2Eoz+eQ0goe20njUg EOJIr95mIhglsfPU4fE81TRzC1JLU0GByjM85OqIYbgiuW18amtGKC9FAojFP0Mv FZa2ELKeeYxtWaS9krRBJXypbS7AFH2awHsUQXFOme88nlBMEZccNLERzHt5XdgL plZJkbEfz9VFu/ccSvL5hayxwtm1GNejz+d5ueiBnCBIiDVKVemyDU/BMOg6RDy4 VdH2GlgK5+CwNwYfIszxarYqhbZuk95jkZvJfjZ0X8nyN2Bpib+TZbk5nIjDZNOF mVkIm7G5qAGN/dr0PPGsUPJY0F6J/md/JoFuYzAWEPyojY+5TYgPFC/GpXBigfrM BD84/CTePpygt7ZGLqVuACKyHepMKDtqafMSjjY/3V0yUt+2/Q7m2TxLm/emdosy QAJ6daPE4UX3Blx2XZMbZs9bq3utaiktbj5hV9VesRq4VGc/6YJNRhbXQ5VFxOPo VI0yfOZxsWGxHK2ikDomA5GU/EXevvPvwL3HIZhgzA292pxYY4yPCowsbkYR9AwN 2Ws1Y7JPZ8aNn/nq+za+Tjm6I+eYrX+4LuhlyEus7QzCWRE//L/cyFxqiDT5kJ6+ MTyoBXLrPuTTTExUDEGcQehC+Z6IyKhZKm0yklEI+iSLyvb/Ij0= =1SBD -----END PGP SIGNATURE----- --uhxldcna4n6vmaqa--