On Tue, Jan 30, 2024 at 11:51:07AM +0000, Will Deacon wrote:
On Fri, Jan 19, 2024 at 12:29:13PM +0000, Mark Brown wrote:
- if (test_thread_flag(TIF_SVE))
- if (current->thread.fp_type == FP_STATE_SVE) sve_to_fpsimd(current);
}
I don't think this hunk applies on -rc2 ^^.
Hrm, git seemed to figure out a rebase with no intervention - I've thrown it at my CI and will resend assuming no changes from the rest of the discussion.
if (add_all || test_thread_flag(TIF_SVE) ||
thread_sm_enabled(¤t->thread)) { int vl = max(sve_max_vl(), sme_max_vl());if (add_all || current->thread.fp_type == FP_STATE_SVE ||
I think this code is preemptible, so I'm struggling to understand what happens if the fp_type changes under our feet as a result of a context switch.
We are relying here on having forced a flush of the floating point register state prior to this code running, simple preemption won't change the state from what was already saved. The same consideration also applies to the check for streaming mode here.
That said if this is preempted ptrace *could* come in and rewrite the data or at worst change the vector length (which could leave us with sve_state deallocated or a different size, possibly while we're in the middle of accessing it). This could also happen with the existing check for TIF_SVE so I don't think there's anything new here - AFAICT this has always been an issue with the vector code, unless I'm missing some bigger thing which excludes ptrace. I think any change that's needed there won't overlap with this one, I'm looking.