On 2025/8/1 00:32, Alexei Starovoitov wrote: > On Mon, Jul 28, 2025 at 7:24 AM Leon Hwang <leon.hwang@xxxxxxxxx> 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@xxxxxxxxx> >> --- >> 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
