arm64/ptrace: Don't clear calling process' TIF_SME on OOM
Subsystems (2)
PATCH 1/1 arm64/ptrace: Don't clear calling process' TIF_SME on OOM
If allocating memory for the target SVE state in za_set() fails we clear TIF_SME for the ptracing task which is obviously not correct. If we are here we know that the target task already had neither TIF_SVE nor TIF_SME set since we only need to allocate if either the target had not used either SVE or SME and had no need to allocate state before or we just changed the vector length with vec_set_vector_length() which clears TIF_ for us on allocation failure so just remove the clear entirely.
--- arch/arm64/kernel/ptrace.c | 2 -- 1 file changed, 2 deletions(-)
arch/arm64/kernel/ptrace.c +0 -2
@@ -1084,7 +1084,6 @@ static int za_set(struct task_struct *target,if (!target->thread.sve_state) {sve_alloc (target, false);if (!target->thread.sve_state) { -clear_thread_flag (TIF_SME ); ret = -ENOMEM ; goto out; }
@@ -1094,7 +1093,6 @@ static int za_set(struct task_struct *target,sme_alloc (target);if (!target->thread.za_state) { ret = -ENOMEM ; -clear_tsk_thread_flag (target,TIF_SME ); goto out; }
Signature · 7 lines
2.30.2 _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Will Deacon
maintainerQuoted 8 lines · Mark Brown
If allocating memory for the target SVE state in
za_set()fails we clearTIF_SMEfor the ptracing task which is obviously not correct. If we are here we know that the target task already had neitherTIF_SVEnorTIF_SMEset since we only need to allocate if either the target had not used either SVE or SME and had no need to allocate state before or we just changed the vector length withvec_set_vector_length()which clearsTIF_for us on allocation failure so just remove the clear entirely.
Quoted 5 lines
Reported-by Wang ShaoBo <[email protected]>Signed-off-by Mark Brown <[email protected]>--- arch/arm64/kernel/ptrace.c | 2 -- 1 file changed, 2 deletions(-)
Is this fixing a real (i.e. user-observable) issue, or is it removing some redundant code? I'm afraid I can't tell from the commit message and I'm trying to figure out whether we should be queueing it for -rc (and CC'ing stable) or not.
Thanks,
Will
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 8 lines · Will Deacon
Quoted 2 lines · Mark Brown
If allocating memory for the target SVE state in
za_set()fails we clearTIF_SMEfor the ptracing task which is obviously not correct. If we areIs this fixing a real (i.e. user-observable) issue, or is it removing some redundant code? I'm afraid I can't tell from the commit message and I'm trying to figure out whether we should be queueing it for -rc (and CC'ing stable) or not.
Since we're clearing TIF_SME for the process doing the ptrace there's the potential for causing an issue in that process where we trap a new SME usage and flush the SME state in the process which is a data corruption issue which would be observable.
_______________________________________________
linux-arm-kernel mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Quoted 9 lines · Mark Brown
If allocating memory for the target SVE state in
za_set()fails we clearTIF_SMEfor the ptracing task which is obviously not correct. If we are here we know that the target task already had neitherTIF_SVEnorTIF_SMEset since we only need to allocate if either the target had not used either SVE or SME and had no need to allocate state before or we just changed the vector length withvec_set_vector_length()which clearsTIF_for us on allocation failure so just remove the clear entirely.[...]
Applied to arm64 (for-next/fixes), thanks!
[1/1] arm64/ptrace: Don't clear calling process' TIF_SME on OOM
https://git.kernel.org/arm64/c/d105d6920ec7
Cheers,
Signature · 10 lines
Will https://fixes.arm64.dev https://next.arm64.dev https://will.arm64.dev _______________________________________________ linux-arm-kernel mailing list [email protected] http://lists.infradead.org/mailman/listinfo/linux-arm-kernel