Thread (23 messages) 23 messages, 3 authors, 2026-02-06

Re: [PATCH bpf-next v9 4/9] bpf: Add syscall common attributes support for prog_load

From: Leon Hwang <hidden>
Date: 2026-02-06 02:45:42
Also in: bpf, linux-kselftest, lkml


On 6/2/26 06:18, Andrii Nakryiko wrote:
On Wed, Feb 4, 2026 at 7:42 PM Leon Hwang [off-list ref] wrote:
[...]
quoted
quoted
quoted
+
+       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
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help