[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Ymr5Ga3gcqG4ZAMt@hirez.programming.kicks-ass.net>
Date: Thu, 28 Apr 2022 22:29:13 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
Cc: Oleg Nesterov <oleg@...hat.com>, rjw@...ysocki.net,
mingo@...nel.org, vincent.guittot@...aro.org,
dietmar.eggemann@....com, rostedt@...dmis.org, mgorman@...e.de,
bigeasy@...utronix.de, Will Deacon <will@...nel.org>,
linux-kernel@...r.kernel.org, tj@...nel.org,
linux-pm@...r.kernel.org
Subject: Re: [PATCH v2 2/5] sched,ptrace: Fix ptrace_check_attach() vs
PREEMPT_RT
On Tue, Apr 26, 2022 at 07:24:03PM -0500, Eric W. Biederman wrote:
> But doing:
>
> /* Don't stop if the task is dying */
> if (unlikely(__fatal_signal_pending(current)))
> return exit_code;
>
> Should work.
Something like so then...
---
Subject: signal,ptrace: Don't stop dying tasks
From: Peter Zijlstra <peterz@...radead.org>
Date: Thu Apr 28 22:17:56 CEST 2022
Oleg pointed out that the tracee can already be killed such that
fatal_signal_pending() is true. In that case signal_wake_up_state()
cannot be relied upon to be responsible for the wakeup -- something
we're going to want to rely on.
As such, explicitly handle this case.
Suggested-by: "Eric W. Biederman" <ebiederm@...ssion.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
---
kernel/signal.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -2226,6 +2226,10 @@ static int ptrace_stop(int exit_code, in
spin_lock_irq(¤t->sighand->siglock);
}
+ /* Don't stop if the task is dying. */
+ if (unlikely(__fatal_signal_pending(current)))
+ return exit_code;
+
/*
* schedule() will not sleep if there is a pending signal that
* can awaken the task.
Powered by blists - more mailing lists