* [PATCH v2 1/4] arm64: ptrace: Add a comment describing our syscall entry/exit trap ABI
2020-07-02 21:26 [PATCH v2 0/4] arm64: Fix single-step handling Will Deacon
@ 2020-07-02 21:26 ` Will Deacon
2020-07-02 21:26 ` [PATCH v2 2/4] arm64: ptrace: Consistently use pseudo-singlestep exceptions Will Deacon
` (3 subsequent siblings)
4 siblings, 0 replies; 9+ messages in thread
From: Will Deacon @ 2020-07-02 21:26 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Luis Machado, Will Deacon, stable, Keno Fischer,
kernel-team
Our tracehook logic for syscall entry/exit raises a SIGTRAP back to the
tracer following a ptrace request such as PTRACE_SYSCALL. As part of this
procedure, we clobber the reported value of one of the tracee's general
purpose registers (x7 for native tasks, r12 for compat) to indicate
whether the stop occurred on syscall entry or exit. This is a slightly
unfortunate ABI, as it prevents the tracer from accessing the real
register value and is at odds with other similar stops such as seccomp
traps.
Since we're stuck with this ABI, expand the comment in our tracehook
logic to acknowledge the issue and descibe the behaviour in more detail.
Cc: <stable@vger.kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Luis Machado <luis.machado@linaro.org>
Reported-by: Keno Fischer <keno@juliacomputing.com>
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kernel/ptrace.c | 16 ++++++++++++++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 68b7f34a08f5..d71795dc3dbd 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1811,8 +1811,20 @@ static void tracehook_report_syscall(struct pt_regs *regs,
unsigned long saved_reg;
/*
- * A scratch register (ip(r12) on AArch32, x7 on AArch64) is
- * used to denote syscall entry/exit:
+ * We have some ABI weirdness here in the way that we handle syscall
+ * exit stops because we indicate whether or not the stop has been
+ * signalled from syscall entry or syscall exit by clobbering a general
+ * purpose register (ip/r12 for AArch32, x7 for AArch64) in the tracee
+ * and restoring its old value after the stop. This means that:
+ *
+ * - Any writes by the tracer to this register during the stop are
+ * ignored/discarded.
+ *
+ * - The actual value of the register is not available during the stop,
+ * so the tracer cannot save it and restore it later.
+ *
+ * - Syscall stops behave differently to seccomp and pseudo-step traps
+ * (the latter do not nobble any registers).
*/
regno = (is_compat_task() ? 12 : 7);
saved_reg = regs->regs[regno];
--
2.27.0.212.ge8ba1cc988-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 9+ messages in thread* [PATCH v2 2/4] arm64: ptrace: Consistently use pseudo-singlestep exceptions
2020-07-02 21:26 [PATCH v2 0/4] arm64: Fix single-step handling Will Deacon
2020-07-02 21:26 ` [PATCH v2 1/4] arm64: ptrace: Add a comment describing our syscall entry/exit trap ABI Will Deacon
@ 2020-07-02 21:26 ` Will Deacon
2020-07-10 14:02 ` Sasha Levin
2020-07-02 21:26 ` [PATCH v2 3/4] arm64: Override SPSR.SS when single-stepping is enabled Will Deacon
` (2 subsequent siblings)
4 siblings, 1 reply; 9+ messages in thread
From: Will Deacon @ 2020-07-02 21:26 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Luis Machado, Will Deacon, stable, Keno Fischer,
kernel-team
Although the arm64 single-step state machine can be fast-forwarded in
cases where we wish to generate a SIGTRAP without actually executing an
instruction, this has two major limitations outside of simply skipping
an instruction due to emulation.
1. Stepping out of a ptrace signal stop into a signal handler where
SIGTRAP is blocked. Fast-forwarding the stepping state machine in
this case will result in a forced SIGTRAP, with the handler reset to
SIG_DFL.
2. The hardware implicitly fast-forwards the state machine when executing
an SVC instruction for issuing a system call. This can interact badly
with subsequent ptrace stops signalled during the execution of the
system call (e.g. SYSCALL_EXIT or seccomp traps), as they may corrupt
the stepping state by updating the PSTATE for the tracee.
Resolve both of these issues by injecting a pseudo-singlestep exception
on entry to a signal handler and also on return to userspace following a
system call.
Cc: <stable@vger.kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Luis Machado <luis.machado@linaro.org>
Reported-by: Keno Fischer <keno@juliacomputing.com>
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/include/asm/thread_info.h | 1 +
arch/arm64/kernel/ptrace.c | 25 +++++++++++++++++++------
arch/arm64/kernel/signal.c | 11 ++---------
arch/arm64/kernel/syscall.c | 2 +-
4 files changed, 23 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/include/asm/thread_info.h b/arch/arm64/include/asm/thread_info.h
index 6ea8b6a26ae9..5e784e16ee89 100644
--- a/arch/arm64/include/asm/thread_info.h
+++ b/arch/arm64/include/asm/thread_info.h
@@ -93,6 +93,7 @@ void arch_release_task_struct(struct task_struct *tsk);
#define _TIF_SYSCALL_EMU (1 << TIF_SYSCALL_EMU)
#define _TIF_UPROBE (1 << TIF_UPROBE)
#define _TIF_FSCHECK (1 << TIF_FSCHECK)
+#define _TIF_SINGLESTEP (1 << TIF_SINGLESTEP)
#define _TIF_32BIT (1 << TIF_32BIT)
#define _TIF_SVE (1 << TIF_SVE)
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index d71795dc3dbd..7b46caea1278 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1830,12 +1830,23 @@ static void tracehook_report_syscall(struct pt_regs *regs,
saved_reg = regs->regs[regno];
regs->regs[regno] = dir;
- if (dir == PTRACE_SYSCALL_EXIT)
+ if (dir == PTRACE_SYSCALL_ENTER) {
+ if (tracehook_report_syscall_entry(regs))
+ forget_syscall(regs);
+ regs->regs[regno] = saved_reg;
+ } else if (!test_thread_flag(TIF_SINGLESTEP)) {
tracehook_report_syscall_exit(regs, 0);
- else if (tracehook_report_syscall_entry(regs))
- forget_syscall(regs);
+ regs->regs[regno] = saved_reg;
+ } else {
+ regs->regs[regno] = saved_reg;
- regs->regs[regno] = saved_reg;
+ /*
+ * Signal a pseudo-step exception since we are stepping but
+ * tracer modifications to the registers may have rewound the
+ * state machine.
+ */
+ tracehook_report_syscall_exit(regs, 1);
+ }
}
int syscall_trace_enter(struct pt_regs *regs)
@@ -1863,12 +1874,14 @@ int syscall_trace_enter(struct pt_regs *regs)
void syscall_trace_exit(struct pt_regs *regs)
{
+ unsigned long flags = READ_ONCE(current_thread_info()->flags);
+
audit_syscall_exit(regs);
- if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
+ if (flags & _TIF_SYSCALL_TRACEPOINT)
trace_sys_exit(regs, regs_return_value(regs));
- if (test_thread_flag(TIF_SYSCALL_TRACE))
+ if (flags & (_TIF_SYSCALL_TRACE | _TIF_SINGLESTEP))
tracehook_report_syscall(regs, PTRACE_SYSCALL_EXIT);
rseq_syscall(regs);
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 801d56cdf701..3b4f31f35e45 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -800,7 +800,6 @@ static void setup_restart_syscall(struct pt_regs *regs)
*/
static void handle_signal(struct ksignal *ksig, struct pt_regs *regs)
{
- struct task_struct *tsk = current;
sigset_t *oldset = sigmask_to_save();
int usig = ksig->sig;
int ret;
@@ -824,14 +823,8 @@ static void handle_signal(struct ksignal *ksig, struct pt_regs *regs)
*/
ret |= !valid_user_regs(®s->user_regs, current);
- /*
- * Fast forward the stepping logic so we step into the signal
- * handler.
- */
- if (!ret)
- user_fastforward_single_step(tsk);
-
- signal_setup_done(ret, ksig, 0);
+ /* Step into the signal handler if we are stepping */
+ signal_setup_done(ret, ksig, test_thread_flag(TIF_SINGLESTEP));
}
/*
diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
index 5f5b868292f5..7c14466a12af 100644
--- a/arch/arm64/kernel/syscall.c
+++ b/arch/arm64/kernel/syscall.c
@@ -139,7 +139,7 @@ static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
if (!has_syscall_work(flags) && !IS_ENABLED(CONFIG_DEBUG_RSEQ)) {
local_daif_mask();
flags = current_thread_info()->flags;
- if (!has_syscall_work(flags)) {
+ if (!has_syscall_work(flags) && !(flags & _TIF_SINGLESTEP)) {
/*
* We're off to userspace, where interrupts are
* always enabled after we restore the flags from
--
2.27.0.212.ge8ba1cc988-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v2 2/4] arm64: ptrace: Consistently use pseudo-singlestep exceptions
2020-07-02 21:26 ` [PATCH v2 2/4] arm64: ptrace: Consistently use pseudo-singlestep exceptions Will Deacon
@ 2020-07-10 14:02 ` Sasha Levin
0 siblings, 0 replies; 9+ messages in thread
From: Sasha Levin @ 2020-07-10 14:02 UTC (permalink / raw)
To: Sasha Levin, Will Deacon, linux-arm-kernel
Cc: Mark Rutland, kernel-team, Luis Machado, Will Deacon, stable
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.7.7, v5.4.50, v4.19.131, v4.14.187, v4.9.229, v4.4.229.
v5.7.7: Build OK!
v5.4.50: Build OK!
v4.19.131: Build OK!
v4.14.187: Failed to apply! Possible dependencies:
0013aceb30748 ("xtensa: clean up fixups in assembly code")
1af1e8a39dc0f ("xtensa: move fixmap and kmap just above the KSEG")
2a61f4747eeaa ("stack-protector: test compiler capability in Kconfig and drop AUTO mode")
2b8383927525d ("Makefile: move stack-protector compiler breakage test earlier")
2bc2f688fdf88 ("Makefile: move stack-protector availability out of Kconfig")
409d5db49867c ("arm64: rseq: Implement backend rseq calls and select HAVE_RSEQ")
40d1a07b333ef ("xtensa: enable stack protector")
44c6dc940b190 ("Makefile: introduce CONFIG_CC_STACKPROTECTOR_AUTO")
5cf97ebd8b40e ("xtensa: clean up functions in assembly code")
8d66772e869e7 ("arm64: Mask all exceptions during kernel_exit")
9800b9dc13cdf ("arm: Add restartable sequences support")
a92d4d1454ab8 ("arm64: entry.S: move SError handling into a C function for future expansion")
c2edb35ae342f ("xtensa: extract init_kio")
c633544a61541 ("xtensa: add support for KASAN")
d148eac0e70f0 ("Kbuild: rename HAVE_CC_STACKPROTECTOR config variable")
f37099b6992a0 ("arm64: convert syscall trace logic to C")
f4431396be5b2 ("xtensa: consolidate kernel stack size related definitions")
v4.9.229: Failed to apply! Possible dependencies:
096683724cb2e ("arm64: unwind: avoid percpu indirection for irq stack")
12964443e8d19 ("arm64: add on_accessible_stack()")
17c2895860092 ("arm64: Abstract syscallno manipulation")
34be98f4944f9 ("arm64: kernel: remove {THREAD,IRQ_STACK}_START_SP")
35d0e6fb4d219 ("arm64: syscallno is secretly an int, make it official")
8018ba4edfd3a ("arm64: move SEGMENT_ALIGN to <asm/memory.h>")
872d8327ce898 ("arm64: add VMAP_STACK overflow detection")
9842ceae9fa8d ("arm64: Add uprobe support")
a92d4d1454ab8 ("arm64: entry.S: move SError handling into a C function for future expansion")
a9ea0017ebe88 ("arm64: factor out current_stack_pointer")
c02433dd6de32 ("arm64: split thread_info from task stack")
c7365330753c5 ("arm64: unwind: disregard frame.sp when validating frame pointer")
cf7de27ab3517 ("arm64/syscalls: Check address limit on user-mode return")
dbc9344a68e50 ("arm64: clean up THREAD_* definitions")
f37099b6992a0 ("arm64: convert syscall trace logic to C")
f60ad4edcf072 ("arm64: clean up irq stack definitions")
v4.4.229: Failed to apply! Possible dependencies:
0a28714c53fd4 ("arm64: Use PoU cache instr for I/D coherency")
0a8ea52c3eb15 ("arm64: Add HAVE_REGS_AND_STACK_ACCESS_API feature")
17c2895860092 ("arm64: Abstract syscallno manipulation")
2dd0e8d2d2a15 ("arm64: Kprobes with single stepping support")
35d0e6fb4d219 ("arm64: syscallno is secretly an int, make it official")
39a67d49ba353 ("arm64: kprobes instruction simulation support")
421dd6fa6709e ("arm64: factor work_pending state machine to C")
57f4959bad0a1 ("arm64: kernel: Add support for User Access Override")
872d8327ce898 ("arm64: add VMAP_STACK overflow detection")
9842ceae9fa8d ("arm64: Add uprobe support")
a92d4d1454ab8 ("arm64: entry.S: move SError handling into a C function for future expansion")
b11e5759bfac0 ("arm64: factor out entry stack manipulation")
cf7de27ab3517 ("arm64/syscalls: Check address limit on user-mode return")
d5370f7548754 ("arm64: prefetch: add alternative pattern for CPUs without a prefetcher")
d59bee8872311 ("arm64: Add more test functions to insn.c")
e04a28d45ff34 ("arm64: debug: re-enable irqs before sending breakpoint SIGTRAP")
f37099b6992a0 ("arm64: convert syscall trace logic to C")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v2 3/4] arm64: Override SPSR.SS when single-stepping is enabled
2020-07-02 21:26 [PATCH v2 0/4] arm64: Fix single-step handling Will Deacon
2020-07-02 21:26 ` [PATCH v2 1/4] arm64: ptrace: Add a comment describing our syscall entry/exit trap ABI Will Deacon
2020-07-02 21:26 ` [PATCH v2 2/4] arm64: ptrace: Consistently use pseudo-singlestep exceptions Will Deacon
@ 2020-07-02 21:26 ` Will Deacon
2020-07-10 14:02 ` Sasha Levin
2020-07-02 21:26 ` [PATCH v2 4/4] arm64: Use test_tsk_thread_flag() for checking TIF_SINGLESTEP Will Deacon
2020-07-03 10:52 ` [PATCH v2 0/4] arm64: Fix single-step handling Luis Machado
4 siblings, 1 reply; 9+ messages in thread
From: Will Deacon @ 2020-07-02 21:26 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, Luis Machado, Will Deacon, stable, Keno Fischer,
kernel-team
Luis reports that, when reverse debugging with GDB, single-step does not
function as expected on arm64:
| I've noticed, under very specific conditions, that a PTRACE_SINGLESTEP
| request by GDB won't execute the underlying instruction. As a consequence,
| the PC doesn't move, but we return a SIGTRAP just like we would for a
| regular successful PTRACE_SINGLESTEP request.
The underlying problem is that when the CPU register state is restored
as part of a reverse step, the SPSR.SS bit is cleared and so the hardware
single-step state can transition to the "active-pending" state, causing
an unexpected step exception to be taken immediately if a step operation
is attempted.
In hindsight, we probably shouldn't have exposed SPSR.SS in the pstate
accessible by the GPR regset, but it's a bit late for that now. Instead,
simply prevent userspace from configuring the bit to a value which is
inconsistent with the TIF_SINGLESTEP state for the task being traced.
Cc: <stable@vger.kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Keno Fischer <keno@juliacomputing.com>
Link: https://lore.kernel.org/r/1eed6d69-d53d-9657-1fc9-c089be07f98c@linaro.org
Reported-by: Luis Machado <luis.machado@linaro.org>
Tested-by: Luis Machado <luis.machado@linaro.org>
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/include/asm/debug-monitors.h | 2 ++
arch/arm64/kernel/debug-monitors.c | 20 ++++++++++++++++----
arch/arm64/kernel/ptrace.c | 4 ++--
3 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/include/asm/debug-monitors.h b/arch/arm64/include/asm/debug-monitors.h
index e5ceea213e39..0b298f48f5bf 100644
--- a/arch/arm64/include/asm/debug-monitors.h
+++ b/arch/arm64/include/asm/debug-monitors.h
@@ -109,6 +109,8 @@ void disable_debug_monitors(enum dbg_active_el el);
void user_rewind_single_step(struct task_struct *task);
void user_fastforward_single_step(struct task_struct *task);
+void user_regs_reset_single_step(struct user_pt_regs *regs,
+ struct task_struct *task);
void kernel_enable_single_step(struct pt_regs *regs);
void kernel_disable_single_step(void);
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index 5df49366e9ab..91146c0a3691 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -141,17 +141,20 @@ postcore_initcall(debug_monitors_init);
/*
* Single step API and exception handling.
*/
-static void set_regs_spsr_ss(struct pt_regs *regs)
+static void set_user_regs_spsr_ss(struct user_pt_regs *regs)
{
regs->pstate |= DBG_SPSR_SS;
}
-NOKPROBE_SYMBOL(set_regs_spsr_ss);
+NOKPROBE_SYMBOL(set_user_regs_spsr_ss);
-static void clear_regs_spsr_ss(struct pt_regs *regs)
+static void clear_user_regs_spsr_ss(struct user_pt_regs *regs)
{
regs->pstate &= ~DBG_SPSR_SS;
}
-NOKPROBE_SYMBOL(clear_regs_spsr_ss);
+NOKPROBE_SYMBOL(clear_user_regs_spsr_ss);
+
+#define set_regs_spsr_ss(r) set_user_regs_spsr_ss(&(r)->user_regs)
+#define clear_regs_spsr_ss(r) clear_user_regs_spsr_ss(&(r)->user_regs)
static DEFINE_SPINLOCK(debug_hook_lock);
static LIST_HEAD(user_step_hook);
@@ -402,6 +405,15 @@ void user_fastforward_single_step(struct task_struct *task)
clear_regs_spsr_ss(task_pt_regs(task));
}
+void user_regs_reset_single_step(struct user_pt_regs *regs,
+ struct task_struct *task)
+{
+ if (test_tsk_thread_flag(task, TIF_SINGLESTEP))
+ set_user_regs_spsr_ss(regs);
+ else
+ clear_user_regs_spsr_ss(regs);
+}
+
/* Kernel API */
void kernel_enable_single_step(struct pt_regs *regs)
{
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 7b46caea1278..89fbee3991a2 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1959,8 +1959,8 @@ static int valid_native_regs(struct user_pt_regs *regs)
*/
int valid_user_regs(struct user_pt_regs *regs, struct task_struct *task)
{
- if (!test_tsk_thread_flag(task, TIF_SINGLESTEP))
- regs->pstate &= ~DBG_SPSR_SS;
+ /* https://lore.kernel.org/lkml/20191118131525.GA4180@willie-the-truck */
+ user_regs_reset_single_step(regs, task);
if (is_compat_thread(task_thread_info(task)))
return valid_compat_regs(regs);
--
2.27.0.212.ge8ba1cc988-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v2 3/4] arm64: Override SPSR.SS when single-stepping is enabled
2020-07-02 21:26 ` [PATCH v2 3/4] arm64: Override SPSR.SS when single-stepping is enabled Will Deacon
@ 2020-07-10 14:02 ` Sasha Levin
0 siblings, 0 replies; 9+ messages in thread
From: Sasha Levin @ 2020-07-10 14:02 UTC (permalink / raw)
To: Sasha Levin, Will Deacon, linux-arm-kernel
Cc: Mark Rutland, kernel-team, Keno Fischer, Will Deacon, stable
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.7.7, v5.4.50, v4.19.131, v4.14.187, v4.9.229, v4.4.229.
v5.7.7: Build OK!
v5.4.50: Build OK!
v4.19.131: Build OK!
v4.14.187: Build OK!
v4.9.229: Build OK!
v4.4.229: Failed to apply! Possible dependencies:
44b53f67c99d0 ("arm64: Blacklist non-kprobe-able symbol")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks
Sasha
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v2 4/4] arm64: Use test_tsk_thread_flag() for checking TIF_SINGLESTEP
2020-07-02 21:26 [PATCH v2 0/4] arm64: Fix single-step handling Will Deacon
` (2 preceding siblings ...)
2020-07-02 21:26 ` [PATCH v2 3/4] arm64: Override SPSR.SS when single-stepping is enabled Will Deacon
@ 2020-07-02 21:26 ` Will Deacon
2020-07-03 10:52 ` [PATCH v2 0/4] arm64: Fix single-step handling Luis Machado
4 siblings, 0 replies; 9+ messages in thread
From: Will Deacon @ 2020-07-02 21:26 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Mark Rutland, kernel-team, Luis Machado, Will Deacon, Keno Fischer
Rather than open-code test_tsk_thread_flag() at each callsite, simply
replace the couple of offenders with calls to test_tsk_thread_flag()
directly.
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/kernel/debug-monitors.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/debug-monitors.c b/arch/arm64/kernel/debug-monitors.c
index 91146c0a3691..7310a4f7f993 100644
--- a/arch/arm64/kernel/debug-monitors.c
+++ b/arch/arm64/kernel/debug-monitors.c
@@ -394,14 +394,14 @@ void user_rewind_single_step(struct task_struct *task)
* If single step is active for this thread, then set SPSR.SS
* to 1 to avoid returning to the active-pending state.
*/
- if (test_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP))
+ if (test_tsk_thread_flag(task, TIF_SINGLESTEP))
set_regs_spsr_ss(task_pt_regs(task));
}
NOKPROBE_SYMBOL(user_rewind_single_step);
void user_fastforward_single_step(struct task_struct *task)
{
- if (test_ti_thread_flag(task_thread_info(task), TIF_SINGLESTEP))
+ if (test_tsk_thread_flag(task, TIF_SINGLESTEP))
clear_regs_spsr_ss(task_pt_regs(task));
}
--
2.27.0.212.ge8ba1cc988-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related [flat|nested] 9+ messages in thread* Re: [PATCH v2 0/4] arm64: Fix single-step handling
2020-07-02 21:26 [PATCH v2 0/4] arm64: Fix single-step handling Will Deacon
` (3 preceding siblings ...)
2020-07-02 21:26 ` [PATCH v2 4/4] arm64: Use test_tsk_thread_flag() for checking TIF_SINGLESTEP Will Deacon
@ 2020-07-03 10:52 ` Luis Machado
2020-07-03 11:49 ` Will Deacon
4 siblings, 1 reply; 9+ messages in thread
From: Luis Machado @ 2020-07-03 10:52 UTC (permalink / raw)
To: Will Deacon, linux-arm-kernel; +Cc: Mark Rutland, Keno Fischer, kernel-team
Hi Will,
On 7/2/20 6:26 PM, Will Deacon wrote:
> Hi all,
>
> This is version two of the patches I previously posted here:
>
> v1: https://lore.kernel.org/linux-arm-kernel/20200603151033.11512-1-will@kernel.org/
>
> Thanks to Keno for a bunch of helpful feedback on that, which has led to
> the following major changes for v2:
>
> - Use pseudo-step traps for both entering a signal handler and exiting a
> system call.
>
> - Document our weird x7 behaviour with PTRACE_SYSCALL.
>
> It has to be said that I'm a bit nervous about these changes. I played
> around with GDB and things seemed ok, but I would really appreciate it
> if Luis could run the GDB testsuite with these changes applied.
Thanks for working on this. I'll need some time to give this a go. I'll
let you know what the results are.
Do I only need to exercise the AArch64 state? Or would this impact
AArch32 as well?
Regards,
Luis
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v2 0/4] arm64: Fix single-step handling
2020-07-03 10:52 ` [PATCH v2 0/4] arm64: Fix single-step handling Luis Machado
@ 2020-07-03 11:49 ` Will Deacon
0 siblings, 0 replies; 9+ messages in thread
From: Will Deacon @ 2020-07-03 11:49 UTC (permalink / raw)
To: Luis Machado; +Cc: Mark Rutland, Keno Fischer, kernel-team, linux-arm-kernel
Hi Luis,
On Fri, Jul 03, 2020 at 07:52:34AM -0300, Luis Machado wrote:
> On 7/2/20 6:26 PM, Will Deacon wrote:
> > This is version two of the patches I previously posted here:
> >
> > v1: https://lore.kernel.org/linux-arm-kernel/20200603151033.11512-1-will@kernel.org/
> >
> > Thanks to Keno for a bunch of helpful feedback on that, which has led to
> > the following major changes for v2:
> >
> > - Use pseudo-step traps for both entering a signal handler and exiting a
> > system call.
> >
> > - Document our weird x7 behaviour with PTRACE_SYSCALL.
> >
> > It has to be said that I'm a bit nervous about these changes. I played
> > around with GDB and things seemed ok, but I would really appreciate it
> > if Luis could run the GDB testsuite with these changes applied.
>
> Thanks for working on this. I'll need some time to give this a go. I'll let
> you know what the results are.
Brilliant, thank you.
> Do I only need to exercise the AArch64 state? Or would this impact AArch32
> as well?
I doubt AArch32 userspace goes very near PTRACE_SINGLESTEP, as it's not
supported by arch/arm/, so AArch64 testing should be sufficient.
Cheers,
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 9+ messages in thread