Re: [RFC PATCH for 4.17 02/21] rseq: Introduce restartable sequences system call (v12)

On Wed, Mar 28, 2018 at 10:47:54AM -0400, Mathieu Desnoyers wrote:

----- On Mar 28, 2018, at 8:50 AM, Peter Zijlstra peterz@infradead.org wrote:

quoted

On Tue, Mar 27, 2018 at 12:05:23PM -0400, Mathieu Desnoyers wrote:

quoted

diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index fb5fc458547f..66b070444a7e 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h

@@ -1249,6 +1249,7 @@ static inline void __set_task_cpu(struct task_struct *p,

unsigned int cpu)
 #endif
 	p->wake_cpu = cpu;
 #endif
+	rseq_migrate(p);
 }

I think you want that in set_task_cpu(), right next to nr_migrations++.

This would miss the __set_task_cpu() call from sched_fork() and wake_up_new_task().

Correct; but since those are _new_ tasks they _SHOULD_ not have an
active RSEQ to begin with.

Those cases are not accounted as explicit "migrations", but it does change the CPU
of the current task. So if for some weird reason userspace wants to fork() while in
a rseq critical section, we want to trigger a rseq restart.

If at all possible I would make it SIGSEGV when issueing SYSCALL()s from
within an RSEQ.

An alternative to this would be to call rseq_migrate() in rseq_fork().

Thoughts ?

Yes, don't try and support that at all. It's _insane_.