On Thu, May 02, 2024 at 09:43:02AM -0700, Andrii Nakryiko wrote: > On Thu, May 2, 2024 at 5:23 AM Jiri Olsa <jo...@kernel.org> 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 > > > > But while we are at it. > > Masami, Oleg, > > What should be the logistics of landing this? Can/should we route this > through the bpf-next tree, given there are lots of BPF-based > selftests? Or you want to take this through > linux-trace/probes/for-next? In the latter case, it's probably better > to apply only the first two patches to probes/for-next and the rest > should still go through the bpf-next tree (otherwise we are running I think this was the plan, previously mentioned in here: https://lore.kernel.org/bpf/20240423000943.478ccf1e735a63c6c1b4c...@kernel.org/ > into conflicts in BPF selftests). Previously we were handling such > cross-tree dependencies by creating a named branch or tag, and merging > it into bpf-next (so that all SHAs are preserved). It's a bunch of > extra work for everyone involved, so the simplest way would be to just > land through bpf-next, of course. But let me know your preferences. > > Thanks! > > > thanks, > > jirka > > > > > > Notes to check list items in Documentation/process/adding-syscalls.rst: > > > > - System Call Alternatives > > New syscall seems like the best way in here, becase we need > > typo (thanks, Gmail): because ok > > > just to quickly enter kernel with no extra arguments processing, > > which we'd need to do if we decided to use another syscall. > > > > - Designing the API: Planning for Extension > > The uretprobe syscall is very specific and most likely won't be > > extended in the future. > > > > At the moment it does not take any arguments and even if it does > > in future, it's allowed to be called only from trampoline prepared > > by kernel, so there'll be no broken user. > > > > - Designing the API: Other Considerations > > N/A because uretprobe syscall does not return reference to kernel > > object. > > > > - Proposing the API > > Wiring up of the uretprobe system call si in separate change, > > typo: is ok, thanks jirka
