Message ID | 1628025796-29533-1-git-send-email-alan.maguire@oracle.com (mailing list archive) |
---|---|
Headers | show |
Series | tools: ksnoop: tracing kernel function entry/return with argument/return value display | expand |
Hi Alan, On 8/3/21 11:23 PM, Alan Maguire wrote: > Recent functionality added to libbpf [1] enables typed display of kernel > data structures; here that functionality is exploited to provide a > simple example of how a tracer can support deep argument/return value > inspection. The intent is to provide a demonstration of these features > to help facilitate tracer adoption, while also providing a tool which > can be useful for kernel debugging. Thanks a lot for working on this tool, this looks _super useful_! Right now under tools/bpf/ we have bpftool and resolve_btfids as the two main tools, the latter used during kernel build, and the former evolving with the kernel together with libbpf. The runqslower in there was originally thought of as a single/small example tool to demo how to build stand-alone tracing tools with all the modern practices, though the latter has also been added to [0] (thus could be removed). I would rather love if you could add ksnoop for inclusion into bcc's libbpf-based tracing tooling suite under [0] as well which would be a better fit long term rather than kernel tree for the tool to evolve. We don't intend to add a stand-alone tooling collection under the tools/bpf/ long term since these can evolve better outside of kernel tree. Thanks a lot, Daniel [0] https://github.com/iovisor/bcc/tree/master/libbpf-tools > Changes since RFC [2]: > > - In the RFC version, kernel data structures were string-ified in > BPF program context vi bpf_snprintf_btf(); Alexei pointed out that > it would be better to dump memory to userspace and let the > interpretation happen there. btf_dump__dump_type_data() in libbpf > now supports this (Alexei, patch 1) > - Added the "stack mode" specification where we trace a specific set > of functions being called in order (though not necessarily directly). > This mode of tracing is useful when debugging issues with a specific > stack signature. > > [1] https://lore.kernel.org/bpf/1626362126-27775-1-git-send-email-alan.maguire@oracle.com/ > [2] https://lore.kernel.org/bpf/1609773991-10509-1-git-send-email-alan.maguire@oracle.com/ > > Alan Maguire (3): > tools: ksnoop: kernel argument/return value tracing/display using BTF > tools: ksnoop: document ksnoop tracing of entry/return with value > display > tools: ksnoop: add .gitignore > > tools/bpf/Makefile | 20 +- > tools/bpf/ksnoop/.gitignore | 1 + > tools/bpf/ksnoop/Documentation/Makefile | 58 ++ > tools/bpf/ksnoop/Documentation/ksnoop.rst | 173 ++++++ > tools/bpf/ksnoop/Makefile | 107 ++++ > tools/bpf/ksnoop/ksnoop.bpf.c | 391 +++++++++++++ > tools/bpf/ksnoop/ksnoop.c | 890 ++++++++++++++++++++++++++++++ > tools/bpf/ksnoop/ksnoop.h | 103 ++++ > 8 files changed, 1738 insertions(+), 5 deletions(-) > create mode 100644 tools/bpf/ksnoop/.gitignore > create mode 100644 tools/bpf/ksnoop/Documentation/Makefile > create mode 100644 tools/bpf/ksnoop/Documentation/ksnoop.rst > create mode 100644 tools/bpf/ksnoop/Makefile > create mode 100644 tools/bpf/ksnoop/ksnoop.bpf.c > create mode 100644 tools/bpf/ksnoop/ksnoop.c > create mode 100644 tools/bpf/ksnoop/ksnoop.h >
On Wed, 4 Aug 2021, Daniel Borkmann wrote: > Hi Alan, > > On 8/3/21 11:23 PM, Alan Maguire wrote: > > Recent functionality added to libbpf [1] enables typed display of kernel > > data structures; here that functionality is exploited to provide a > > simple example of how a tracer can support deep argument/return value > > inspection. The intent is to provide a demonstration of these features > > to help facilitate tracer adoption, while also providing a tool which > > can be useful for kernel debugging. > > Thanks a lot for working on this tool, this looks _super useful_! Right now > under tools/bpf/ we have bpftool and resolve_btfids as the two main tools, > the latter used during kernel build, and the former evolving with the kernel > together with libbpf. The runqslower in there was originally thought of as > a single/small example tool to demo how to build stand-alone tracing tools > with all the modern practices, though the latter has also been added to [0] > (thus could be removed). I would rather love if you could add ksnoop for > inclusion into bcc's libbpf-based tracing tooling suite under [0] as well > which would be a better fit long term rather than kernel tree for the tool > to evolve. We don't intend to add a stand-alone tooling collection under the > tools/bpf/ long term since these can evolve better outside of kernel tree. > Sounds good; I'll look into contributing the tool to bcc. Thanks! Alan
On 8/5/21 1:14 PM, Alan Maguire wrote: > On Wed, 4 Aug 2021, Daniel Borkmann wrote: >> On 8/3/21 11:23 PM, Alan Maguire wrote: >>> Recent functionality added to libbpf [1] enables typed display of kernel >>> data structures; here that functionality is exploited to provide a >>> simple example of how a tracer can support deep argument/return value >>> inspection. The intent is to provide a demonstration of these features >>> to help facilitate tracer adoption, while also providing a tool which >>> can be useful for kernel debugging. >> >> Thanks a lot for working on this tool, this looks _super useful_! Right now >> under tools/bpf/ we have bpftool and resolve_btfids as the two main tools, >> the latter used during kernel build, and the former evolving with the kernel >> together with libbpf. The runqslower in there was originally thought of as >> a single/small example tool to demo how to build stand-alone tracing tools >> with all the modern practices, though the latter has also been added to [0] >> (thus could be removed). I would rather love if you could add ksnoop for >> inclusion into bcc's libbpf-based tracing tooling suite under [0] as well >> which would be a better fit long term rather than kernel tree for the tool >> to evolve. We don't intend to add a stand-alone tooling collection under the >> tools/bpf/ long term since these can evolve better outside of kernel tree. > > Sounds good; I'll look into contributing the tool to bcc. Awesome, thanks a lot Alan!