Re: [PATCH bpf v1 01/10] bpf: Mark signal tracepoint siginfo arguments as scalar

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Thu Sep 3, 2026 at 8:52 AM PDT, bot+bpf-ci wrote:
>> diff --git a/kernel/bpf/btf.c b/kernel/bpf/btf.c
>> index da36d4b9d31ab..d6d243c262ea5 100644
>> --- a/kernel/bpf/btf.c
>> +++ b/kernel/bpf/btf.c
>> @@ -6717,6 +6717,9 @@ static const struct bpf_raw_tp_null_args raw_tp_null_args[] = {
>>  	{ "rxrpc_resend", 0x10 },
>>  	{ "rxrpc_tq", 0x10 },
>>  	{ "rxrpc_client", 0x1 },
>> +	/* signal */
>> +	{ "signal_generate", 0x20 },
>> +	{ "signal_deliver", 0x20 },
>                                    ^^^^
>
> Is signal_deliver's 0x20 mask too strict for its actual call sites?
>
> Looking at the two call sites for trace_signal_deliver():
>
>   kernel/signal.c (do_coredump):
>     trace_signal_deliver(SIGKILL, SEND_SIG_NOINFO,
>                          &sighand->action[SIGKILL-1]);
>
>   kernel/signal.c (get_signal):
>     trace_signal_deliver(signr, &ksig->info, ka);
>
> SEND_SIG_PRIV is never passed to this tracepoint. SEND_SIG_NOINFO is
> zero (NULL), and &ksig->info is always a real pointer filled by
> dequeue_synchronous_signal() or dequeue_signal() just above the call.
>
> SEND_SIG_PRIV == 1 only reaches trace_signal_generate() from
> kernel/signal.c:__send_signal_locked().
>
> If that's the case, would 0x10 (PTR_MAYBE_NULL) be both sufficient and
> less restrictive for signal_deliver? With 0x10 the verifier would still
> force a NULL check to catch SEND_SIG_NOINFO, but after the check a
> tp_btf program could read info->si_code and other fields. With 0x20 the
> register becomes SCALAR_VALUE immediately and check_mem_access() rejects
> all dereferencing with "R1 invalid mem access 'scalar'".

Though AI is correct today the callers of trace_signal_deliver() may change
in the future without cc-ing bpf mailing list and raw_tp_null_args[]
won't be correct anymore. It's better to be strict by default.
Hence, I applied the series as-is.