On Tue, 10 Sep 2024 17:44:11 -0700 Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > 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). pt_regs things are asked by PeterZ. It is not recommended to use pt_regs if it is not actual pt_regs because user expects it works as full pt_regs. So I and Steve decided to use ftrace_regs for this faked registers. (I think tracepoint should also use ftrace_regs or another one.) Anyway, we're almost at a goal we can all agree on. I think we would better push fprobe on fgraph series instead of such ad-hoc change. Thank you, > > > > > 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> -- Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
