Re: [PATCH 2/5] sched,ptrace: Fix ptrace_check_attach() vs PREEMPT_RT

From: Oleg Nesterov <oleg@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: rjw@rjwysocki.net, mingo@kernel.org, vincent.guittot@linaro.org,
	dietmar.eggemann@arm.com, rostedt@goodmis.org, mgorman@suse.de,
	ebiederm@xmission.com, bigeasy@linutronix.de,
	Will Deacon <will@kernel.org>,
	linux-kernel@vger.kernel.org, tj@kernel.org,
	linux-pm@vger.kernel.org
Subject: Re: [PATCH 2/5] sched,ptrace: Fix ptrace_check_attach() vs PREEMPT_RT
Date: Wed, 20 Apr 2022 20:03:23 +0200	[thread overview]
Message-ID: <20220420180323.GA14947@redhat.com> (raw)
In-Reply-To: <20220420131731.GF2731@worktop.programming.kicks-ass.net>

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.