Thread (39 messages) flat view 39 messages, 2 authors, 2018-10-01

Re: [RFC PATCH 08/11] powerpc/tm: Do not reclaim on ptrace

From: Michael Neuling <hidden>
Date: 2018-09-18 05:36:56

On Wed, 2018-09-12 at 16:40 -0300, Breno Leitao wrote:
quoted hunk ↗ jump to hunk
Make sure that we are not suspended on ptrace and that the registers were
already reclaimed.
=20
Since the data was already reclaimed, there is nothing to be done here
except to restore the SPRs.
=20
Signed-off-by: Breno Leitao <leitao@debian.org>
---
 arch/powerpc/kernel/ptrace.c | 10 ++++------
 1 file changed, 4 insertions(+), 6 deletions(-)
=20
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 9667666eb18e..cf6ee9154b11 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -136,12 +136,10 @@ static void flush_tmregs_to_thread(struct task_stru=
ct
*tsk)
 	if ((!cpu_has_feature(CPU_FTR_TM)) || (tsk !=3D current))
 		return;
=20
-	if (MSR_TM_SUSPENDED(mfmsr())) {
-		tm_reclaim_current(TM_CAUSE_SIGNAL);
-	} else {
-		tm_enable();
-		tm_save_sprs(&(tsk->thread));
-	}
+	WARN_ON(MSR_TM_SUSPENDED(mfmsr()));
+
+	tm_enable();
+	tm_save_sprs(&(tsk->thread));
Do we need to check if TM was enabled in the task before saving the TM SPRs=
?

What happens if TM was lazily off and hence we had someone else's TM SPRs i=
n the
CPU currently?  Wouldn't this flush the wrong values to the task_struct?

I think we need to check the processes MSR before doing this.

Mikey
 }
 #else
 static inline void flush_tmregs_to_thread(struct task_struct *tsk) { }
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help