On Mon, Jan 24, 2022 at 03:29:56PM +0100, Peter Zijlstra wrote:
> On Fri, Jan 21, 2022 at 04:18:46PM +0100, Peter Zijlstra wrote:
> > Something like this, still yuck though. Also still need to write me a
> > test for this.
> >
> > --- a/kernel/sched/umcg.c
> > +++ b/kernel/sched/umcg.c
> > @@ -232,6 +232,8 @@ static int umcg_update_state(struct task
> > /* Called from syscall enter path and exceptions that can schedule */
> > void umcg_sys_enter(struct pt_regs *regs, long syscall)
> > {
> > + current->umcg_timeout = 0;
> > +
> > /* avoid recursion vs our own syscalls */
> > if (syscall == __NR_umcg_wait ||
> > syscall == __NR_umcg_ctl)
> > @@ -519,6 +521,7 @@ void umcg_notify_resume(struct pt_regs *
> > struct umcg_task __user *self = tsk->umcg_task;
> > bool worker = tsk->flags & PF_UMCG_WORKER;
> > u32 state;
> > + int ret;
> >
> > /* avoid recursion vs schedule() */
> > if (worker)
> > @@ -554,12 +557,17 @@ void umcg_notify_resume(struct pt_regs *
> > umcg_unpin_pages();
> > }
> >
> > - switch (umcg_wait(0)) {
> > + ret = umcg_wait(tsk->umcg_timeout);
>
> Oh how I hate signals... this can get scribbled by a syscall/fault from
> sigcontext :/
>
> Maybe I can recover the timo argument from the original syscall
> pt_regs.. let me try.
Urgh, recursive hell... If the signal does *anything* that tickles
notify-resume it'll find RUNNABLE and go wait there --- ad infinitum.
I need to go cook dinner, I'll prod more at this later
