v2:
- Use semantic newlines always in patch 1 [Alex]
- Fix s/.BR/.B/ in patch 2 [Alex]
- Rebased to http://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git
Add the two missing pieces till latest 5.19-rc1: the UFFD_USER_MODE_ONLY
flag, and also the recent wr-protect support on shmem and hugetlbfs.
Please review, thanks.
Peter Xu (2):
userfaultfd.2: Add section for UFFD_USER_MODE_ONLY
userfaultfd.2: Update on write-protection support
man2/userfaultfd.2 | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
--
2.32.0
Add a paragraph for UFFD_USER_MODE_ONLY flag that was introduced in
Linux 5.11.
Signed-off-by: Peter Xu <[email protected]>
---
man2/userfaultfd.2 | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2
index 93dca009f..6b9412aaf 100644
--- a/man2/userfaultfd.2
+++ b/man2/userfaultfd.2
@@ -12,8 +12,9 @@ Standard C library
.RI ( libc ", " \-lc )
.SH SYNOPSIS
.nf
-.BR "#include <fcntl.h>" " /* Definition of " O_* " constants */"
-.BR "#include <sys/syscall.h>" " /* Definition of " SYS_* " constants */"
+.BR "#include <fcntl.h>" " /* Definition of " O_* " constants */"
+.BR "#include <sys/syscall.h>" " /* Definition of " SYS_* " constants */"
+.BR "#include <linux/userfaultfd.h>" " /* Definition of " UFFD_* " constants */"
.B #include <unistd.h>
.PP
.BI "int syscall(SYS_userfaultfd, int " flags );
@@ -59,6 +60,15 @@ See the description of the
.B O_NONBLOCK
flag in
.BR open (2).
+.TP
+.B UFFD_USER_MODE_ONLY
+This is an userfaultfd specific flag that was introduced since Linux 5.11.
+When set, the userfaultfd object will only be able to handle page faults
+originated from the userspace on the registered regions.
+When a kernel originated fault was triggered on the registered range with
+this userfaultfd, a
+.B SIGBUS
+signal will be delivered.
.PP
When the last file descriptor referring to a userfaultfd object is closed,
all memory ranges that were registered with the object are unregistered
--
2.32.0
The shmem/hugetlbfs memory types are supported for write-protection
messages very lately. Update the man page to reflect that.
Signed-off-by: Peter Xu <[email protected]>
---
man2/userfaultfd.2 | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2
index 6b9412aaf..9b5ec0358 100644
--- a/man2/userfaultfd.2
+++ b/man2/userfaultfd.2
@@ -270,13 +270,18 @@ Since Linux 4.11,
userfaultfd can be also used with hugetlbfs and shared memory mappings.
.\"
.SS Userfaultfd write-protect mode (since 5.7)
-Since Linux 5.7, userfaultfd supports write-protect mode.
+Since Linux 5.7, userfaultfd supports write-protect mode for anonymous memory.
The user needs to first check availability of this feature using
.B UFFDIO_API
ioctl against the feature bit
.B UFFD_FEATURE_PAGEFAULT_FLAG_WP
before using this feature.
.PP
+Since Linux 5.19, the write-protection mode was also supported on shmem and hugetlbfs
+memory types.
+It can be detected with the feature bit
+.BR UFFD_FEATURE_WP_HUGETLBFS_SHMEM .
+.PP
To register with userfaultfd write-protect mode, the user needs to initiate the
.B UFFDIO_REGISTER
ioctl with mode
@@ -327,8 +332,6 @@ ioctl, whose
should have the flag
.B UFFDIO_WRITEPROTECT_MODE_WP
cleared upon the faulted page or range.
-.PP
-Write-protect mode supports only private anonymous memory.
.\"
.SS Userfaultfd minor fault mode (since 5.13)
Since Linux 5.13,
--
2.32.0
On Mon, Jun 06, 2022 at 08:52:25PM +0200, Alejandro Colomar wrote:
> Hi Peter,
Hi, Alex,
>
> On 6/3/22 19:37, Peter Xu wrote:
> > v2:
> > - Use semantic newlines always in patch 1 [Alex]
> > - Fix s/.BR/.B/ in patch 2 [Alex]
> > - Rebased to http://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git
> >
> > Add the two missing pieces till latest 5.19-rc1: the UFFD_USER_MODE_ONLY
> > flag, and also the recent wr-protect support on shmem and hugetlbfs.
> >
> > Please review, thanks.
> >
> > Peter Xu (2):
> > userfaultfd.2: Add section for UFFD_USER_MODE_ONLY
> > userfaultfd.2: Update on write-protection support
> >
> > man2/userfaultfd.2 | 23 ++++++++++++++++++-----
> > 1 file changed, 18 insertions(+), 5 deletions(-)
> >
>
>
> I think the patch below would improve a little bit the wording (and
> newlines). I still have a bit of trouble understanding "When a
> kernel-originated fault was triggered on the registered range with this
> userfaultfd". Did you maybe mean "range registered" instead of "registered
> range"?
Since I'm not a native speaker I don't immediately see the difference
between the two.. What I wanted to express is all the memory ranges that
we registered with UFFDIO_REGISTER ioctl, and further it was trying to
describe what the kernel will do when there're any page faults that were
triggered upon those ranges from a kernel context.
It's always challenging for me to grasp how you prefer the newlines are
made, but anyway below changes looks good to me. Thanks,
>
> Thanks,
>
> Alex
>
>
> diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2
> index 9b5ec0358..0c0a4f687 100644
> --- a/man2/userfaultfd.2
> +++ b/man2/userfaultfd.2
> @@ -62,11 +62,11 @@ flag in
> .BR open (2).
> .TP
> .B UFFD_USER_MODE_ONLY
> -This is an userfaultfd specific flag that was introduced since Linux 5.11.
> -When set, the userfaultfd object will only be able to handle page faults
> -originated from the userspace on the registered regions.
> -When a kernel originated fault was triggered on the registered range with
> -this userfaultfd, a
> +This is an userfaultfd-specific flag that was introduced in Linux 5.11.
> +When set, the userfaultfd object will only be able to handle
> +page faults originated from the user space on the registered regions.
> +When a kernel-originated fault was triggered
> +on the registered range with this userfaultfd, a
> .B SIGBUS
> signal will be delivered.
> .PP
> @@ -277,8 +277,9 @@ ioctl against the feature bit
> .B UFFD_FEATURE_PAGEFAULT_FLAG_WP
> before using this feature.
> .PP
> -Since Linux 5.19, the write-protection mode was also supported on shmem and
> hugetlbfs
> -memory types.
> +Since Linux 5.19,
> +the write-protection mode was also supported on
> +shmem and hugetlbfs memory types.
> It can be detected with the feature bit
> .BR UFFD_FEATURE_WP_HUGETLBFS_SHMEM .
> .PP
>
>
> --
> Alejandro Colomar
> <http://www.alejandro-colomar.es/>
--
Peter Xu
Hi Peter,
On 6/3/22 19:37, Peter Xu wrote:
> v2:
> - Use semantic newlines always in patch 1 [Alex]
> - Fix s/.BR/.B/ in patch 2 [Alex]
> - Rebased to http://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git
>
> Add the two missing pieces till latest 5.19-rc1: the UFFD_USER_MODE_ONLY
> flag, and also the recent wr-protect support on shmem and hugetlbfs.
>
> Please review, thanks.
>
> Peter Xu (2):
> userfaultfd.2: Add section for UFFD_USER_MODE_ONLY
> userfaultfd.2: Update on write-protection support
>
> man2/userfaultfd.2 | 23 ++++++++++++++++++-----
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
I think the patch below would improve a little bit the wording (and
newlines). I still have a bit of trouble understanding "When a
kernel-originated fault was triggered on the registered range with this
userfaultfd". Did you maybe mean "range registered" instead of
"registered range"?
Thanks,
Alex
diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2
index 9b5ec0358..0c0a4f687 100644
--- a/man2/userfaultfd.2
+++ b/man2/userfaultfd.2
@@ -62,11 +62,11 @@ flag in
.BR open (2).
.TP
.B UFFD_USER_MODE_ONLY
-This is an userfaultfd specific flag that was introduced since Linux 5.11.
-When set, the userfaultfd object will only be able to handle page faults
-originated from the userspace on the registered regions.
-When a kernel originated fault was triggered on the registered range with
-this userfaultfd, a
+This is an userfaultfd-specific flag that was introduced in Linux 5.11.
+When set, the userfaultfd object will only be able to handle
+page faults originated from the user space on the registered regions.
+When a kernel-originated fault was triggered
+on the registered range with this userfaultfd, a
.B SIGBUS
signal will be delivered.
.PP
@@ -277,8 +277,9 @@ ioctl against the feature bit
.B UFFD_FEATURE_PAGEFAULT_FLAG_WP
before using this feature.
.PP
-Since Linux 5.19, the write-protection mode was also supported on shmem
and hugetlbfs
-memory types.
+Since Linux 5.19,
+the write-protection mode was also supported on
+shmem and hugetlbfs memory types.
It can be detected with the feature bit
.BR UFFD_FEATURE_WP_HUGETLBFS_SHMEM .
.PP
--
Alejandro Colomar
<http://www.alejandro-colomar.es/>
On Mon, Jun 6, 2022 at 12:40 PM Peter Xu <[email protected]> wrote:
>
> On Mon, Jun 06, 2022 at 08:52:25PM +0200, Alejandro Colomar wrote:
> > Hi Peter,
>
> Hi, Alex,
>
> >
> > On 6/3/22 19:37, Peter Xu wrote:
> > > v2:
> > > - Use semantic newlines always in patch 1 [Alex]
> > > - Fix s/.BR/.B/ in patch 2 [Alex]
> > > - Rebased to http://www.alejandro-colomar.es/src/alx/linux/man-pages/man-pages.git
> > >
> > > Add the two missing pieces till latest 5.19-rc1: the UFFD_USER_MODE_ONLY
> > > flag, and also the recent wr-protect support on shmem and hugetlbfs.
> > >
> > > Please review, thanks.
> > >
> > > Peter Xu (2):
> > > userfaultfd.2: Add section for UFFD_USER_MODE_ONLY
> > > userfaultfd.2: Update on write-protection support
> > >
> > > man2/userfaultfd.2 | 23 ++++++++++++++++++-----
> > > 1 file changed, 18 insertions(+), 5 deletions(-)
> > >
> >
> >
> > I think the patch below would improve a little bit the wording (and
> > newlines). I still have a bit of trouble understanding "When a
> > kernel-originated fault was triggered on the registered range with this
> > userfaultfd". Did you maybe mean "range registered" instead of "registered
> > range"?
>
> Since I'm not a native speaker I don't immediately see the difference
> between the two.. What I wanted to express is all the memory ranges that
> we registered with UFFDIO_REGISTER ioctl, and further it was trying to
> describe what the kernel will do when there're any page faults that were
> triggered upon those ranges from a kernel context.
>
> It's always challenging for me to grasp how you prefer the newlines are
> made, but anyway below changes looks good to me. Thanks,
I think "range registered" Alejandro suggested is a bit more natural,
just because that's the way you'd say it if we were slightly more
verbose:
"When a kernel-originated fault was triggered on the range [that was
previously] registered with this userfaultfd, ..."
Of course leaving out "that was previously" is fine, but I think the
ordering "range registered" remains more natural.
Another alternative I find equally natural which keeps the existing
ordering might be something like:
"... on the userfaultfd-registered range ..."
>
> >
> > Thanks,
> >
> > Alex
> >
> >
> > diff --git a/man2/userfaultfd.2 b/man2/userfaultfd.2
> > index 9b5ec0358..0c0a4f687 100644
> > --- a/man2/userfaultfd.2
> > +++ b/man2/userfaultfd.2
> > @@ -62,11 +62,11 @@ flag in
> > .BR open (2).
> > .TP
> > .B UFFD_USER_MODE_ONLY
> > -This is an userfaultfd specific flag that was introduced since Linux 5.11.
> > -When set, the userfaultfd object will only be able to handle page faults
> > -originated from the userspace on the registered regions.
> > -When a kernel originated fault was triggered on the registered range with
> > -this userfaultfd, a
> > +This is an userfaultfd-specific flag that was introduced in Linux 5.11.
> > +When set, the userfaultfd object will only be able to handle
> > +page faults originated from the user space on the registered regions.
> > +When a kernel-originated fault was triggered
> > +on the registered range with this userfaultfd, a
> > .B SIGBUS
> > signal will be delivered.
> > .PP
> > @@ -277,8 +277,9 @@ ioctl against the feature bit
> > .B UFFD_FEATURE_PAGEFAULT_FLAG_WP
> > before using this feature.
> > .PP
> > -Since Linux 5.19, the write-protection mode was also supported on shmem and
> > hugetlbfs
> > -memory types.
> > +Since Linux 5.19,
> > +the write-protection mode was also supported on
> > +shmem and hugetlbfs memory types.
> > It can be detected with the feature bit
> > .BR UFFD_FEATURE_WP_HUGETLBFS_SHMEM .
> > .PP
> >
> >
> > --
> > Alejandro Colomar
> > <http://www.alejandro-colomar.es/>
>
>
>
>
> --
> Peter Xu
>