Sebastian Andrzej Siewior <[email protected]> writes:
> From: Thomas Gleixner <[email protected]>
>
> Upstream commit '53da1d9456fe7f8 fix ptrace slowness' is nothing more
> than a bandaid around the ptrace design trainwreck. It's not a
> correctness issue, it's merily a cosmetic bandaid.
This patch comes with no justification or reason to remove the
``cosmetic bandaid''. The description in 53da1d9456fe ("fix ptrace
slowness") is quite persuasive that there is a real world issue.
So while this may be a good idea to remove this. I don't see any
description of testing to indicate this won't cause uml to regresssion.
Nor do I see any compelling reason except code tidiness to remove this.
As such until adequate descriptions can be provideded.
Nacked-by: "Eric W. Biederman" <[email protected]>
> Signed-off-by: Thomas Gleixner <[email protected]>
> Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
> ---
> kernel/signal.c | 8 --------
> 1 file changed, 8 deletions(-)
>
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -1876,15 +1876,7 @@ static void ptrace_stop(int exit_code, i
> if (gstop_done && ptrace_reparented(current))
> do_notify_parent_cldstop(current, false, why);
>
> - /*
> - * Don't want to allow preemption here, because
> - * sys_ptrace() needs this task to be inactive.
> - *
> - * XXX: implement read_unlock_no_resched().
> - */
> - preempt_disable();
> read_unlock(&tasklist_lock);
> - preempt_enable_no_resched();
> freezable_schedule();
> } else {
> /*
