linux-kernel - Re: userfaultfd: two-step UFFDIO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <9b68a811-ffed-4595-83a6-0ef78a7de806@yandex.ru>
Date: Mon, 25 Nov 2024 20:32:54 +0300
From: stsp <stsp2@...dex.ru>
To: Peter Xu <peterx@...hat.com>
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

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?