Messages in this thread | | | Date | Mon, 20 Jul 2020 16:02:24 +0200 | From | Oleg Nesterov <> | Subject | Re: 5.8-rc*: kernel BUG at kernel/signal.c:1917 |
| |
On 07/20, Peter Zijlstra wrote: > > Also, is there any way to not have ptrace do this?
Well, we need to ensure that even SIGKILL can't wake the tracee up while debugger plays with its registers/etc.
> How performance > critical is this ptrace path?
This is a slow path.
We can probably change ptrace_check_attach() to call ptrace_freeze_traced() after wait_task_inactive(), but I would like to not do this... Because we actually want to avoid wait_task_inactive() when possible.
Perhaps ptrace_freeze_traced() can __task_rq_lock() to avoid the race with __schedule() ? No, it reads prev_state before rq_lock().
> Because I really hate having to add code > to __schedule() to deal with this horrible thing.
Oh yes, I agree.
I have to admit, I do not understand the usage of prev_state in schedule(), it looks really, really subtle...
Oleg.
| |