Message ID | 20231003194547.2237424-3-axelrasmussen@google.com (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | userfaultfd man page updates | expand |
Hi Axel, On Tue, Oct 03, 2023 at 12:45:44PM -0700, Axel Rasmussen wrote: > First, it is not correct that repeated UFFDIO_API calls result in > EINVAL. This is true *if both calls enable features*, but in the case > where we're doing a two-step feature detection handshake, the kernel > explicitly expects 2 calls (one with no features set). So, correct this > description. > > Then, some new error cases have been added to the kernel recently, and > the man page wasn't updated to note these. So, add in descriptions of > these new error cases. > > Signed-off-by: Axel Rasmussen <axelrasmussen@google.com> Patch applied. Thanks, Alex > --- > man2/ioctl_userfaultfd.2 | 24 +++++++++++++++++++----- > 1 file changed, 19 insertions(+), 5 deletions(-) > > diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 > index ef352a69d..28dd2fcdd 100644 > --- a/man2/ioctl_userfaultfd.2 > +++ b/man2/ioctl_userfaultfd.2 > @@ -256,17 +256,31 @@ refers to an address that is outside the calling process's > accessible address space. > .TP > .B EINVAL > -The userfaultfd has already been enabled by a previous > -.B UFFDIO_API > -operation. > -.TP > -.B EINVAL > The API version requested in the > .I api > field is not supported by this kernel, or the > .I features > field passed to the kernel includes feature bits that are not supported > by the current kernel version. > +.TP > +.B EINVAL > +A previous > +.B UFFDIO_API > +call already enabled one or more features for this userfaultfd. > +Calling > +.B UFFDIO_API > +twice, > +the first time with no features set, > +is explicitly allowed > +as per the two-step feature detection handshake. > +.TP > +.B EPERM > +The > +.B UFFD_FEATURE_EVENT_FORK > +feature was enabled, > +but the calling process doesn't have the > +.B CAP_SYS_PTRACE > +capability. > .\" FIXME In the above error case, the returned 'uffdio_api' structure is > .\" zeroed out. Why is this done? This should be explained in the manual page. > .\" > -- > 2.42.0.609.gbb76f46606-goog >
diff --git a/man2/ioctl_userfaultfd.2 b/man2/ioctl_userfaultfd.2 index ef352a69d..28dd2fcdd 100644 --- a/man2/ioctl_userfaultfd.2 +++ b/man2/ioctl_userfaultfd.2 @@ -256,17 +256,31 @@ refers to an address that is outside the calling process's accessible address space. .TP .B EINVAL -The userfaultfd has already been enabled by a previous -.B UFFDIO_API -operation. -.TP -.B EINVAL The API version requested in the .I api field is not supported by this kernel, or the .I features field passed to the kernel includes feature bits that are not supported by the current kernel version. +.TP +.B EINVAL +A previous +.B UFFDIO_API +call already enabled one or more features for this userfaultfd. +Calling +.B UFFDIO_API +twice, +the first time with no features set, +is explicitly allowed +as per the two-step feature detection handshake. +.TP +.B EPERM +The +.B UFFD_FEATURE_EVENT_FORK +feature was enabled, +but the calling process doesn't have the +.B CAP_SYS_PTRACE +capability. .\" FIXME In the above error case, the returned 'uffdio_api' structure is .\" zeroed out. Why is this done? This should be explained in the manual page. .\"
First, it is not correct that repeated UFFDIO_API calls result in EINVAL. This is true *if both calls enable features*, but in the case where we're doing a two-step feature detection handshake, the kernel explicitly expects 2 calls (one with no features set). So, correct this description. Then, some new error cases have been added to the kernel recently, and the man page wasn't updated to note these. So, add in descriptions of these new error cases. Signed-off-by: Axel Rasmussen <axelrasmussen@google.com> --- man2/ioctl_userfaultfd.2 | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-)