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: [PATCH bpf-next v9 4/9] bpf: Add syscall common attributes support for prog_load
Date: Thu, 5 Feb 2026 11:42:42 +0800	[thread overview]
Message-ID: <a31b7f19-a22a-44ab-8ecd-9df9dead9c3d@linux.dev> (raw)
In-Reply-To: <CAEf4Bza-PM9ExqJS=Q_oj7Cqc5dvmbN_Zv9-4UnJNtsZU28FoQ@mail.gmail.com>



On 5/2/26 03:48, Andrii Nakryiko wrote:
> On Mon, Feb 2, 2026 at 6:42 AM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
>> BPF_PROG_LOAD can now provide log parameters through both union bpf_attr
>> and struct bpf_common_attr. Define clear conflict and precedence rules:
>>
>> - if both are provided and log_buf/log_size/log_level match, use them;
>> - if only one side provides a log buffer, use that one;
>> - if both provide log buffers but differ, return -EINVAL.
>>
>> Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
>> ---
>>  include/linux/bpf_verifier.h |  3 ++-
>>  kernel/bpf/log.c             | 24 ++++++++++++++++++++++--
>>  kernel/bpf/syscall.c         |  3 ++-
>>  3 files changed, 26 insertions(+), 4 deletions(-)
>>
>> diff --git a/include/linux/bpf_verifier.h b/include/linux/bpf_verifier.h
>> index c805b85b6f7a..0d106fddbbc5 100644
>> --- a/include/linux/bpf_verifier.h
>> +++ b/include/linux/bpf_verifier.h
>> @@ -638,7 +638,8 @@ struct bpf_log_attr {
>>  };
>>
>>  int bpf_prog_load_log_attr_init(struct bpf_log_attr *attr_log, union bpf_attr *attr,
>> -                               bpfptr_t uattr, u32 size);
>> +                               bpfptr_t uattr, u32 size, struct bpf_common_attr *attr_common,
>> +                               bpfptr_t uattr_common, u32 size_common);
>>  int bpf_log_attr_finalize(struct bpf_log_attr *attr, struct bpf_verifier_log *log);
>>
>>  #define BPF_MAX_SUBPROGS 256
>> diff --git a/kernel/bpf/log.c b/kernel/bpf/log.c
>> index ff579fcba36f..345005ba98dd 100644
>> --- a/kernel/bpf/log.c
>> +++ b/kernel/bpf/log.c
>> @@ -873,10 +873,30 @@ static void bpf_log_attr_init(struct bpf_log_attr *attr_log, int offsetof_true_s
>>         attr_log->uattr = uattr;
>>  }
>>
>> +static bool bpf_log_attrs_diff(struct bpf_common_attr *common, u64 log_buf, u32 log_size,
>> +                              u32 log_level)
>> +{
>> +       return log_buf && common->log_buf && (log_buf != common->log_buf ||
>> +                                             log_size != common->log_size ||
>> +                                             log_level != common->log_level);
> 
> let's validate (unless we do this somewhere else) that if log_buf is
> set, then log_size and log_level (? not sure, maybe zero is fine) are
> set, or all three are not set. Same for common->log* fields...
> 

Ack.

Will validate 'log_buf && log_size && log_level' first.

> 
>> +}
>> +
>>  int bpf_prog_load_log_attr_init(struct bpf_log_attr *attr_log, union bpf_attr *attr,
>> -                               bpfptr_t uattr, u32 size)
>> +                               bpfptr_t uattr, u32 size, struct bpf_common_attr *attr_common,
>> +                               bpfptr_t uattr_common, u32 size_common)
>>  {
>> -       bpf_log_attr_init(attr_log, offsetof(union bpf_attr, log_true_size), uattr, size);
>> +       if (bpf_log_attrs_diff(attr_common, attr->log_buf, attr->log_size, attr->log_level))
>> +               return -EINVAL;
>> +
>> +       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().

> 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.

Thanks,
Leon

> 
>> +               bpf_log_attr_init(attr_log, offsetof(struct bpf_common_attr, log_true_size),
>> +                                 uattr_common, size_common);
>> +       } else {
>> +               bpf_log_attr_init(attr_log, offsetof(union bpf_attr, log_true_size), uattr, size);
>> +       }
>>         return 0;
>>  }
>>
>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>> index e81199361241..7125ea445c6c 100644
>> --- a/kernel/bpf/syscall.c
>> +++ b/kernel/bpf/syscall.c
>> @@ -6232,7 +6232,8 @@ static int __sys_bpf(enum bpf_cmd cmd, bpfptr_t uattr, unsigned int size,
>>                 err = map_freeze(&attr);
>>                 break;
>>         case BPF_PROG_LOAD:
>> -               err = bpf_prog_load_log_attr_init(&attr_log, &attr, uattr, size);
>> +               err = bpf_prog_load_log_attr_init(&attr_log, &attr, uattr, size, &attr_common,
>> +                                                 uattr_common, size_common);
>>                 err = err ?: bpf_prog_load(&attr, uattr, &attr_log);
>>                 break;
>>         case BPF_OBJ_PIN:
>> --
>> 2.52.0
>>


  reply	other threads:[~2026-02-05  3:43 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 [this message]
2026-02-05 22:18       ` Andrii Nakryiko
2026-02-06  2:45         ` Leon Hwang
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=a31b7f19-a22a-44ab-8ecd-9df9dead9c3d@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.