Re: [PATCH bpf-next v1 00/14] selftests/bpf: Fixes for userspace ASAN

[Eduard Zingerman <eddyz87@gmail.com>]

On Fri, 2026-02-13 at 08:13 -0800, Ihor Solodrai wrote:

[...]

> So what happens is test_prog's custom signal handler *overwrites* ASAN's
> signal handler leading to the weirdness we are seeing.

That's what I meant by conflict.

> 
> [1] https://stackoverflow.com/questions/17102919/is-it-valid-to-have-multiple-signal-handlers-for-same-signal
> [2] https://man7.org/linux/man-pages/man2/sigaction.2.html
> 
> We should probably do then:
> 
> diff --git a/tools/testing/selftests/bpf/test_progs.c b/tools/testing/selftests/bpf/test_progs.c
> index 02a85dda30e6..77a36f6ca352 100644
> --- a/tools/testing/selftests/bpf/test_progs.c
> +++ b/tools/testing/selftests/bpf/test_progs.c
> @@ -1672,14 +1672,15 @@ static void server_main(void)
>  {
>         pthread_t *dispatcher_threads;
>         struct dispatch_data *data;
> +       int i;
> +
> +#ifndef __SANITIZE_ADDRESS__
>         struct sigaction sigact_int = {
>                 .sa_handler = sigint_handler,
>                 .sa_flags = SA_RESETHAND,
>         };
> -       int i;
> -
>         sigaction(SIGINT, &sigact_int, NULL);
> -
> +#endif
>         dispatcher_threads = calloc(sizeof(pthread_t), env.workers);
>         data = calloc(sizeof(struct dispatch_data), env.workers);

ASAN's stack trace looks nicer compared to what libunwind generates.
On the other hand, test_progs.c:carsh_handler() prints pending test log.
There is an option to remember old handler returned by sigaction and
call it from the crash_handler (thus invoking ASAN's handler),
but the complication is probably not worth it.
I think this part is good as it is, sorry for the noise.

[...]