Thread (27 messages) flat view 27 messages, 6 authors, 2021-09-15

Re: [PATCH 2/4 v0.5] sched/umcg: RFC: add userspace atomic helpers

From: Peter Oskolkov <hidden>
Date: 2021-09-09 22:10:19
Also in: lkml

On Thu, Sep 9, 2021 at 2:21 PM Jann Horn [off-list ref] wrote:
[...]
quoted
Option 1: as you suggest, pin pages holding struct umcg_task in sys_umcg_ctl;
FWIW, there is a variant on this that might also be an option:

You can create a new memory mapping from kernel code and stuff pages
into it that were originally allocated as normal kernel pages. This is
done in a bunch of places, e.g.:

This has the advantage that it avoids pinning random pages that were
originally allocated from ZONE_MOVABLE blocks. (Or pinning hugepages,
or something like that.)
The downsides are that it reduces userspace's freedom to place the
UAPI structs wherever it wants (so userspace e.g. probably can't
directly put the struct in thread-local storage, instead it has to
store a pointer to the struct), and that you need to write a bunch of
code to create the mapping and allocate slots in these pages for
userspace threads.
Thanks again, Jann! Why do you think using custom mapping like this is
preferable to doing just kzalloc(size, GFP_USER), or maybe
alloc_page(GFP_USER)?

The documentation here
https://www.kernel.org/doc/html/latest/core-api/memory-allocation.html
says:

"GFP_USER means that the allocated memory is not movable and it must
be directly accessible by the kernel", which sounds exactly what we
need here.

[...]
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help