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@kernel.org
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;
elseksft_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@linuxfoundation.org
thanks, -- Shuah