On Wed, Sep 11, 2024 at 4:53 PM Masami Hiramatsu <mhiramat@xxxxxxxxxx> wrote: > > On Wed, 11 Sep 2024 13:18:12 -0700 > Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > > > > So while I get the desire to have a clean and nice > > > > end goal, and that it might take a bit longer to get everything right. > > > > But, maybe, landing a stop-gap solution meanwhile (especially as > > > > isolated and thus easily backportable as the patch [0] you referenced) > > > > is an OK path forward? > > > > > > I had not realized that the PSTATE register was not saved correctly > > > at that point. This is one reason why I decided to move in the > > > current fprobe-on-fgraph direction. > > > > Sure, but you said yourself, the same problem exists with current > > kretprobe implementation, so this won't regress anything. And yes, > > your fprobe-on-fgraph series is supposed to fix this for good, which > > is great, but that's a separate topic. > > It does not regress kretprobe, but introduces the same problem to > fprobe. I'm not sure if we are on the same page. There is no FPROBE on arm64 right now due to lack of HAVE_RETHOOK. Implementing rethook on ARM64 quickly will enable FPROBE on ARM64 and make it so that this can be pretty easily backported to old kernels. Yes, PSTATE register won't be complete (we can set it to zero or whatever to make this more obvious), but then an entire BPF multi-kprobe functionality will start working on ARM64. In my mind it's undoubtedly **much better** to not have PSTATE value and have FPROBE and thus BPF multi-kprobes than not having anything at all. > And since fprobe-on-fgraph was boosted by this problem, > I think that is not a separate topic. I see fprobe-on-fgraph as an improvement on top of implementing RETHOOK for ARM64, it doesn't have to block and preclude it. I'm quite puzzled that PSTATE register value is a big deal for you, but 15% performance drop (for anyone following, see [1]) due to fprobe-on-fgraph is somehow not. Quoting you from [0]: > Anyway, performance optimization can be done > afterwards, so I'm not so worried it :) If "afterwards" means before we turn on fprobe-on-fgraph for x86-64, then sure. But otherwise I'm not sure it's acceptable to just have a 15% regression just like that. [0] https://lore.kernel.org/bpf/20240912100928.a7322dc9161a90aa723662c4@xxxxxxxxxx/ [1] https://lore.kernel.org/bpf/ZuHhD35xHpw2kCC-@krava/ > > Thank you, > > -- > Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
