lkml.org 
[lkml]   [2022]   [Apr]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.

\
 
 \ /
  Last update: 2022-04-20 20:04    [W:0.228 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site