[PATCH v1 2/4] kselftest/arm64: Log unexpected asynchronous MTE faults

[Shuah Khan]

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 at 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;
> +			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 at linuxfoundation.org>

thanks,
-- Shuah