Skip to content

Conversation

pzakha
Copy link
Contributor

@pzakha pzakha commented Oct 20, 2020

lecopzer and others added 30 commits May 22, 2019 23:15
…tach_probe

Most lines in bpf_attach_kprobe and bpf_attach_uprobe are same and
can be merged into a single function.

Introduce `bpf_attach_probe()` as an internal interface inside bpf_attach_[k,u]probe.
When creating [k,u]probe, comment above bpf_try_perf_event_open_with_probe()
said "new kernel API".

"new" is a relative concept and it's committed at f180ea1
("bcc: add functions to use new [k,u]probe API"), it's not "new" now.

The "new" API came from
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e12f03d

Remove "new" word and explicit provide which commit in the Linux kernel is.
This patch syncs with libbpf v0.0.3.

Signed-off-by: Yonghong Song <yhs@fb.com>
The function arguments have been changed in Linux 5.1,
breaking the non-audit filter. The kernel also introduced
the INSETID bit:
https://github.com/torvalds/linux/blob/v5.1/include/linux/security.h#L65

Fix the bit logic to detect non-audit calls and
display the INSETID bit if available in an own column.
Signed-off-by: forrestchen <forrestchen@tencent.com>
The LLVM 9.0 is able to generated BTF DataSec kind to
represent global and static variables.
   https://reviews.llvm.org/rL356326
At the time of DataSec kind generation, the DataSec
size is not known and hence the zero is put there.
But the verifier requires a legal non-zero DataSec
size and bpf loader has to patch the correct value.
In Linux, libbpf did patching right before
loading the program into the kernel.

This patch patches the DataSec kind size with
correct section size.

Signed-off-by: Yonghong Song <yhs@fb.com>
For section name, the kernel does not accept '/'.
So change DataSec name here to please the kenerl
as we do not really use DataSec yet.
This change can be removed if the kernel is
changed to accpet '/' in section names.

Signed-off-by: Yonghong Song <yhs@fb.com>
Compiling bcc with latest clang built from trunk, I got
the following warning:
  In file included from /home/yhs/work/bcc/src/cc/frontends/clang/tp_frontend_action.cc:32:
  /home/yhs/work/bcc/src/cc/frontends/clang/tp_frontend_action.h:53:22: warning: private field 'C' is not used
        [-Wunused-private-field]
    clang::ASTContext &C;
                       ^

This patch removed this unused field.

Signed-off-by: Yonghong Song <yhs@fb.com>
remove unused field in tp_frontend_action.h
Signed-off-by: Brenden Blanco <bblanco@gmail.com>
sync with latest upstream libbpf repo. The main change
is to bring bpf_send_signal() helper to bcc. The
bpf_send_signal() helper is implemented in the current
development version 5.3. Available in bpf-next now.

Signed-off-by: Yonghong Song <yhs@fb.com>
tools: Added exitsnoop: Trace all process termination
The TID and the INSETID bit are the less interesting
fields and keeping them out allows to reduce the line
length below 80 characters.

Closes iovisor/bcc#2392
capable: Hide TID and INSETID columns by default
Add a -T option to include a time column on output (HH:MM:SS) and update manpage
and example file accordingly.
In upstream kernel, the path has been renamed as the kheaders got moved
to sysfs. Let us update BCC with the new path.

Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
build: Rename kheaders location from proc to sys
tools/execsnoop: add -T option
This is pretty standard practice these days as it ensures you don't
accidentally create a new method that doesn't override the base class
method. It also helps document the fact you're overriding methods.
olsajiri and others added 21 commits January 30, 2020 17:31
Currently we display the caller symbol in stack,
which ends up with output below when we enable stack:

                                  Caller   Avg Hold  Count   Max hold Total hold
                  b'flush_to_ldisc+0x22'      56112      2     103914     112225
                  b'flush_to_ldisc+0x22'
               b'process_one_work+0x1b0'
                   b'worker_thread+0x50'
                         b'kthread+0xfb'

Skipping one more symbol in stack to fix that:

                                  Caller   Avg Hold  Count   Max hold Total hold
                  b'flush_to_ldisc+0x22'       1893      2       2765       3787
               b'process_one_work+0x1b0'
                   b'worker_thread+0x50'
                         b'kthread+0xfb'

Signed-off-by: Jiri Olsa <jolsa@kernel.org>
llvm 11.0 required explicit conversion from StringRef to std::string.
The patch is
  llvm/llvm-project@777180a

This patch made a compatible change which works for old llvm
as well.

Signed-off-by: Yonghong Song <yhs@fb.com>
* add XSKMAP support
* enable lookup for XSKMAP available from kernel 5.3
* add section for XSKMAP in reference guide
Since commit 115b959
("Fix a file descriptor leak when module is deleted (#2530)"), we
observe the following exceptions during python exit:

  Error in atexit._run_exitfuncs:
  Traceback (most recent call last):
    File "/usr/lib/python2.7/atexit.py", line 24, in _run_exitfuncs
      func(*targs, **kargs)
    File "/usr/lib/python2.7/dist-packages/bcc/__init__.py", line 1366, in cleanup
      os.close(fn.fd)
  OSError: [Errno 9] Bad file descriptor

which occurs for python programs issuing a call to 'cleanup()', or using
the 'with bcc.BPF(...)' code pattern.

BPF's 'cleanup' is registered to be invoked atexit. Alas, commit
115b959 introduced an 'os.close(fn.fd)' call for each func loaded (to
prevent accidental FD leakage).

Problem is, that the 'self.funcs' dict entries are NOT deleted, making
subsequent calls to 'cleanup' to attempt closing the same 'fn.fd' again
and again.

It is expected from 'cleanup' to operate correctly when called
repeatedly; Therefore, it should "nullify" references to closed
resources.

Fix, by deleting the reference to each unloaded function from the
'self.func' dictionary.

Fixes: 115b959 ("Fix a file descriptor leak when module is deleted (#2530)")
Reported-by: Dana Rubin <drubin@metanetworks.com>
Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Fix issue #2734.

In 4.18 and later, when CONFIG_FUNCTION_TRACER is defined, kernel Makefile adds
-DCC_USING_FENTRY. Let do the same for bpf programs.

Signed-off-by: Yonghong Song <yhs@fb.com>
A couple of issues fixed:

- put snapcraft.yaml in the snap directory so it is
  picked up by snapcraft when run from the project root.
- use snap/local for local snapcraft assets.
- setup.py.in should not add root for sdist targets
- cleanup snap/README.md.
- re-arrange parts in snapcraft.yaml and move to python3.

Signed-off-by: Sergio Schvezov <sergio.schvezov@canonical.com>
Fix issue #2352.
Corresponding llvm bug: https://bugs.llvm.org/show_bug.cgi?id=41918.

If the element type is array type, the rewriter may generate code like
  addr = ({ typeof(__u8 [16]) _val; __builtin_memset(&_val, 0, sizeof(_val));
            bpf_probe_read(&_val, sizeof(_val), (u64)&daddr->s6_addr); _val; })
for something like
  addr = daddr->s6_addr;
where s6_addr is an array.

The above code has an issue then as addr is pointing to some data
which is out of scope, which meaning compiler is free to use the space.

Let us disable such transformation until we find a good solution.

Signed-off-by: Yonghong Song <yhs@fb.com>
Fix #2739.

The issue exposed an issue that to rewrite
  CODE1: __u8 byte = daddr->s6_addr[4];
will segfault and to rewrite
  CODE2: __u8 byte = (daddr->s6_addr)[4];
will be okay.

For CODE1, the clang did not give enough information to find the text
which contains the left bracket "[", given base "daddr->s6_addr"
and subscript "4". For CODE2, the clang is able to get the information
successfuly.

I think if we really go inside the base "daddr->s6_addr" and gets to
its member field "s6_addr", we can find the needed information
for the text range containing "[". Let us fix the segfault first
and if really desirable, we can try to enhance later for CODE1 patterns.

Signed-off-by: Yonghong Song <yhs@fb.com>
This patch supports sockmap, sockhash and cgroup_local_storage
maps. Two C++ APIs, attach_func and detach_func are also
added to allow to attach program to cgroups. So this makes
using C++ APIs for cgroup based networking applications
easier to integrate with bpf programs.

The unit testing is rough as it needs some work to set up
cgroups and establish TCP connections to really test the
result of map operations. But still all supported map
operations in kernel and in C++ APIs are tested syntacically.

Signed-off-by: Yonghong Song <yhs@fb.com>
Also need libfl-dev to build on other non-x86 targets

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Check in bpftool binary to be used for BPF skeleton generation for
libbpf-based tools.

Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Check in vmlinux.h generated from Linux 5.5 version with default config. This
is used from libbpf-based tools.

Signed-off-by: Andrii Nakryiko <andriin@fb.com>
… tool

Add runqslower as a first tool converted from BCC to libbpf, utilizing BPF
CO-RE (Compile Once - Run Everywhere) approach and BPF skeleton for
interfacing with BPF programs. Current set up is Makefile based and is set up
in such a way as to enable easy addition for more tools, based on a simple and
convenient naming pattern. General build infrastructure takes case of BPF
skeleton generation, tracking dependencies, clean up, etc.

Signed-off-by: Andrii Nakryiko <andriin@fb.com>
1. Wirte a simple go, just print pid and get some website.
func main() {
	 pid := os.Getpid()
         fmt.Println(pid)
         response, err := http.Get("http://www.baidu.com")
        ....
}

./main
3581

2. But when run `tcpconnlat`, we just go tid 3585, (not pid 3581)
#./tcpconnlat
PID    COMM         IP SADDR            DADDR            DPORT LAT(ms)
3585   main         4  10.0.2.15        180.101.49.11    80    60.68

3. So run `./tcpconnlat -p 3581` not work
I have tested this situation under kernel 3.10 and 5.0.9.
@pzakha pzakha changed the base branch from 6.0/stage to 6.0/release October 20, 2020 20:21
@pzakha pzakha changed the title Syncup 6.0/stage with master Syncup 6.0/release with master Oct 20, 2020
@pzakha
Copy link
Contributor Author

pzakha commented Oct 21, 2020

I'll close this for now, given that #5 was integrated. We should probably look into syncing bcc with upstream on master first, as it's already 8 months old, and then we can sync 6.0/stage.

@pzakha pzakha closed this Oct 21, 2020
prakashsurya pushed a commit that referenced this pull request Nov 8, 2022
…for -v option

Add additional information and change format of backtrace
- add symbol base offset, dso name, dso base offset
- symbol and dso info is included if it's available in target binary
- changed format:
INDEX ADDR [SYMBOL+OFFSET] (MODULE+OFFSET)

Print backtrace of ip if it failed to get syms.

Before:
  # offcputime -v
    psiginfo
    vscanf
    __snprintf_chk
    [unknown]
    [unknown]
    [unknown]
    [unknown]
    [unknown]
    sd_event_exit
    sd_event_dispatch
    sd_event_run
    [unknown]
    __libc_start_main
    [unknown]
    -                systemd-journal (204)
        1

    xas_load
    xas_find
    filemap_map_pages
    __handle_mm_fault
    handle_mm_fault
    do_page_fault
    do_translation_fault
    do_mem_abort
    do_el0_ia_bp_hardening
    el0_ia
    xas_load
    --
failed to get syms
      -                PmLogCtl (138757)
        1

After:
  # offcputime -v
    #0  0xffffffc01018b7e8 __arm64_sys_clock_nanosleep+0x0
    #1  0xffffffc01009a93c el0_svc_handler+0x34
    #2  0xffffffc010084a08 el0_svc+0x8
    #3  0xffffffc01018b7e8 __arm64_sys_clock_nanosleep+0x0
    --
    #4  0x0000007fa0bffd14 clock_nanosleep+0x94 (/usr/lib/libc-2.31.so+0x9ed14)
    #5  0x0000007fa0c0530c nanosleep+0x1c (/usr/lib/libc-2.31.so+0xa430c)
    #6  0x0000007fa0c051e4 sleep+0x34 (/usr/lib/libc-2.31.so+0xa41e4)
    #7  0x000000558a5a9608 flb_loop+0x28 (/usr/bin/fluent-bit+0x52608)
    #8  0x000000558a59f1c4 flb_main+0xa84 (/usr/bin/fluent-bit+0x481c4)
    #9  0x0000007fa0b85124 __libc_start_main+0xe4 (/usr/lib/libc-2.31.so+0x24124)
    #10 0x000000558a59d828 _start+0x34 (/usr/bin/fluent-bit+0x46828)
    -                fluent-bit (1238)
        1

    #0  0xffffffc01027daa4 generic_copy_file_checks+0x334
    #1  0xffffffc0102ba634 __handle_mm_fault+0x8dc
    #2  0xffffffc0102baa20 handle_mm_fault+0x168
    #3  0xffffffc010ad23c0 do_page_fault+0x148
    #4  0xffffffc010ad27c0 do_translation_fault+0xb0
    #5  0xffffffc0100816b0 do_mem_abort+0x50
    #6  0xffffffc0100843b0 el0_da+0x1c
    #7  0xffffffc01027daa4 generic_copy_file_checks+0x334
    --
    #8  0x0000007f8dc12648 [unknown]
    #9  0x0000007f8dc0aef8 [unknown]
    #10 0x0000007f8dc1c990 [unknown]
    #11 0x0000007f8dc08b0c [unknown]
    #12 0x0000007f8dc08e48 [unknown]
    #13 0x0000007f8dc081c8 [unknown]
    -                PmLogCtl (2412)
        1

Fixed: #3884
Signed-off-by: Eunseon Lee <es.lee@lge.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.