On Fri, May 31, 2024 at 10:52 AM Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx> wrote: > > On Thu, May 23, 2024 at 5:11 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-8 are based on bpf-next/master, but patch 2 and 3 are > > apply-able on linux-trace.git tree probes/for-next branch. > > Patch 9 is based on man-pages master. > > > > v7 changes: > > - fixes in man page [Alejandro Colomar] > > - fixed patch #1 fixes tag [Oleg] > > > > Also available at: > > https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git > > uretprobe_syscall > > > > 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, because we need > > 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 is in separate change, > > selftests and man page changes are part of the patchset. > > > > - Generic System Call Implementation > > There's no CONFIG option for the new functionality because it > > keeps the same behaviour from the user POV. > > > > - x86 System Call Implementation > > It's 64-bit syscall only. > > > > - Compatibility System Calls (Generic) > > N/A uretprobe syscall has no arguments and is not supported > > for compat processes. > > > > - Compatibility System Calls (x86) > > N/A uretprobe syscall is not supported for compat processes. > > > > - System Calls Returning Elsewhere > > N/A. > > > > - Other Details > > N/A. > > > > - Testing > > Adding new bpf selftests and ran ltp on top of this change. > > > > - Man Page > > Attached. > > > > - Do not call System Calls in the Kernel > > N/A. > > > > > > [0] https://lore.kernel.org/bpf/ZeCXHKJ--iYYbmLj@krava/ > > --- > > Jiri Olsa (8): > > x86/shstk: Make return uprobe work with shadow stack > > uprobe: Wire up uretprobe system call > > uprobe: Add uretprobe syscall to speed up return probe > > selftests/x86: Add return uprobe shadow stack test > > selftests/bpf: Add uretprobe syscall test for regs integrity > > selftests/bpf: Add uretprobe syscall test for regs changes > > selftests/bpf: Add uretprobe syscall call from user space test > > selftests/bpf: Add uretprobe shadow stack test > > > > Masami, Steven, > > It seems like the series is ready to go in. Are you planning to take > the first 4 patches through your linux-trace tree? Another ping. It's been two weeks since Jiri posted the last revision that got no more feedback to be addressed and everyone seems to be happy with it. This is an important speed up improvement for uprobe infrastructure in general and for BPF ecosystem in particular. "Uprobes are slow" is one of the top complaints from production BPF users, and sys_uretprobe approach is significantly improving the situation for return uprobes (aka uretprobes), potentially enabling new use cases that previously could have been too expensive to trace in practice and reducing the overhead of the existing ones. I'd appreciate the engagement from linux-trace maintainers on this patch set. Given it's important for BPF and that a big part of the patch set is BPF-based selftests, we'd also be happy to route all this through the bpf-next tree (which would actually make logistics for us much easier, but that's not the main concern). But regardless of the tree, it would be nice to make a decision and go forward with it. Thank you! > > > arch/x86/entry/syscalls/syscall_64.tbl | 1 + > > arch/x86/include/asm/shstk.h | 4 + > > arch/x86/kernel/shstk.c | 16 ++++ > > arch/x86/kernel/uprobes.c | 124 ++++++++++++++++++++++++++++- > > include/linux/syscalls.h | 2 + > > include/linux/uprobes.h | 3 + > > include/uapi/asm-generic/unistd.h | 5 +- > > kernel/events/uprobes.c | 24 ++++-- > > kernel/sys_ni.c | 2 + > > tools/include/linux/compiler.h | 4 + > > tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c | 123 ++++++++++++++++++++++++++++- > > tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c | 385 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > tools/testing/selftests/bpf/progs/uprobe_syscall.c | 15 ++++ > > tools/testing/selftests/bpf/progs/uprobe_syscall_executed.c | 17 ++++ > > tools/testing/selftests/x86/test_shadow_stack.c | 145 ++++++++++++++++++++++++++++++++++ > > 15 files changed, 860 insertions(+), 10 deletions(-) > > create mode 100644 tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c > > create mode 100644 tools/testing/selftests/bpf/progs/uprobe_syscall.c > > create mode 100644 tools/testing/selftests/bpf/progs/uprobe_syscall_executed.c > > > > Jiri Olsa (1): > > man2: Add uretprobe syscall page > > > > man/man2/uretprobe.2 | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > 1 file changed, 56 insertions(+) > > create mode 100644 man/man2/uretprobe.2
