mbox series

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

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

Message

Alan Maguire Aug. 3, 2021, 9:23 p.m. UTC
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.

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

Comments

Daniel Borkmann Aug. 4, 2021, 9:05 p.m. UTC | #1
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
>
Alan Maguire Aug. 5, 2021, 11:14 a.m. UTC | #2
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
Daniel Borkmann Aug. 6, 2021, 2:56 p.m. UTC | #3
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!