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

Shuah Khan
2022-03-10T20:04:23Z

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

thanks,
-- Shuah