Re: [RFC PATCH bpf-next 3/5] bpf: Report freplace attach failure reason via extended syscall

[Leon Hwang <leon.hwang@linux.dev>]

On 2025/8/1 00:32, Alexei Starovoitov wrote:
> On Mon, Jul 28, 2025 at 7:24 AM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
>> This patch enables detailed error reporting when a freplace program fails
>> to attach to its target.
>>
>> By leveraging the extended 'bpf()' syscall with common attributes, users
>> can now retrieve the failure reason through the provided log buffer.
>>
>> Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
>> ---
>>  kernel/bpf/syscall.c | 39 +++++++++++++++++++++++++++++++--------
>>  1 file changed, 31 insertions(+), 8 deletions(-)
>>
>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>> index ca7ce8474812..4d1f58b14a0a 100644
>> --- a/kernel/bpf/syscall.c
>> +++ b/kernel/bpf/syscall.c
>> @@ -3446,7 +3446,8 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog,
>>                                    int tgt_prog_fd,
>>                                    u32 btf_id,
>>                                    u64 bpf_cookie,
>> -                                  enum bpf_attach_type attach_type)
>> +                                  enum bpf_attach_type attach_type,
>> +                                  struct bpf_verifier_log *log)
> 
> Same issue as before.
> Nack on adding new uapi for the sole purpose of freplace.
> 

Got it.

> Patches 1 and 2 are fine, but must follow with patch(es) that
> make common_attrs usable for existing commands like prog_load and btf_load.
> We need to decide what to do when prog_load's log_buf conflicts
> with common_attrs.log_buf.
> I think it's ok if they both specified and are exactly the same.
> If one of them is specified and another is zero it's also ok.
> When they conflict it's an EINVAL or, maybe, EUSERS to make it distinct.
> After that map_create cmd should adopt log and disambiguate all EINVAL-s
> into human readable messages.

Let me have a try.

Thanks,
Leon