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: <cfc58081-c49a-4f30-bb39-966c7f18b9eb@yandex.ru>
Date: Tue, 26 Nov 2024 10:39:19 +0300
From: stsp <stsp2@...dex.ru>
To: Axel Rasmussen <axelrasmussen@...gle.com>, Peter Xu <peterx@...hat.com>
Cc: Linux kernel <linux-kernel@...r.kernel.org>,
 Muhammad Usama Anjum <usama.anjum@...labora.com>,
 Mike Rapoport <rppt@...nel.org>
Subject: Re: userfaultfd: two-step UFFDIO_API always gives -EINVAL

26.11.2024 01:42, Axel Rasmussen пишет:
> For what it's worth, I still don't like the two-step handshake design,
> my preference is still an API like this:
>
> 1. userspace asks for the features it wants
> 2. kernel responds with the (possibly subset of) features it actually supports
> 3. userspace is free to carry on with perhaps limited features, or
> exit with error, or ...

4. pass the needed features to
UFFDIO_REGISTER, correct?

> But, I think at that point the ship has already sailed. I think to
> maintain compatibility with existing programs there isn't much we can
> do at this point.
Please, just why do you have that UFFD_API
const? Only to call every screw-up like this
one, a sailed ship? :)
Why not to add UFFD_API_v2?
Then UFFD_API_v3?
Full binary and source compatibility is
therefore preserved, you only need to
update the man page to document the
latest one.