[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220420180323.GA14947@redhat.com>
Date: Wed, 20 Apr 2022 20:03:23 +0200
From: Oleg Nesterov <oleg@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: rjw@...ysocki.net, mingo@...nel.org, vincent.guittot@...aro.org,
dietmar.eggemann@....com, rostedt@...dmis.org, mgorman@...e.de,
ebiederm@...ssion.com, bigeasy@...utronix.de,
Will Deacon <will@...nel.org>, linux-kernel@...r.kernel.org,
tj@...nel.org, linux-pm@...r.kernel.org
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.
Powered by blists - more mailing lists