mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Leon Hwang <leon.hwang@linux.dev>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: bpf@vger.kernel.org, Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@kernel.org>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Simon Horman <horms@kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Martin KaFai Lau <martin.lau@linux.dev>,
	Song Liu <song@kernel.org>,
	Yonghong Song <yonghong.song@linux.dev>,
	Jiri Olsa <jolsa@kernel.org>,
	Emil Tsalapatis <emil@etsalapatis.com>,
	Ihor Solodrai <ihor.solodrai@linux.dev>,
	Jesper Dangaard Brouer <hawk@kernel.org>,
	John Fastabend <john.fastabend@gmail.com>,
	Stanislav Fomichev <sdf@fomichev.me>,
	Steven Rostedt <rostedt@goodmis.org>,
	Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	Shuah Khan <shuah@kernel.org>,
	Kuniyuki Iwashima <kuniyu@google.com>,
	Hangbin Liu <liuhangbin@gmail.com>,
	Martin Karsten <mkarsten@uwaterloo.ca>,
	Masashi Honma <masashi.honma@gmail.com>,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	linux-trace-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 5/6] libbpf: Add bpf_link_create_log API
Date: Wed, 21 Oct 2026 23:26:53 +0800	[thread overview]
Message-ID: <d4fc4fcd-3691-4122-8b3e-a75447956255@linux.dev> (raw)
In-Reply-To: <CAEf4Bzbr46UkiE1sbb+Zwcs0S1ejpKmtTGjNCAkWD-J6FRcPGQ@mail.gmail.com>

On 2026/10/21 07:25, Andrii Nakryiko wrote:
> On Mon, Oct 19, 2026 at 8:37 AM Leon Hwang <leon.hwang@linux.dev> wrote:

[...]

>> --- a/tools/lib/bpf/bpf.h
>> +++ b/tools/lib/bpf/bpf.h
>> @@ -484,6 +484,11 @@ LIBBPF_API int bpf_link_create(int prog_fd, int target_fd,
>>                                enum bpf_attach_type attach_type,
>>                                const struct bpf_link_create_opts *opts);
>>
>> +LIBBPF_API int bpf_link_create_log(int prog_fd, int target_fd,
>> +                                  enum bpf_attach_type attach_type,
>> +                                  const struct bpf_link_create_opts *opts,
>> +                                  struct bpf_log_opts *log_opts);
> 
> Leon,
> 
> how about instead of adding this new API, we try to repurpose
> bpf_link_create_opts' iter_info to be used as log opts? we have this
> right now:
> 
> union bpf_iter_link_info; /* defined in up-to-date linux/bpf.h */
> struct bpf_link_create_opts {
>         size_t sz; /* size of this struct for forward/backward compatibility */
>         __u32 flags;
>         union bpf_iter_link_info *iter_info;
>         __u32 iter_info_len;
>         __u32 target_btf_id;
>         union {
> 
> 
> that iter_info/iter_info_len is a bit of a legacy before we had
> per-attach type union, what if we add iter section into the union,
> wrap iter_info with union and put log_opts there, mark iter_info
> deprecated or something.
> 
> I'm not sure anyone is actually using iter_info (I didn't find any
> uses in Meta code base, for instance), but we can detect its use by
> checking iter_info_len: if it's non-zero, then iter_info must be a
> real bpf_iter_link_info. so we should be able to detect this just
> fine, the only downside is that you can't use log_opts and iter_info
> simultaneously, but I think that's fine: you can update your code to
> use new iter.info fields instead, if you need log_opts + iter_info.
> 
> WDYT?
> 

IIUC, the struct bpf_link_create_opts will be changed to

struct bpf_link_create_opts {
	size_t sz; /* size of this struct for forward/backward compatibility */
	__u32 flags;
	union {
		union bpf_iter_link_info *iter_info;
		struct bpf_log_opts *log_opts;
	};
	__u32 iter_info_len;
	__u32 target_btf_id;
	union {
		/* ... */
		struct {
			union bpf_iter_link_info *info;
			__u32 len;
		} iter;
	};
};

Thereafter, iter.info is preferred against iter_info. And to keep
backward compatibility, iter_info is used only when iter_info_len is
set. But iter_info_len and iter.len are not allowed to be set at the
same time.

With this change, the bpf_link_create_log API can be dropped.

I'd like to drop the bpf_link_create_log API first, then add iter.info
in the series of log support for iter link_create in the future.

Thanks,
Leon


  reply	other threads:[~2026-10-21 15:27 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-19 15:36 [PATCH bpf-next v2 0/6] bpf: Add syscall common attrs support for xdp link_create Leon Hwang
2026-10-19 15:36 ` [PATCH bpf-next v2 1/6] bpf: Add syscall common attrs support for link_create Leon Hwang
2026-10-19 19:25   ` Alexei Starovoitov
2026-10-20  4:54     ` Leon Hwang
2026-10-19 15:36 ` [PATCH bpf-next v2 2/6] bpf: Add syscall common attrs support for xdp link_create Leon Hwang
2026-10-19 15:36 ` [PATCH bpf-next v2 3/6] bpf: Retire tracepoint bpf_xdp_link_attach_failed Leon Hwang
2026-10-19 15:36 ` [PATCH bpf-next v2 4/6] libbpf: Factor out __sys_bpf_fd helper Leon Hwang
2026-10-19 15:36 ` [PATCH bpf-next v2 5/6] libbpf: Add bpf_link_create_log API Leon Hwang
2026-10-20 23:25   ` Andrii Nakryiko
2026-10-21 15:26     ` Leon Hwang [this message]
2026-10-19 15:36 ` [PATCH bpf-next v2 6/6] selftests/bpf: Add tests to verify link_create logs 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=d4fc4fcd-3691-4122-8b3e-a75447956255@linux.dev \
    --to=leon.hwang@linux.dev \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=eddyz87@gmail.com \
    --cc=edumazet@kernel.org \
    --cc=emil@etsalapatis.com \
    --cc=hawk@kernel.org \
    --cc=horms@kernel.org \
    --cc=ihor.solodrai@linux.dev \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=liuhangbin@gmail.com \
    --cc=martin.lau@linux.dev \
    --cc=masashi.honma@gmail.com \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=memxor@gmail.com \
    --cc=mhiramat@kernel.org \
    --cc=mkarsten@uwaterloo.ca \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=rostedt@goodmis.org \
    --cc=sdf@fomichev.me \
    --cc=shuah@kernel.org \
    --cc=song@kernel.org \
    --cc=yonghong.song@linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®