On Mon, Jun 6, 2022 at 12:40 PM Peter Xu <peterx@xxxxxxxxxx> 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 >
