[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20240115-arm64-fix-ptrace-za-zt-v1-1-48617517028a@kernel.org>
Date: Mon, 15 Jan 2024 18:42:38 +0000
From: Mark Brown <broonie@...nel.org>
To: Oleg Nesterov <oleg@...hat.com>,
Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>
Cc: Dave Martin <dave.martin@....com>, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, Mark Brown <broonie@...nel.org>
Subject: [PATCH] arm64/ptrace: Don't flush ZA/ZT storage when writing ZA
via ptrace
When writing ZA we currently unconditionally flush the buffer used to store
it as part of ensuring that it is allocated. Since this buffer is shared
with ZT0 this means that a write to ZA when PSTATE.ZA is already set will
corrupt the value of ZT0 on a SME2 system. Fix this by only flushing the
backing storage if PSTATE.ZA was not previously set.
This will mean that short or failed writes may leave stale data in the
buffer, this seems as correct as our current behaviour and unlikely to be
something that userspace will rely on.
Fixes: f90b529bcbe5 ("arm64/sme: Implement ZT0 ptrace support")
Signed-off-by: Mark Brown <broonie@...nel.org>
---
arch/arm64/kernel/ptrace.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 20d7ef82de90..b3f64144b5cd 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1107,12 +1107,13 @@ static int za_set(struct task_struct *target,
}
}
- /* Allocate/reinit ZA storage */
- sme_alloc(target, true);
- if (!target->thread.sme_state) {
- ret = -ENOMEM;
- goto out;
- }
+ /*
+ * Only flush the storage if PSTATE.ZA was not already set,
+ * otherwise preserve any existing data.
+ */
+ sme_alloc(target, !thread_za_enabled(&target->thread));
+ if (!target->thread.sme_state)
+ return -ENOMEM;
/* If there is no data then disable ZA */
if (!count) {
---
base-commit: 0dd3ee31125508cd67f7e7172247f05b7fd1753a
change-id: 20240105-arm64-fix-ptrace-za-zt-5f64a61fd612
Best regards,
--
Mark Brown <broonie@...nel.org>
Powered by blists - more mailing lists