Re: [PATCH bpf-next v4 2/4] bpf: Improve error reporting for freplace attachment failure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 25, 2025 at 9:19 AM Andrii Nakryiko
<andrii.nakryiko@xxxxxxxxx> wrote:
>
> > But, how can we achieve it?
>
> There is no *elegant* way to do this, but I think we could retrofit
> this as extra common bpf_attrs into existing bpf() syscall. Something
> along the lines of:
>
> struct bpf_common_attr {
>     __u64 log_buf;
>     __u32 log_size;

other than missing log_level I like this approach.

> }
>
> #define BPF_COMMON_ATTRS 0x80000000

negative enum/int is a bit meh, can we use 64 instead?
In token we have:
BUILD_BUG_ON(__MAX_BPF_CMD >= 64);
and delegate_cmds mount option too.

Currently __MAX_BPF_CMD = 37
so we have some room.
BPF_COMMON_ATTRS (1 << 16) is fine too.
Just not the sign bit.

>
> static int __sys_bpf(enum bpf_cmd cmd, bpfptr_t uattr, unsigned int
> size, bpfptr_t uattr_common, unsigned int size_common)
> {
>     if (cmd & BPF_COMMON_ATTRS) {
>         cmd &= ~BPF_COMMON_ATTRS;
>         /* read out bpf_common_attr from uattr_common */
>     }
> }
>
>
> i.e., we add two extra arguments to bpf() syscall, but only look at
> them if we have an extra flag set in cmd.
>
> >
> > Thanks,
> > Leon
> >





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux