Re: [PATCH v2 0/2] userfaultfd.2: Update to latest

[Axel Rasmussen]

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
>