Yes, there are indeed pieces missing for this use-case. I intend to push another system call for the next merge window (4.19): "cpu_opv" [1]. It stands for "CPU

Yes, there are indeed pieces missing for this use-case. I intend to push another system call for the next merge window (4.19): "cpu_opv" [1]. It stands for "CPU operation vector", which is needed to take care of moving user-level tasks around between per-cpu work-queues touched by rseq fast-paths in a way that is safe against CPU hotplug. It's also needed to migrate free memory between per-cpu memory pools modified by rseq fast-paths safely against CPU hotplug. Some of it can be approximated by setting cpu affinity, but it's racy against CPU hotplug. cpu_opv can be used as a slow-path fallback in pretty much all scenarios where the rseq fast-path aborts. rseq user-level APIs are pretty much limited to only work on the current CPU, whereas cpu_opv allows creating operations on per-cpu data structures [2] which take the CPU number as argument. If it happens to be on the current CPU, rseq can be used and it is fast, but if the CPU number is not the current CPU, or is an offline CPU, then cpu_opv takes care of performing the operation safely with respect to rseq critical sections, and other cpu_opv operations. [1] https://git.kernel.org/pub/scm/linux/kernel/git/rseq/linux-rseq.git/commit/?h=v4.18-rc1-rseq-20180619.2&id=293b0fb03e6dc9c70d2c5e6ce4065456aa8c4d5e https://git.kernel.org/pub/scm/linux/kernel/git/rseq/linux-r... [2] https://git.kernel.org/pub/scm/linux/kernel/git/rseq/linux-rseq.git/commit/?h=v4.18-rc1-rseq-20180619.2&id=d380b8e2f5f08c09ad893dc46cf530b45910914d https://git.kernel.org/pub/scm/linux/kernel/git/rseq/linux-r...