On Fri, May 03, 2024 at 10:39:21PM +0200, Jiri Olsa wrote: > On Fri, May 03, 2024 at 11:03:24AM -0700, Andrii Nakryiko wrote: > > On Thu, May 2, 2024 at 1:04 PM Jiri Olsa <olsajiri@xxxxxxxxx> wrote: > > > > > > On Thu, May 02, 2024 at 09:43:02AM -0700, Andrii Nakryiko wrote: > > > > On Thu, May 2, 2024 at 5:23 AM Jiri Olsa <jolsa@xxxxxxxxxx> wrote: > > > > > > > > > > hi, > > > > > as part of the effort on speeding up the uprobes [0] coming with > > > > > return uprobe optimization by using syscall instead of the trap > > > > > on the uretprobe trampoline. > > > > > > > > > > The speed up depends on instruction type that uprobe is installed > > > > > and depends on specific HW type, please check patch 1 for details. > > > > > > > > > > Patches 1-6 are based on bpf-next/master, but path 1 and 2 are > > > > > apply-able on linux-trace.git tree probes/for-next branch. > > > > > Patch 7 is based on man-pages master. > > > > > > > > > > v4 changes: > > > > > - added acks [Oleg,Andrii,Masami] > > > > > - reworded the man page and adding more info to NOTE section [Masami] > > > > > - rewrote bpf tests not to use trace_pipe [Andrii] > > > > > - cc-ed linux-man list > > > > > > > > > > Also available at: > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git > > > > > uretprobe_syscall > > > > > > > > > > > > > It looks great to me, thanks! Unfortunately BPF CI build is broken, > > > > probably due to some of the Makefile additions, please investigate and > > > > fix (or we'll need to fix something on BPF CI side), but it looks like > > > > you'll need another revision, unfortunately. > > > > > > > > pw-bot: cr > > > > > > > > [0] https://github.com/kernel-patches/bpf/actions/runs/8923849088/job/24509002194 > > > > > > yes, I think it's missing the 32-bit libc for uprobe_compat binary, > > > probably it needs to be added to github.com:libbpf/ci.git setup-build-env/action.yml ? > > > hm but I'm not sure how to test it, need to check > > > > You can create a custom PR directly against Github repo > > (kernel-patches/bpf) and BPF CI will run all the tests on your custom > > code. This way you can iterate without spamming the mailing list. > > I'm running CI tests like that, but I think I need to change the action > which is in other repo (github.com:libbpf/ci.git) > > > > > But I'm just wondering if it's worth complicating setup just for > > testing this x32 compat mode. So maybe just dropping one of those > > patches would be better? > > well, we had compat process crashing on uretprobe because of this change, > so I rather keep the test.. or it can go in later on when the CI stuff is > figured out.. I got busy with the shadow stack issue today, will check on > the CI PR next week ok, it's not as easy as just adding the package.. I don't want to delay this on my missing github skills, I'll skip the test in next version and submit it separately when the github ci is ready for that jirka
