On Tue, Jan 3, 2023 at 10:36 AM Andy Lutomirski <luto@xxxxxxxxxx> wrote:
>
> I have a rather different suggestion: make a special mapping. Jason,
> you're trying to shoehorn all kinds of bizarre behavior into the core
> mm, and none of that seems to me to belong to the core mm. Instead,
> have an actual special mapping with callbacks that does the right
> thing. No fancy VM flags.
I don't disagree, but honestly, my deeper reaction is "this is not worth it".
I think the real issue here is that Jason has to prove that this is
such a big deal that the VM has to be modified *at*all* for this.
Honestly, "getrandom()" performance simply is not important enough to
design VM changes for.
Do some people care? Debatable. Jason cares, sure. But people have
gotten used to doing their own random number implementations if they
*really* care, and yes, they've gotten them wrong, or they've not
performed as well as they could, but on the whole this is still a
really tiny thing, and Jason is trying to micro-optimize something
that THE KERNEL SHOULD NOT CARE ABOUT.
This should all be in libc. Not in the kernel with special magic vdso
support and special buffer allocations. The kernel should give good
enough support that libc can do a good job, but the kernel should
simply *not* take the approach of "libc will get this wrong, so let's
just do all the work for it".
Let user space do their own percpu areas if they really care. And most
(as in 99.9%) of all user space won't care at all, and is perfectly
happy just doing a read() from /dev/urandom or using our existing
"getrandom()" without any super-clever vdso support with magic
temporary buffer handling.
Now, if the magic buffers were something cool that were a generic
concept that a lot of *other* cases would also kill for, that's one
thing. But this is such a small special case that absolutely *nobody*
has asked for, and that nothing else wants.
Linus
