On Thu, Jan 22, 2026 at 8:19 PM Leon Hwang [off-list ref] wrote:

On 23/1/26 12:12, Alexei Starovoitov wrote:

quoted

On Thu, Jan 22, 2026 at 8:07 PM Leon Hwang [off-list ref] wrote:

quoted

On 23/1/26 11:55, Alexei Starovoitov wrote:

quoted

On Thu, Jan 22, 2026 at 7:25 PM Leon Hwang [off-list ref] wrote:

quoted

+static int probe_bpf_syscall_common_attrs(int token_fd)
+{
+       int ret;
+
+       ret = probe_sys_bpf_ext();
+       return ret > 0;
+}

When you look at the above, what thoughts come to mind?

... and please don't use ai for answers.

My initial thought was whether probe_fd() is needed here to handle and
close a returned fd, since the return value of probe_sys_bpf_ext() isn’t
obvious from the call site.

Have you looked at how probes are called (in feat_supported()?) They
all follow the same contract: > 0 (normally just 1) means feature is
supported, 0 means feature is not supported, and <0 means something
went wrong. Libbpf will log an error and will assume feature is not
supported.

probe_sys_bpf_ext() should either follow that convention or drop the
probe_ prefix altogether to avoid confusion. And then
probe_bpf_syscall_common_attrs() is necessary only as a wrapper around
probe_sys_bpf_ext() to ignore mandatory (but unused) token_fd argument
(so to make it "pluggable" into feat_supported() framework).

So, just make probe_sys_bpf_ext() follow probe contract as described,
and then just:

static int probe_bpf_syscall_common_attr(int token_fd)
{
    return probe_sys_bpf_ext();
}

Alternatively, just make probe_sys_bpf_ext() take token_fd (but ignore
it), and just use probe_sys_bpf_ext() directly for feat_supported().


probe_fd() is not suitable here because it's for a common case when we
expect syscall to succeed and create fd, in which case that successful
fd represents successful feature detection. This is not the case here,
so probe_fd() is not what you should use.

quoted

Fair enough, but then collapse it into one helper if FD is a concern.
My question was about stylistic/taste preferences.

Understood, thanks for the clarification.

I’ll rework it with the stylistic preference in mind.

Thanks,
Leon