On Tue, Sep 10, 2024 at 5:39 PM Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > > On Tue, 10 Sep 2024 13:29:57 -0700 > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > You are probably talking about [0]. But I was asking about [1], i.e., > > adding HAVE_RETHOOK support to ARM64. Despite all your emotions above, > > can I still get a meaningful answer as for why that wasn't landed and > > what prevents it from landing right now before Masami's 20-patch > > series lands? > > As I replied to your last email, Mark discovered that [1] is incorrect. > From the bpf perspective, it may be fine that struct pt_regs is missing > some architecture-specific registers, but from an API perspective, > it is a problem. > > Actually kretprobes on arm64 still does not do it correctly, but I also > know most of users does not care. So currently I keep it as it is. But > after fixing this issue on fprobe. I would like to update kretprobe so > that it will use sw-breakpoint to handle it. It will increase the overhead > of kretprobe, but it should be replaced by fprobe at that moment. Ok, given kretprobes already have this issue, can we add this support for BPF multi-kprobe/kretprobe only? We can have an extra Kconfig option or whatever necessary. It's sad that we don't have entire feature just because a few registers can't be set (and I bet no BPF users ever reads those registers from pt_regs). It's not the first, nor last case where pt_regs isn't complete (e.g., tracepoints set only a few fields in pt_regs, the rest are zero; and that's fine). > > Thank you, > > > > > [0] https://lore.kernel.org/linux-trace-kernel/172398527264.293426.2050093948411376857.stgit@devnote2/ > > [1] https://lore.kernel.org/bpf/164338038439.2429999.17564843625400931820.stgit@devnote2/ > > > > > > > > Again, just letting you know. > > > > > > -- Steve > > > -- > Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
