Messages in this thread | | | Date | Thu, 28 Apr 2022 12:00:52 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH v2 1/5] sched,signal,ptrace: Rework TASK_TRACED, TASK_STOPPED state |
| |
On Tue, Apr 26, 2022 at 06:34:09PM -0500, Eric W. Biederman wrote: > Peter Zijlstra <peterz@infradead.org> writes: > > > Currently ptrace_stop() / do_signal_stop() rely on the special states > > TASK_TRACED and TASK_STOPPED resp. to keep unique state. That is, this > > state exists only in task->__state and nowhere else. > > > > There's two spots of bother with this: > > > > - PREEMPT_RT has task->saved_state which complicates matters, > > meaning task_is_{traced,stopped}() needs to check an additional > > variable. > > > > - An alternative freezer implementation that itself relies on a > > special TASK state would loose TASK_TRACED/TASK_STOPPED and will > > result in misbehaviour. > > > > As such, add additional state to task->jobctl to track this state > > outside of task->__state. > > > > NOTE: this doesn't actually fix anything yet, just adds extra state. > > > > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> > > > --- a/kernel/signal.c > > +++ b/kernel/signal.c > > @@ -770,7 +773,9 @@ void signal_wake_up_state(struct task_st > > * By using wake_up_state, we ensure the process will wake up and > > * handle its death signal. > > */ > > - if (!wake_up_state(t, state | TASK_INTERRUPTIBLE)) > > + if (wake_up_state(t, state | TASK_INTERRUPTIBLE)) > > + t->jobctl &= ~(JOBCTL_STOPPED | JOBCTL_TRACED); > > + else > > kick_process(t); > > } > > This hunk is subtle and I don't think it is actually what we want if the > code is going to be robust against tsk->__state becoming TASK_FROZEN.
Oooh, indeed. Yes, let me go back to that resume based thing as you suggest.
But first, let me go read all your patches :-)
| |