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: [PATCH bpf-next v9 4/9] bpf: Add syscall common attributes support for prog_load
Date: Fri, 6 Feb 2026 10:45:17 +0800 [thread overview]
Message-ID: <097f4aa3-dfa6-4847-8395-8108323b020f@linux.dev> (raw)
In-Reply-To: <CAEf4BzZWawrE+mXaPNPAT8zcz0Qy+5QYA6r4JzEVw7UAcUH-uA@mail.gmail.com>
On 6/2/26 06:18, Andrii Nakryiko wrote:
> On Wed, Feb 4, 2026 at 7:42 PM Leon Hwang <leon.hwang@linux.dev> wrote:
[...]
>>>> +
>>>> + if (!attr->log_buf && attr_common->log_buf) {
>>>> + attr->log_buf = attr_common->log_buf;
>>>> + attr->log_size = attr_common->log_size;
>>>> + attr->log_level = attr_common->log_level;
>>>
>>> why are we setting this? Do we still have code that can access
>>> attr->log_buf even though we pass attr_log everywhere? If yes, should
>>> we still have that "split brain" code?
>>>
>>
>> 'attr->log_buf' is accessed only in bpf_check().
>
> bpf_check should be changed then, see below
>
>>
>>> If we don't have this assignment, then I think we don't need to have
>>> bpf_prog_load-specific and btf_load-specific log_attr_init() helpers.
>>> They can be unified into generic log_attr_init, where for
>>> bpf_prog_load you'll pass offsetof(log_true_size) +
>>> attr->log_{buf,size,level}, and for btf_load you'll pass different
>>> offset of and btf-specific attr->btf_log*
>>>
>>> This helper will just be making decision whether to use common_attr's
>>> log fields or passed directly command-specific ones.
>>>
>>> Or what am I missing?
>>>
>>
>> If the log attributes differ, where should the effective
>> log_* values be stored?
>>
>> Should they live in struct bpf_common_attr, or should we extend
>> struct bpf_log_attr to carry them?
>>
>> Note that in v8, Alexei suggested struct bpf_log_attr only needs
>> u32 offsetof_true_size;
>> bpfptr_t uattr;
>>
>> so I’d like to clarify the intended direction here. Once that’s clear, a
>> single generic log_attr_init() should be sufficient to handle this.
>>
>
> The intended direction is to have log buf/size/level in one place
> (after attr and common_attr validations), so we keep internal logic
> simple. Let's put all of that and log_true_size **pointer** (we don't
> have to much with offsetof, just calculate user addr for
> log_true_size, which just might be NULL) into bpf_log_attrs and teach
> all code to look and work *only* with that struct, ignoring anything
> log related from attr.
>
It’s clear now.
I’ll follow this direction in the next revision and consolidate all
log-related fields (including the log_true_size pointer) into
bpf_log_attr, so that internal code relies solely on that struct.
Thanks,
Leon
next prev parent reply other threads:[~2026-02-06 2:45 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-02 14:40 [PATCH bpf-next v9 0/9] bpf: Extend BPF syscall with common attributes support Leon Hwang
2026-02-02 14:40 ` [PATCH bpf-next v9 1/9] " Leon Hwang
2026-02-02 14:40 ` [PATCH bpf-next v9 2/9] libbpf: Add support for extended bpf syscall Leon Hwang
2026-02-04 19:48 ` Andrii Nakryiko
2026-02-02 14:40 ` [PATCH bpf-next v9 3/9] bpf: Refactor reporting log_true_size for prog_load Leon Hwang
2026-02-04 19:48 ` Andrii Nakryiko
2026-02-05 2:20 ` Leon Hwang
2026-02-02 14:40 ` [PATCH bpf-next v9 4/9] bpf: Add syscall common attributes support " Leon Hwang
2026-02-04 19:48 ` Andrii Nakryiko
2026-02-05 3:42 ` Leon Hwang
2026-02-05 22:18 ` Andrii Nakryiko
2026-02-06 2:45 ` Leon Hwang [this message]
2026-02-02 14:40 ` [PATCH bpf-next v9 5/9] bpf: Refactor reporting btf_log_true_size for btf_load Leon Hwang
2026-02-02 14:40 ` [PATCH bpf-next v9 6/9] bpf: Add syscall common attributes support " Leon Hwang
2026-02-02 14:40 ` [PATCH bpf-next v9 7/9] bpf: Add syscall common attributes support for map_create Leon Hwang
2026-02-02 14:40 ` [PATCH bpf-next v9 8/9] libbpf: " Leon Hwang
2026-02-04 19:48 ` Andrii Nakryiko
2026-02-05 3:45 ` Leon Hwang
2026-02-02 14:40 ` [PATCH bpf-next v9 9/9] selftests/bpf: Add tests to verify map create failure log Leon Hwang
2026-02-04 20:14 ` Alexei Starovoitov
2026-02-05 3:53 ` Leon Hwang
2026-02-05 23:18 ` Alexei Starovoitov
2026-02-06 2:50 ` 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=097f4aa3-dfa6-4847-8395-8108323b020f@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.