| Message ID | 20240502122313.1579719-1-jolsa@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | uprobe: uretprobe speed up | expand |
On Thu, May 2, 2024 at 5:23 AM Jiri Olsa <jolsa@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 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 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 > 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 > 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 (6): > uprobe: Wire up uretprobe system call > uprobe: Add uretprobe syscall to speed up return probe > 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 compat test > > arch/x86/entry/syscalls/syscall_64.tbl | 1 + > arch/x86/kernel/uprobes.c | 115 ++++++++++++++++++++++++++++ > 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/.gitignore | 1 + > tools/testing/selftests/bpf/Makefile | 7 +- > tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c | 123 ++++++++++++++++++++++++++++- > tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c | 382 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > tools/testing/selftests/bpf/progs/uprobe_syscall.c | 15 ++++ > tools/testing/selftests/bpf/progs/uprobe_syscall_executed.c | 17 +++++ > 14 files changed, 691 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 > > man2/uretprobe.2 | 45 +++++++++++++++++++++++++++++++++++++++++++++ > 1 file changed, 45 insertions(+) > create mode 100644 man2/uretprobe.2
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@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.478ccf1e735a63c6c1b4c66b@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
On Thu, May 2, 2024 at 1:04 PM Jiri Olsa <olsajiri@gmail.com> 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@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 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. 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? > > > > > > > > > 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.478ccf1e735a63c6c1b4c66b@kernel.org/ > Ok, then we'll have to land this patch set as two separate ones. It's fine, let's figure out if you need to do anything for shadow stacks and try to land it soon. > > 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
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@gmail.com> 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@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 > > 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 jirka
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@gmail.com> 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@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 > > > > 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
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 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 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, 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 (6): uprobe: Wire up uretprobe system call uprobe: Add uretprobe syscall to speed up return probe 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 compat test arch/x86/entry/syscalls/syscall_64.tbl | 1 + arch/x86/kernel/uprobes.c | 115 ++++++++++++++++++++++++++++ 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/.gitignore | 1 + tools/testing/selftests/bpf/Makefile | 7 +- tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c | 123 ++++++++++++++++++++++++++++- tools/testing/selftests/bpf/prog_tests/uprobe_syscall.c | 382 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ tools/testing/selftests/bpf/progs/uprobe_syscall.c | 15 ++++ tools/testing/selftests/bpf/progs/uprobe_syscall_executed.c | 17 +++++ 14 files changed, 691 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 man2/uretprobe.2 | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 man2/uretprobe.2