Re: userfaultfd: two-step UFFDIO_API always gives -EINVAL

[Peter Xu]

On Mon, Nov 25, 2024 at 08:32:54PM +0300, stsp wrote:
> 25.11.2024 20:13, Peter Xu пишет:
> > Old kernels will fail with -EINVAL, new will succeed.  It's already an ABI
> > violation, IMHO.
> > 
> > Not to mention I'm not sure what could happen if uffd feature flags can
> > change on the fly.  Your proposal means it can happen when anon missing
> > trap is enabled at least.  That's probably unwanted, and unnecessary
> > complexity to maintain to the kernel.
> OK, thanks for considering.
> 
> By the way, as we are at it, I have
> this usage question. I initially intended
> to use UFFD_FEATURE_WP_ASYNC, but
> it appears (and is documented so) to not
> deliver any notification.
> Why not?
> I am currently using UFFD_FEATURE_PAGEFAULT_FLAG_WP,
> but I only want to monitor the fact that
> the page was written to. With
> UFFD_FEATURE_WP_ASYNC it would be
> much faster, as the kernel resolves the
> fault for me. Yes, I've seen the mentioning
> of /proc/pages in docs (I don't even have
> /proc/pages - perhaps it was ment to be
> /proc/<pid>/pages?), but why such a
> complexity if all I need is the notification
> similar to what I get from
> UFFD_FEATURE_PAGEFAULT_FLAG_WP?

Apps who tracks snapshots needs the unmodified pages before being written.
Those cannot rely on kernel resolution because it needs more than "if the
page is written" - it also needs the page data before being written.

-- 
Peter Xu