All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leon Hwang <leon.hwang@linux.dev>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	John Fastabend <john.fastabend@gmail.com>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Eduard Zingerman <eddyz87@gmail.com>, Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@fomichev.me>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>, Shuah Khan <shuah@kernel.org>,
	Christian Brauner <brauner@kernel.org>,
	Seth Forshee <sforshee@kernel.org>,
	Yuichiro Tsuji <yuichtsu@amazon.com>,
	Andrey Albershteyn <aalbersh@redhat.com>,
	Willem de Bruijn <willemb@google.com>,
	Jason Xing <kerneljasonxing@gmail.com>,
	Tao Chen <chen.dylane@linux.dev>,
	Mykyta Yatsenko <yatsenko@meta.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Anton Protopopov <a.s.protopopov@gmail.com>,
	Amery Hung <ameryhung@gmail.com>, Rong Tao <rongtao@cestc.cn>,
	linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
	linux-kselftest@vger.kernel.org, kernel-patches-bot@fb.com
Subject: Re: [RESEND PATCH bpf-next v6 2/9] libbpf: Add support for extended bpf syscall
Date: Fri, 23 Jan 2026 09:41:38 +0800	[thread overview]
Message-ID: <d8f37588-2b7d-447a-ae4f-dc81e1b573c5@linux.dev> (raw)
In-Reply-To: <CAEf4BzYuZsFC-DPhhzLcyFTahucHP59+6kAc0sooY2g+SqgrEA@mail.gmail.com>



On 23/1/26 08:53, Andrii Nakryiko wrote:
> On Tue, Jan 20, 2026 at 7:26 AM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
>> To support the extended BPF syscall introduced in the previous commit,
>> introduce the following internal APIs:
>>
>> * 'sys_bpf_ext()'
>> * 'sys_bpf_ext_fd()'
>>   They wrap the raw 'syscall()' interface to support passing extended
>>   attributes.
>> * 'probe_sys_bpf_ext()'
>>   Check whether current kernel supports the BPF syscall common attributes.
>>
>> Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
>> ---
>>  tools/lib/bpf/bpf.c             | 32 ++++++++++++++++++++++++++++++++
>>  tools/lib/bpf/features.c        |  8 ++++++++
>>  tools/lib/bpf/libbpf_internal.h |  3 +++
>>  3 files changed, 43 insertions(+)
>>
>> diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
>> index 21b57a629916..ed9c6eaeb656 100644
>> --- a/tools/lib/bpf/bpf.c
>> +++ b/tools/lib/bpf/bpf.c
>> @@ -69,6 +69,38 @@ static inline __u64 ptr_to_u64(const void *ptr)
>>         return (__u64) (unsigned long) ptr;
>>  }
>>
>> +static inline int sys_bpf_ext(enum bpf_cmd cmd, union bpf_attr *attr,
>> +                             unsigned int size,
>> +                             struct bpf_common_attr *attr_common,
>> +                             unsigned int size_common)
>> +{
>> +       cmd = attr_common ? (cmd | BPF_COMMON_ATTRS) : (cmd & ~BPF_COMMON_ATTRS);
>> +       return syscall(__NR_bpf, cmd, attr, size, attr_common, size_common);
>> +}
>> +
>> +static inline int sys_bpf_ext_fd(enum bpf_cmd cmd, union bpf_attr *attr,
>> +                                unsigned int size,
>> +                                struct bpf_common_attr *attr_common,
>> +                                unsigned int size_common)
>> +{
>> +       int fd;
>> +
>> +       fd = sys_bpf_ext(cmd, attr, size, attr_common, size_common);
>> +       return ensure_good_fd(fd);
>> +}
>> +
>> +int probe_sys_bpf_ext(void)
>> +{
>> +       const size_t attr_sz = offsetofend(union bpf_attr, prog_token_fd);
>> +       union bpf_attr attr;
>> +
>> +       memset(&attr, 0, attr_sz);
>> +       /* This syscall() will return error always. */
> 
> I'll cite myself from the last review:
> 
>> But fd should really not be >= 0, and if it is -- it's some problem,
>> so I'd return an error in that case to keep us aware, which is why I'm
>> saying I'd just return inside if (fd >= 0) { }
> 
> I didn't say let's just ignore syscall return with (void) cast and
> happily check errno no matter what, did I? Drop the comment, and
> handle fd >= 0 case explicitly, please.
> 

My mistake — sorry for the misunderstanding.

You’re right; the return value should not be ignored. In the next
revision, I’ll handle the fd >= 0 case explicitly and drop the comment.
The logic will be updated along the lines of:

fd = syscall(__NR_bpf, BPF_PROG_LOAD | BPF_COMMON_ATTRS,
             &attr, attr_sz, NULL, sizeof(struct bpf_common_attr));
if (fd >= 0) {
        close(fd);
        return 0;
}
return errno == EFAULT;

Thanks,
Leon



  reply	other threads:[~2026-01-23  1:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-20 15:24 [RESEND PATCH bpf-next v6 0/9] bpf: Extend BPF syscall with common attributes support Leon Hwang
2026-01-20 15:24 ` [RESEND PATCH bpf-next v6 1/9] " Leon Hwang
2026-01-20 15:24 ` [RESEND PATCH bpf-next v6 2/9] libbpf: Add support for extended bpf syscall Leon Hwang
2026-01-23  0:53   ` Andrii Nakryiko
2026-01-23  1:41     ` Leon Hwang [this message]
2026-01-23 18:54       ` Andrii Nakryiko
2026-01-20 15:24 ` [RESEND PATCH bpf-next v6 3/9] bpf: Refactor reporting log_true_size for prog_load Leon Hwang
2026-01-20 15:24 ` [RESEND PATCH bpf-next v6 4/9] bpf: Add syscall common attributes support " Leon Hwang
2026-01-20 15:24 ` [RESEND PATCH bpf-next v6 5/9] bpf: Refactor reporting btf_log_true_size for btf_load Leon Hwang
2026-01-20 15:24 ` [RESEND PATCH bpf-next v6 6/9] bpf: Add syscall common attributes support " Leon Hwang
2026-01-20 15:24 ` [RESEND PATCH bpf-next v6 7/9] bpf: Add syscall common attributes support for map_create Leon Hwang
2026-01-20 15:24 ` [RESEND PATCH bpf-next v6 8/9] libbpf: Add common attr " Leon Hwang
2026-01-20 15:24 ` [RESEND PATCH bpf-next v6 9/9] selftests/bpf: Add tests to verify map create failure log Leon Hwang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d8f37588-2b7d-447a-ae4f-dc81e1b573c5@linux.dev \
    --to=leon.hwang@linux.dev \
    --cc=a.s.protopopov@gmail.com \
    --cc=aalbersh@redhat.com \
    --cc=ameryhung@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=chen.dylane@linux.dev \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kernel-patches-bot@fb.com \
    --cc=kerneljasonxing@gmail.com \
    --cc=kpsingh@kernel.org \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=memxor@gmail.com \
    --cc=rongtao@cestc.cn \
    --cc=sdf@fomichev.me \
    --cc=sforshee@kernel.org \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=willemb@google.com \
    --cc=yatsenko@meta.com \
    --cc=yonghong.song@linux.dev \
    --cc=yuichtsu@amazon.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.