Re: [PATCH 00/16] ptrace: cleanups and calling do_cldstop with only siglock

On 2022-05-18 20:26:05 [-0700], Kyle Huey wrote: > Is there a git branch somewhere I can pull to test this? It doesn't apply > cleanly to Linus's tip. https://kernel.googlesource.com/pub/scm/linux/kernel/git/ebiederm/user-namespace.git ptrace_stop-cleanup-for-v5.19 > - Kyle Sebastian _

[PATCH 16/16] signal: Always call do_notify_parent_cldstop with siglock held

Now that siglock keeps tsk->parent and tsk->real_parent constant require that do_notify_parent_cldstop is called with tsk->siglock held instead of the tasklist_lock. As all of the callers of do_notify_parent_cldstop had to drop the siglock and take tasklist_lock this simplifies all of it's callers

[PATCH 15/16] ptrace: Use siglock instead of tasklist_lock in ptrace_check_attach

Now that siglock protects tsk->parent and tsk->ptrace there is no need to grab tasklist_lock in ptrace_check_attach. The siglock can handle all of the locking needs of ptrace_check_attach. Signed-off-by: "Eric W. Biederman" --- kernel/ptrace.c | 23 +-- 1 file changed, 9 ins

[PATCH 14/16] signal: Protect parent child relationships by childs siglock

The functions ptrace_stop and do_signal_stop have to drop siglock and grab tasklist_lock because the parent/child relation ship is guarded by tasklist_lock and not siglock. Simplify things by additionally guarding the parent/child relationship with siglock. This just requires a little bit of code

[PATCH 13/16] ptrace: Document why ptrace_setoptions does not need a lock

The functions that change ->ptrace are: ptrace_attach, ptrace_traceme, ptrace_init_task, __ptrace_unlink, ptrace_setoptions. Except for ptrace_setoptions all of the places where ->ptrace is modified hold tasklist_lock for write, and either the tracee or the tracer is modifies ->ptrace. When ptrac

[PATCH 12/16] ptrace: Stop protecting ptrace_set_signr with tasklist_lock

Now that ptrace_set_signr no longer sets task->exit_code the race documented in commit b72c186999e6 ("ptrace: fix race between ptrace_resume() and wait_task_stopped()") is no longer possible, as task->exit_code is only updated by wait during a ptrace_stop. As there is no possibilty of a race and p

[PATCH 11/16] ptrace: Use si_sino as the signal number to resume with

The signal number to resume with is already in si_signo. So instead of placing an extra copy in tsk->exit_code and later reading the extra copy from tsk->exit_code just read si_signo. Read si_signo in ptrace_do_notify where it is easy as the siginfo is a local variable. Only ptrace_report_syscal

[PATCH 10/16] ptrace: In ptrace_signal look at what the debugger did with siginfo

Now that siginfo is only modified by the tracer and that siginfo is cleared with the signal is canceled have ptrace_signal directly examine siginfo. This makes the code a little simpler and handles the case when the tracer exits without calling ptrace_detach. Signed-off-by: "Eric W. Biederman" -

[PATCH 08/16] ptrace: Only populate last_siginfo from ptrace

The code in ptrace_signal to populate siginfo if the signal number changed is buggy. If the tracer contined the tracee using ptrace_detach it is guaranteed to use the real_parent (or possibly a new tracer) but definitely not the origional tracer to populate si_pid and si_uid. Fix this bug by only

[PATCH 09/16] ptrace: In ptrace_setsiginfo deal with invalid si_signo

If the tracer calls PTRACE_SETSIGINFO it only has an effect if the tracee is stopped in ptrace_signal. When one of PTRACE_DETACH, PTRACE_SINGLESTEP, PTRACE_SINGLEBLOCK, PTRACE_SYSEMU, PTRACE_SYSEMU_SINGLESTEP, PTRACE_SYSCALL, or PTRACE_CONT pass in a signel number to continue with the kernel valid

[PATCH 07/16] signal: Wake up the designated parent

Today if a process is ptraced only the ptracer will ever be woken up in wait, if the parent is waiting with __WNOTHREAD. Update the code so that the real_parent can also be woken up with __WNOTHREAD even when the code is ptraced. Fixes: 75b95953a569 ("job control: Add @for_ptrace to do_notify_pa

[PATCH 06/16] ptrace: Remove unnecessary locking in ptrace_(get|set)siginfo

Since commit 9899d11f6544 ("ptrace: ensure arch_ptrace/ptrace_request can never race with SIGKILL") it has been unnecessary for ptrace_getsiginfo and ptrace_setsiginfo to use lock_task_sighand. Having the code taking an unnecessary lock is confusing as it suggests that other parts of the code need

[PATCH 04/16] powerpc/xmon: Use real_parent when displaying a list of processes

xmon has a bug (copied from kdb) that when showing a list of processes the debugger is listed as the parent, if a processes is being debugged. This is silly, and I expect it is rare enough no has noticed in practice. Update the code to use real_parent so that it is clear xmon does not want to dis

[PATCH 05/16] ptrace: Remove dead code from __ptrace_detach

Ever since commit 28d838cc4dfe ("Fix ptrace self-attach rule") it has been impossible to attach another thread in the same thread group. Remove the code from __ptrace_detach that was trying to support detaching from a thread in the same thread group. The code is dead and I can not make sense of w

[PATCH 02/16] signal/ia64: Remove unused definition of IA64_TASK_REAL_PARENT_OFFSET

Rather than update the unused definition of IA64_TASK_REAL_PARENT_OFFSENT when I move tsk->real_parent into signal_struct remove it now. Cc: linux-i...@vger.kernel.org Signed-off-by: "Eric W. Biederman" --- arch/ia64/kernel/asm-offsets.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/ia

[PATCH 03/16] kdb: Use real_parent when displaying a list of processes

kdb has a bug that when using the ps command to display a list of processes, if a process is being debugged the debugger as the parent process. This is silly, and I expect it never comes up in ptractice. As there is very little point in using gdb and kdb simultaneously. Update the code to use re

[PATCH 01/16] signal/alpha: Remove unused definition of TASK_REAL_PARENT

Rather than update this defition when I move tsk->real_parent into signal_struct remove it now. Cc: Richard Henderson Cc: Ivan Kokshaysky Cc: Matt Turner Cc: linux-al...@vger.kernel.org Signed-off-by: "Eric W. Biederman" --- arch/alpha/kernel/asm-offsets.c | 1 - 1 file changed, 1 deletion(-)

[PATCH 00/16] ptrace: cleanups and calling do_cldstop with only siglock

For ptrace_stop to work on PREEMT_RT no spinlocks can be taken once ptrace_freeze_traced has completed successfully. Which fundamentally means the lock dance of dropping siglock and grabbing tasklist_lock does not work on PREEMPT_RT. So I have worked through what is necessary so that tasklist_l

Re: [PATCH 19/30] panic: Add the panic hypervisor notifier list

On 18/05/2022 04:33, Petr Mladek wrote: > [...] > Anyway, I would distinguish it the following way. > > + If the notifier is preserving kernel log then it should be ideally > treated as kmsg_dump(). > > + It the notifier is saving another debugging data then it better > fits into the

Re: [PATCH 19/30] panic: Add the panic hypervisor notifier list

On 18/05/2022 04:58, Petr Mladek wrote: > [...] >> I does similar things like kmsg_dump() so it should be called in >> the same location (after info notifier list and before kdump). >> >> A solution might be to put it at these notifiers at the very >> end of the "info" list or make extra "dump" not

Re: [PATCH 19/30] panic: Add the panic hypervisor notifier list

On 18/05/2022 04:38, Petr Mladek wrote: > [...] > I have answered this in more detail in the other reply, see > https://lore.kernel.org/r/YoShZVYNAdvvjb7z@alley > > I agree that both notifiers in > > drivers/soc/bcm/brcmstb/pm/pm-arm.c > drivers/firmware/google/gsmi.c > > better fit into