linux-toradex.git/include/linux/ptrace.h, branch v6.7-rc8

kill signal_pt_regs()

2022-10-23T22:06:54+00:00

Once upon at it was used on hot paths, but that had not been
true since 2013.  IOW, there's no point for arch-optimized
equivalent of task_pt_regs(current) - remaining two users are
not worth bothering with.

Signed-off-by: Al Viro

ptrace/xtensa: Replace PT_SINGLESTEP with TIF_SINGLESTEP

2022-05-11T19:33:44+00:00

xtensa is the last user of the PT_SINGLESTEP flag.  Changing tsk->ptrace in
user_enable_single_step and user_disable_single_step without locking could
potentiallly cause problems.

So use a thread info flag instead of a flag in tsk->ptrace.  Use TIF_SINGLESTEP
that xtensa already had defined but unused.

Remove the definitions of PT_SINGLESTEP and PT_BLOCKSTEP as they have no more users.

Cc: stable@vger.kernel.org
Acked-by: Max Filippov 
Tested-by: Kees Cook 
Reviewed-by: Oleg Nesterov 
Link: https://lkml.kernel.org/r/20220505182645.497868-4-ebiederm@xmission.com
Signed-off-by: "Eric W. Biederman"

ptrace/um: Replace PT_DTRACE with TIF_SINGLESTEP

2022-05-11T19:33:33+00:00

User mode linux is the last user of the PT_DTRACE flag.  Using the flag to indicate
single stepping is a little confusing and worse changing tsk->ptrace without locking
could potentionally cause problems.

So use a thread info flag with a better name instead of flag in tsk->ptrace.

Remove the definition PT_DTRACE as uml is the last user.

Cc: stable@vger.kernel.org
Acked-by: Johannes Berg 
Tested-by: Kees Cook 
Reviewed-by: Oleg Nesterov 
Link: https://lkml.kernel.org/r/20220505182645.497868-3-ebiederm@xmission.com
Signed-off-by: "Eric W. Biederman"

ptrace: Return the signal to continue with from ptrace_stop

2022-03-18T14:52:10+00:00

The signal a task should continue with after a ptrace stop is
inconsistently read, cleared, and sent.  Solve this by reading and
clearing the signal to be sent in ptrace_stop.

In an ideal world everything except ptrace_signal would share a common
implementation of continuing with the signal, so ptracers could count
on the signal they ask to continue with actually being delivered.  For
now retain bug compatibility and just return with the signal number
the ptracer requested the code continue with.

Link: https://lkml.kernel.org/r/875yoe7qdp.fsf_-_@email.froward.int.ebiederm.org
Reviewed-by: Kees Cook 
Signed-off-by: "Eric W. Biederman"

ptrace: Move setting/clearing ptrace_message into ptrace_stop

2022-03-18T14:44:19+00:00

Today ptrace_message is easy to overlook as it not a core part of
ptrace_stop.  It has been overlooked so much that there are places
that set ptrace_message and don't clear it, and places that never set
it.  So if you get an unlucky sequence of events the ptracer may be
able to read a ptrace_message that does not apply to the current
ptrace stop.

Move setting of ptrace_message into ptrace_stop so that it always gets
set before the stop, and always gets cleared after the stop.  This
prevents non-sense from being reported to userspace and makes
ptrace_message more visible in the ptrace helper functions so that
kernel developers can see it.

Link: https://lkml.kernel.org/r/87bky67qfv.fsf_-_@email.froward.int.ebiederm.org
Acked-by: Oleg Nesterov 
Reviewed-by: Kees Cook 
Signed-off-by: "Eric W. Biederman"

ptrace: Create ptrace_report_syscall_{entry,exit} in ptrace.h

2022-03-10T19:35:08+00:00

Rename tracehook_report_syscall_{entry,exit} to
ptrace_report_syscall_{entry,exit} and place them in ptrace.h

There is no longer any generic tracehook infractructure so make
these ptrace specific functions ptrace specific.

Reviewed-by: Kees Cook 
Link: https://lkml.kernel.org/r/20220309162454.123006-3-ebiederm@xmission.com
Signed-off-by: "Eric W. Biederman"

ptrace: Move ptrace_report_syscall into ptrace.h

2022-03-10T19:31:01+00:00

Move ptrace_report_syscall from tracehook.h into ptrace.h where it
belongs.

Reviewed-by: Kees Cook 
Link: https://lkml.kernel.org/r/20220309162454.123006-1-ebiederm@xmission.com
Signed-off-by: "Eric W. Biederman"

ptrace: Remove the unnecessary arguments from arch_ptrace_stop

2021-10-06T16:27:41+00:00

Both arch_ptrace_stop_needed and arch_ptrace_stop are called with an
exit_code and a siginfo structure.  Neither argument is used by any of
the implementations so just remove the unneeded arguments.

The two arechitectures that implement arch_ptrace_stop are ia64 and
sparc.  Both architectures flush their register stacks before a
ptrace_stack so that all of the register information can be accessed
by debuggers.

As the question of if a register stack needs to be flushed is
independent of why ptrace is stopping not needing arguments make sense.

Cc: David Miller 
Cc: sparclinux@vger.kernel.org
Link: https://lkml.kernel.org/r/87lf3mx290.fsf@disp2133
Reviewed-by: Kees Cook 
Signed-off-by: "Eric W. Biederman"

include/linux: remove repeated words

2021-02-26T17:41:03+00:00

Drop the doubled word "for" in a comment. {firewire-cdev.h}
Drop the doubled word "in" in a comment. {input.h}
Drop the doubled word "a" in a comment. {mdev.h}
Drop the doubled word "the" in a comment. {ptrace.h}

Link: https://lkml.kernel.org/r/20210126232444.22861-1-rdunlap@infradead.org
Signed-off-by: Randy Dunlap 
Cc: Stefan Richter 
Cc: Dmitry Torokhov 
Cc: Kirti Wankhede 
Cc: Oleg Nesterov 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

signal: Remove the signal number and task parameters from force_sig_info

2019-05-29T14:31:44+00:00

force_sig_info always delivers to the current task and the signal
parameter always matches info.si_signo.  So remove those parameters to
make it a simpler less error prone interface, and to make it clear
that none of the callers are doing anything clever.

This guarantees that force_sig_info will not grow any new buggy
callers that attempt to call force_sig on a non-current task, or that
pass an signal number that does not match info.si_signo.

Signed-off-by: "Eric W. Biederman"