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

\
 
 \ /
  Last update: 2020-07-20 16:03    [W:0.240 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site