Re: [PATCH v1] arm64: poe: fix stale POR_EL0 values for ptrace
From: Mark Rutland <mark.rutland@arm.com>
Date: 2026-01-21 15:37:09
Also in:
linux-arm-kernel
On Wed, Jan 21, 2026 at 03:59:22PM +0100, Kevin Brodsky wrote:
On 21/01/2026 14:56, Joey Gouly wrote:quoted
If a process wrote to POR_EL0 and then crashed before a context switch happened, the coredump would contain an incorrect value for POR_EL0.Isn't that also a problem if using ptrace(PTRACE_GETREGSET, REGSET_POE)?
In the case of manipulating a tracee (i.e. target != current), the core code ensures that the tracee is stopped (has context-switched out, an hence has saved its registrer contents to memory) before the relevant regset functions can be called.
Just like for fpsimd, etc.
Just FYI, The FPSIMD/SVE/SME registers are a special case relative to all the other regsets. The FPSIMD/SVE/SME registers eagerly saved to memory (and so when a task is scheduled out, the value in memory will be up-to-date), but they're lazily restored (so the value in registers can be transiently stale while the task is running), and there's a special case when scheduling a task in where we attempt to spot if the CPU registers happen to be up-to-date with the task. The gist of this is that when manipulating the FPSIMD/SVE/SME regsets of a task: * For reads, we know that the value in memory is up-to-date unless the task is the current task. * For writes (which can only occur for a tracee which is not the current task), we need to update some tracking data to prevent context-switch from reusing stale values on a CPU. That's what fpsimd_flush_task_state() does. Pretty much all other regsets don't need the "flush" on writes, since the value in memory will be loaded when the task is next scheduled in. Mark.