> On Mar 3, 2021, at 10:11 AM, Daniel Xu <d...@dxuuu.xyz> wrote: > > On Tue, Mar 02, 2021 at 06:18:23PM -0800, Alexei Starovoitov wrote: >>> On Tue, Mar 2, 2021 at 5:46 PM Andy Lutomirski <l...@amacapital.net> wrote: >>> >>> >>>> On Mar 2, 2021, at 5:22 PM, Alexei Starovoitov >>>> <alexei.starovoi...@gmail.com> wrote: >>>> >>>> On Tue, Mar 2, 2021 at 1:02 PM Andy Lutomirski <l...@amacapital.net> >>>> wrote: >>>>> >>>>> >>>>>>> On Mar 2, 2021, at 12:24 PM, Alexei Starovoitov >>>>>>> <alexei.starovoi...@gmail.com> wrote: >>>>>> >>>>>> On Tue, Mar 2, 2021 at 10:38 AM Andy Lutomirski <l...@kernel.org> wrote: >>>>>>> >>>>>>> Is there something like a uprobe test suite? How maintained / >>>>>>> actively used is uprobe? >>>>>> >>>>>> uprobe+bpf is heavily used in production. >>>>>> selftests/bpf has only one test for it though. >>>>>> >>>>>> Why are you asking? >>>>> >>>>> Because the integration with the x86 entry code is a mess, and I want to >>>>> know whether to mark it BROKEN or how to make sure the any cleanups >>>>> actually work. >>>> >>>> Any test case to repro the issue you found? >>>> Is it a bug or just messy code? >>> >>> Just messy code. >>> >>>> Nowadays a good chunk of popular applications (python, mysql, etc) has >>>> USDTs in them. >>>> Issues reported with bcc: >>>> https://github.com/iovisor/bcc/issues?q=is%3Aissue+USDT >>>> Similar thing with bpftrace. >>>> Both standard USDT and semaphore based are used in the wild. >>>> uprobe for containers has been a long standing feature request. >>>> If you can improve uprobe performance that would be awesome. >>>> That's another thing that people report often. We optimized it a bit. >>>> More can be done. >>> >>> >>> Wait... USDT is much easier to implement well. Are we talking just USDT or >>> are we talking about general uprobes in which almost any instruction can >>> get probed? If the only users that care about uprobes are doing USDT, we >>> could vastly simplify the implementation and probably make it faster, too. >> >> USDTs are driving the majority of uprobe usage. > > I'd say 50/50 in my experience. Larger userspace applications using bpf > for production monitoring tend to use USDT for stability and ABI reasons > (hard for bpf to read C++ classes). Bare uprobes (ie not USDT) are used > quite often for ad-hoc production debugging. > >> If they can get faster it will increase their adoption even more. >> There are certainly cases of normal uprobes. >> They are at the start of the function 99% of the time. >> Like the following: >> "uprobe:/lib64/libc.so:malloc(u64 size):size:size,_ret", >> "uprobe:/lib64/libc.so:free(void *ptr)::ptr", >> is common despite its overhead. >> >> Here is the most interesting and practical usage of uprobes: >> https://github.com/iovisor/bcc/blob/master/tools/sslsniff.py >> and the manpage for the tool: >> https://github.com/iovisor/bcc/blob/master/tools/sslsniff_example.txt >> >> uprobe in the middle of the function is very rare. >> If the kernel starts rejecting uprobes on some weird instructions >> I suspect no one will complain. > > I think it would be great if the kernel could reject mid-instruction > uprobes. Unlike with kprobes, you can place uprobes on immediate > operands which can cause silent data corruption. See > https://github.com/iovisor/bpftrace/pull/803#issuecomment-507693933 > for a funny example.
This can’t be done in general on x86. One cannot look at code and find the instruction boundaries. > > To prevent accidental (and silent) data corruption, bpftrace uses a > disassembler to ensure uprobes are placed on instruction boundaries. > > <...> > > Daniel
