Re: [PATCH bpf-next 0/3] tools: ksnoop: tracing kernel function entry/return with argument/return value display

[Daniel Borkmann <daniel@iogearbox.net>]

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
>