On 3/10/22 7:43 AM, Mark Brown wrote:
Help people figure out problems by printing a diagnostic when we get an
unexpected asynchronous fault.
Signed-off-by: Mark Brown <broonie@xxxxxxxxxx>
---
tools/testing/selftests/arm64/mte/mte_common_util.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/arm64/mte/mte_common_util.c b/tools/testing/selftests/arm64/mte/mte_common_util.c
index 0328a1e08f65..24b0c14203cb 100644
--- a/tools/testing/selftests/arm64/mte/mte_common_util.c
+++ b/tools/testing/selftests/arm64/mte/mte_common_util.c
@@ -37,6 +37,8 @@ void mte_default_handler(int signum, siginfo_t *si, void *uc)
if (si->si_code == SEGV_MTEAERR) {
if (cur_mte_cxt.trig_si_code == si->si_code)
cur_mte_cxt.fault_valid = true;
+ else
+ ksft_print_msg("Got unexpected SEGV_MTEAERR\n");
This is good. Would it make sense to add more info. - I see this in the doc?
Would it make sense to also check si_addr?
- *Asynchronous* - The kernel raises a ``SIGSEGV``, in the offending
thread, asynchronously following one or multiple tag check faults,
with ``.si_code = SEGV_MTEAERR`` and ``.si_addr = 0`` (the faulting
address is unknown).
return;
}
/* Compare the context for precise error */
Looks good to me as such.
Reviewed-by: Shuah Khan <skhan@xxxxxxxxxxxxxxxxxxx>
thanks,
-- Shuah
