Messages in this thread | | | Date | Wed, 20 Apr 2022 20:03:23 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH 2/5] sched,ptrace: Fix ptrace_check_attach() vs PREEMPT_RT |
| |
On 04/20, Peter Zijlstra wrote: > > Does something like: > > #define JOBCTL_TRACED_BIT 25 > #define JOBCTL_TRACED_QUIESCE_BIT 26 > > work?
Agreed! ;)
> > } else { > > /* > > * By the time we got the lock, our tracer went away. > > - * Don't drop the lock yet, another tracer may come. > > - * > > + * Don't drop the lock yet, another tracer may come, > > + * tasklist protects us from ptrace_freeze_traced(). > > + */ > > + __set_current_state(TASK_RUNNING); > > + clear_traced_xxx(); > > + /* > > * If @gstop_done, the ptracer went away between group stop > > * completion and here. During detach, it would have set > > * JOBCTL_STOP_PENDING on us and we'll re-enter > > This is that same else clause again; perhaps make signal_wake_up_state() > also clear TRACED_XXX instead?
I swear, I too thought about this after my last email. Yes, I think this makes sense. Thanks,
Oleg.
| |