triton: fix context schedule/wakeup race

Allow triton_context_wakeup() to run before triton_context_schedule().
When that happens, triton_context_schedule() now lets the context
running instead of putting it in sleep mode.

Note that, even though triton now allows triton_context_wakeup() to
happen before triton_context_schedule(), these two functions still need
to be paired and not nested. That is, in a sequence like the following,

triton_context_wakeup()
triton_context_wakeup()
triton_context_schedule()
triton_context_schedule()

the second triton_context_schedule() would put the context in sleep
mode. No matter how many triton_context_wakeup() have been called, the
first triton_context_schedule() "consumes" them all.

Being immune to schedule/wakeup inversion allows to fix the pppd_compat
module. This module needs to fork() to execute external programs. The
parent then waits for completion of its child using
triton_context_schedule(). When child terminates, the sigchld module
runs a callback that has to call triton_context_wakeup() to resume
execution of the parent.

The problem is that there is no synchronisation between the parent and
its child. When under stress, the child may execute faster than its
parent and the sigchld callback might run triton_context_wakeup()
before the parent had time to call triton_context_schedule().

Then accel-ppp might crash because the triton thread might have reset
ctx->thread to NULL, making triton_context_wakeup() write to invalid
memory when trying to insert the context in ctx->thread->wakeup_list[].

Synchronising the parent and its child completion's callback would
require cooperation from triton_context_schedule(). Otherwise we would
still have a time frame between the moment we let the callback waking
up the context and the moment we put the context in sleep mode.
Allowing schedule/wakeup call inversion in triton looks simpler since
it avoids modifying the current API.

Signed-off-by: Guillaume Nault <g.nault@alphalink.fr>

0 files changed, 0 insertions, 0 deletions