arm64: fpsimd: Fix failure to restore FPSIMD state after signals

PATCH New Dave Martin 3 participants 6 messages Nov 30, 2017 arm64

Share & tools

Dave Martin

author

2017-11-30 11:56 UTC #0 lore raw

PATCH 1/1 arm64: fpsimd: Fix failure to restore FPSIMD state after signals

The fpsimd_update_current_state() function is responsible for loading the FPSIMD state from the user signal frame into the current task during sigreturn. When implementing support for SVE, conditional code was added to this function in order to handle the case where SVE state need to be loaded for the task and merged with the FPSIMD data from the signal frame; however, the FPSIMD-only case was unintentionally dropped.

As a result of this, sigreturn does not currently restore the FPSIMD state of the task, except in the case where the system supports SVE and the signal frame contains SVE state in addition to FPSIMD state.

This patch fixes this bug by making the copy-in of the FPSIMD data from the signal frame to thread_struct unconditional.

This remains a performance regression from v4.14, since the FPSIMD state is now copied into thread_struct and then loaded back, instead of _only_ being loaded into the CPU FPSIMD registers. However, it is essential to call task_fpsimd_load() here anyway in order to ensure that the SVE enable bit in CPACR_EL1 is set correctly before returning to userspace. This could use some refactoring, but since sigreturn is not a fast path I have kept this patch as a pure fix and left the refactoring for later.

Fixes 8cd969d28fd2 ("arm64/sve: Signal handling support")

Signed-off-by Dave Martin <[email protected]>

Reported-by Alex Benn?e <[email protected]>

Cc Catalin Marinas <[email protected]>

Cc Ard Biesheuvel <[email protected]>

Cc Will Deacon <[email protected]>

---

Initial testing of this patch looks OK, but I will continue to bash it.

While debugging this issue, I also hit another possible register corruption issue that I don't have an explanation for, but I wanted to get this patch out first since this issue at least is fairly straightforward and fixing it is required anyway.

I will continue to investigate.

 arch/arm64/kernel/fpsimd.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

arch/arm64/kernel/fpsimd.c +3 -3

index 143b3e7..5084e69 100644
@@ -1026,10 +1026,10 @@ void fpsimd_update_current_state(struct fpsimd_state *state)
 
 	local_bh_disable();
 
-	if (system_supports_sve() && test_thread_flag(TIF_SVE)) {
-		current->thread.fpsimd_state = *state;
+	current->thread.fpsimd_state = *state;
+	if (system_supports_sve() && test_thread_flag(TIF_SVE))
 		fpsimd_to_sve(current);
-	}
+
 	task_fpsimd_load();
 
 	if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {

Signature · 1 line

2.1.4

Will Deacon

2017-11-30 12:08 UTC #1 lore raw

PATCH 1/1 arm64: fpsimd: Fix failure to restore FPSIMD state after signals

Quoted 50 lines · Dave Martin

The fpsimd_update_current_state() function is responsible for loading the FPSIMD state from the user signal frame into the current task during sigreturn. When implementing support for SVE, conditional code was added to this function in order to handle the case where SVE state need to be loaded for the task and merged with the FPSIMD data from the signal frame; however, the FPSIMD-only case was unintentionally dropped.
As a result of this, sigreturn does not currently restore the FPSIMD state of the task, except in the case where the system supports SVE and the signal frame contains SVE state in addition to FPSIMD state.
This patch fixes this bug by making the copy-in of the FPSIMD data from the signal frame to thread_struct unconditional.
This remains a performance regression from v4.14, since the FPSIMD state is now copied into thread_struct and then loaded back, instead of _only_ being loaded into the CPU FPSIMD registers. However, it is essential to call task_fpsimd_load() here anyway in order to ensure that the SVE enable bit in CPACR_EL1 is set correctly before returning to userspace. This could use some refactoring, but since sigreturn is not a fast path I have kept this patch as a pure fix and left the refactoring for later.
Fixes 8cd969d28fd2 ("arm64/sve: Signal handling support")
Signed-off-by Dave Martin <[email protected]>
Reported-by Alex Benn?e <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Ard Biesheuvel <[email protected]>
Cc Will Deacon <[email protected]>
---
Initial testing of this patch looks OK, but I will continue to bash it.
While debugging this issue, I also hit another possible register corruption issue that I don't have an explanation for, but I wanted to get this patch out first since this issue at least is fairly straightforward and fixing it is required anyway.
I will continue to investigate.
 arch/arm64/kernel/fpsimd.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
arch/arm64/kernel/fpsimd.c +0 -0
index 143b3e7..5084e69 100644

arch/arm64/kernel/fpsimd.c void fpsimd_update_current_state(struct fpsimd_state *state) · line 1032

Quoted 10 lines

arch/arm64/kernel/fpsimd.c +3 -3

@@ -1026,10 +1026,10 @@ void fpsimd_update_current_state(struct fpsimd_state *state)
 
 	local_bh_disable();
 
-	if (system_supports_sve() && test_thread_flag(TIF_SVE)) {
-		current->thread.fpsimd_state = *state;
+	current->thread.fpsimd_state = *state;
+	if (system_supports_sve() && test_thread_flag(TIF_SVE))
 		fpsimd_to_sve(current);
-	}
+

Curious, but does the order in which you set TIF_SVE matter? If not, you could move the TIF_SVE check into fpsimd_to_sve and reorder the flag setting in do_sve_acc so that we don't need to conditionalise all invocations of this.

Will

Dave Martin

author

2017-11-30 12:32 UTC #2 lore raw

PATCH 1/1 arm64: fpsimd: Fix failure to restore FPSIMD state after signals

Quoted 54 lines · Will Deacon

Quoted 53 lines · Dave Martin
The fpsimd_update_current_state() function is responsible for loading the FPSIMD state from the user signal frame into the current task during sigreturn. When implementing support for SVE, conditional code was added to this function in order to handle the case where SVE state need to be loaded for the task and merged with the FPSIMD data from the signal frame; however, the FPSIMD-only case was unintentionally dropped.
As a result of this, sigreturn does not currently restore the FPSIMD state of the task, except in the case where the system supports SVE and the signal frame contains SVE state in addition to FPSIMD state.
This patch fixes this bug by making the copy-in of the FPSIMD data from the signal frame to thread_struct unconditional.
This remains a performance regression from v4.14, since the FPSIMD state is now copied into thread_struct and then loaded back, instead of _only_ being loaded into the CPU FPSIMD registers. However, it is essential to call task_fpsimd_load() here anyway in order to ensure that the SVE enable bit in CPACR_EL1 is set correctly before returning to userspace. This could use some refactoring, but since sigreturn is not a fast path I have kept this patch as a pure fix and left the refactoring for later.
Fixes 8cd969d28fd2 ("arm64/sve: Signal handling support")
Signed-off-by Dave Martin <[email protected]>
Reported-by Alex Benn?e <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Ard Biesheuvel <[email protected]>
Cc Will Deacon <[email protected]>
---
Initial testing of this patch looks OK, but I will continue to bash it.
While debugging this issue, I also hit another possible register corruption issue that I don't have an explanation for, but I wanted to get this patch out first since this issue at least is fairly straightforward and fixing it is required anyway.
I will continue to investigate.
 arch/arm64/kernel/fpsimd.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
arch/arm64/kernel/fpsimd.c +0 -0
index 143b3e7..5084e69 100644
@@ -1026,10 +1026,10 @@ void fpsimd_update_current_state(struct fpsimd_state *state)
 
 	local_bh_disable();
 

Quoted 9 lines

arch/arm64/kernel/fpsimd.c void fpsimd_update_current_state(struct fpsimd_state *state) · line 1032
Quoted 7 lines
arch/arm64/kernel/fpsimd.c +3 -3
-	if (system_supports_sve() && test_thread_flag(TIF_SVE)) {
-		current->thread.fpsimd_state = *state;
+	current->thread.fpsimd_state = *state;
+	if (system_supports_sve() && test_thread_flag(TIF_SVE))
 		fpsimd_to_sve(current);
-	}
+
Curious, but does the order in which you set TIF_SVE matter? If not, you

Historically, yes, but now this flag is protected by local_bh_disable() for running tasks, everywhere execpt in signal.c:restore_sve_fpsimd_context() (see comments in that function for explanation of that case).

(To be more precise, it's not TIF_SVE that's critical directly, but the TIF_FOREIGN_FPSTATE stuff and related logic are bh-critical, and the ordering of TIF_SVE against TIF_FOREIGN_FPSTATE et al. _is_ important. So TIF_SVE is bh-critical-by-proxy as it were.)

Quoted 3 lines

could move the TIF_SVE check into fpsimd_to_sve and reorder the flag setting in do_sve_acc so that we don't need to conditionalise all invocations of this.

This kind of thing will get sucked into future cleanup I want to do. I don't like to tweak this one thing by itself, because there is a wider factoring issue to be looked at: there are many functions today that do SVE-related things unconditionally and leave it to the caller to check whether they should be called or not.

Eventually, I'd like to get rid of much of the local_bh_disable(), in which case the exact ordering of checks would become important again. I remained unsure whether baking these checks in was the correct thing to do -- at the least it may result in duplicate checks on some code paths. For this particular function that's not an issue though.

I can take a look if you feel strongly about it, but it doesn't feel like a priority right now. Attacking it piecemeal is likely to create more problems than it solves IMHO...

Cheers
---Dave

Alex Bennée

2017-11-30 16:27 UTC #3 lore raw

PATCH 1/1 arm64: fpsimd: Fix failure to restore FPSIMD state after signals

In reply to Dave Martin

Quoted 25 lines · Dave Martin

The fpsimd_update_current_state() function is responsible for loading the FPSIMD state from the user signal frame into the current task during sigreturn. When implementing support for SVE, conditional code was added to this function in order to handle the case where SVE state need to be loaded for the task and merged with the FPSIMD data from the signal frame; however, the FPSIMD-only case was unintentionally dropped.
As a result of this, sigreturn does not currently restore the FPSIMD state of the task, except in the case where the system supports SVE and the signal frame contains SVE state in addition to FPSIMD state.
This patch fixes this bug by making the copy-in of the FPSIMD data from the signal frame to thread_struct unconditional.
This remains a performance regression from v4.14, since the FPSIMD state is now copied into thread_struct and then loaded back, instead of _only_ being loaded into the CPU FPSIMD registers. However, it is essential to call task_fpsimd_load() here anyway in order to ensure that the SVE enable bit in CPACR_EL1 is set correctly before returning to userspace. This could use some refactoring, but since sigreturn is not a fast path I have kept this patch as a pure fix and left the refactoring for later.

Quoted 6 lines

Fixes 8cd969d28fd2 ("arm64/sve: Signal handling support")
Signed-off-by Dave Martin <[email protected]>
Reported-by Alex Benn?e <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Ard Biesheuvel <[email protected]>
Cc Will Deacon <[email protected]>

Tested-by Alex Benn?e <[email protected]>

Reviewed-by Alex Benn?e <[email protected]>

Quoted 22 lines

---
Initial testing of this patch looks OK, but I will continue to bash it.
While debugging this issue, I also hit another possible register corruption issue that I don't have an explanation for, but I wanted to get this patch out first since this issue at least is fairly straightforward and fixing it is required anyway.
I will continue to investigate.
 arch/arm64/kernel/fpsimd.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)
arch/arm64/kernel/fpsimd.c +0 -0
index 143b3e7..5084e69 100644
@@ -1026,10 +1026,10 @@ void fpsimd_update_current_state(struct fpsimd_state *state)
 
 	local_bh_disable();
 

arch/arm64/kernel/fpsimd.c void fpsimd_update_current_state(struct fpsimd_state *state) · line 1035

Quoted 10 lines

arch/arm64/kernel/fpsimd.c +3 -3

-	if (system_supports_sve() && test_thread_flag(TIF_SVE)) {
-		current->thread.fpsimd_state = *state;
+	current->thread.fpsimd_state = *state;
+	if (system_supports_sve() && test_thread_flag(TIF_SVE))
 		fpsimd_to_sve(current);
-	}
+
 	task_fpsimd_load();
 
 	if (test_and_clear_thread_flag(TIF_FOREIGN_FPSTATE)) {

--
Alex Benn?e

Dave Martin

author

2017-11-30 16:30 UTC #4 lore raw

PATCH 1/1 arm64: fpsimd: Fix failure to restore FPSIMD state after signals

Quoted 35 lines · Alex Benn?e

Quoted 25 lines · Dave Martin
The fpsimd_update_current_state() function is responsible for loading the FPSIMD state from the user signal frame into the current task during sigreturn. When implementing support for SVE, conditional code was added to this function in order to handle the case where SVE state need to be loaded for the task and merged with the FPSIMD data from the signal frame; however, the FPSIMD-only case was unintentionally dropped.
As a result of this, sigreturn does not currently restore the FPSIMD state of the task, except in the case where the system supports SVE and the signal frame contains SVE state in addition to FPSIMD state.
This patch fixes this bug by making the copy-in of the FPSIMD data from the signal frame to thread_struct unconditional.
This remains a performance regression from v4.14, since the FPSIMD state is now copied into thread_struct and then loaded back, instead of _only_ being loaded into the CPU FPSIMD registers. However, it is essential to call task_fpsimd_load() here anyway in order to ensure that the SVE enable bit in CPACR_EL1 is set correctly before returning to userspace. This could use some refactoring, but since sigreturn is not a fast path I have kept this patch as a pure fix and left the refactoring for later.
Quoted 6 lines
Fixes 8cd969d28fd2 ("arm64/sve: Signal handling support")
Signed-off-by Dave Martin <[email protected]>
Reported-by Alex Benn?e <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Ard Biesheuvel <[email protected]>
Cc Will Deacon <[email protected]>

Quoted 2 lines

Tested-by Alex Benn?e <[email protected]>
Reviewed-by Alex Benn?e <[email protected]>

Awesome, thanks for the quick turn-around.

Will, will you pick with these tags or do you want me to repost?

Cheers
---Dave

Dave Martin

author

2017-11-30 16:29 UTC #5 lore raw

PATCH 1/1 arm64: fpsimd: Fix failure to restore FPSIMD state after signals

In reply to Dave Martin

Quoted 32 lines · Dave Martin

The fpsimd_update_current_state() function is responsible for loading the FPSIMD state from the user signal frame into the current task during sigreturn. When implementing support for SVE, conditional code was added to this function in order to handle the case where SVE state need to be loaded for the task and merged with the FPSIMD data from the signal frame; however, the FPSIMD-only case was unintentionally dropped.
As a result of this, sigreturn does not currently restore the FPSIMD state of the task, except in the case where the system supports SVE and the signal frame contains SVE state in addition to FPSIMD state.
This patch fixes this bug by making the copy-in of the FPSIMD data from the signal frame to thread_struct unconditional.
This remains a performance regression from v4.14, since the FPSIMD state is now copied into thread_struct and then loaded back, instead of _only_ being loaded into the CPU FPSIMD registers. However, it is essential to call task_fpsimd_load() here anyway in order to ensure that the SVE enable bit in CPACR_EL1 is set correctly before returning to userspace. This could use some refactoring, but since sigreturn is not a fast path I have kept this patch as a pure fix and left the refactoring for later.
Fixes 8cd969d28fd2 ("arm64/sve: Signal handling support")
Signed-off-by Dave Martin <[email protected]>
Reported-by Alex Benn?e <[email protected]>
Cc Catalin Marinas <[email protected]>
Cc Ard Biesheuvel <[email protected]>
Cc Will Deacon <[email protected]>
---

[...]

Quoted 6 lines

While debugging this issue, I also hit another possible register corruption issue that I don't have an explanation for, but I wanted to get this patch out first since this issue at least is fairly straightforward and fixing it is required anyway.
I will continue to investigate.

I've now tracked this issue down to a unintended feature in my test, so I believe this patch is sufficient to fix the observed problems (testing still encouraged though).

Cheers
---Dave