[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z0S3isgc-QlEF7oW@x1n>
Date: Mon, 25 Nov 2024 12:44:42 -0500
From: Peter Xu <peterx@...hat.com>
To: stsp <stsp2@...dex.ru>
Cc: Linux kernel <linux-kernel@...r.kernel.org>,
Muhammad Usama Anjum <usama.anjum@...labora.com>
Subject: Re: userfaultfd: two-step UFFDIO_API always gives -EINVAL
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
Powered by blists - more mailing lists