Commit
bac633a6bb60b6b8542348ea3f61c367eae14f7c
by jmarchantools: fix runqslower warning
The state member of task_struct is volatile and it's use as the last parameter of bpf_probe_read (const void *) triggers the following clang warning (LLVM 8):
/virtual/main.c:56:42: warning: passing 'volatile long *' to parameter of type 'const void *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] bpf_probe_read(&state, sizeof(long), &prev->state); ^~~~~~~~~~~~ 1 warning generated. Tracing run queue latency higher than 10000 us TIME COMM PID LAT(us)
An explicit cast fixes the warning.
|
| tools/runqslower.py (diff) |
|
| tools/btrfsslower.py (diff) |
|
| src/cc/libbpf (diff) |
| src/cc/compat/linux/virtual_bpf.h (diff) |
| introspection/bps.c (diff) |
|
| src/cc/api/BPF.h (diff) |
| src/cc/ns_guard.cc |
| tests/cc/usdt_test_lib.c |
| src/cc/libbpf.c (diff) |
| tests/cc/CMakeLists.txt (diff) |
| src/cc/usdt.h (diff) |
| examples/cpp/pyperf/PyPerfUtil.cc (diff) |
| src/cc/CMakeLists.txt (diff) |
| tests/cc/test_c_api.cc (diff) |
| src/cc/bcc_elf.c (diff) |
| src/cc/ns_guard.h |
| src/cc/bcc_syms.h (diff) |
| src/cc/usdt/usdt.cc (diff) |
| src/cc/api/BPF.cc (diff) |
| src/cc/bcc_proc.c (diff) |
| src/cc/bcc_syms.cc (diff) |
| src/cc/syms.h (diff) |
| tests/cc/dummy_proc_map.txt |
| tests/cc/test_usdt_probes.cc (diff) |
| src/cc/bcc_proc.h (diff) |
Commit
d42fcc8eabfe2197cb2aba67113e839240d4b9a5
by yonghong-songLazily symbolize regular ELF binaries
This patch adds a new API to bcc_elf.h, bcc_elf_foreach_sym_lazy. This helper avoids storing symbol names in string format, as for large binaries this data can get quite large.
Instead we store the location in the ELF binary where we can later find the string. Later on, we can load these strings on demand and cache them in case they're accessed again.
This patch also makes lazy resolution the default for regular ELF binaries, where regular means not perfmap or VDSO.
|
| src/cc/bcc_syms.cc (diff) |
| src/cc/bcc_elf.c (diff) |
| src/cc/syms.h (diff) |
| src/cc/bcc_elf.h (diff) |
|
| src/cc/bcc_syms.cc (diff) |
|
| src/cc/bcc_elf.c (diff) |
|
| src/cc/syms.h (diff) |
| src/cc/bcc_elf.h (diff) |
| src/cc/bcc_syms.cc (diff) |
| src/cc/bcc_elf.c (diff) |
|
| src/cc/bcc_syms.cc (diff) |
|
| src/cc/bcc_syms.cc (diff) |
| src/cc/bcc_syms.h (diff) |
| src/cc/syms.h (diff) |
| src/cc/bcc_elf.c (diff) |
|
| tests/cc/test_c_api.cc (diff) |
|
| src/cc/api/BPFTable.cc (diff) |
| src/lua/bcc/libbcc.lua (diff) |
| src/cc/bcc_syms.cc (diff) |
| src/cc/usdt/usdt_args.cc (diff) |
| examples/cpp/pyperf/PyPerfUtil.cc (diff) |
|
| src/cc/bcc_syms.cc (diff) |
|
| tools/inject_example.txt (diff) |
| man/man8/inject.8 (diff) |
Commit
10dae9eac33287c1df9e6645933b608c2d2c5640
by yonghong-songfix various compilation warnings
The following compilation warnings are fix: ... /home/yhs/work/bcc/src/cc/libbpf.c:548:12: warning: comparison of distinct pointer types ('typeof (name_len - name_offset) *' (aka 'unsigned long *') and 'typeof (16U - 1) *' (aka 'unsigned int *')) [-Wcompare-distinct-pointer-types] min(name_len - name_offset, BPF_OBJ_NAME_LEN - 1)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /home/yhs/work/bcc/src/cc/libbpf/include/linux/kernel.h:28:17: note: expanded from macro 'min' (void) (&_min1 == &_min2); ... /home/yhs/work/bcc/src/cc/bcc_syms.h:71:34: warning: declaration of 'struct mod_info' will not be visible outside of this function [-Wvisibility] int _bcc_syms_find_module(struct mod_info *info, int enter_ns, void *p); ... /home/yhs/work/bcc/src/cc/usdt/usdt.cc:486:14: warning: unused variable 'pid' [-Wunused-variable] auto pid = ctx->pid(); ^ ...
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| src/cc/usdt/usdt.cc (diff) |
| src/cc/libbpf.c (diff) |
| src/cc/bcc_syms.h (diff) |
Commit
a74c0429396f3180ba5b20f4a4eefc233b681cb4
by yonghong-songfix asm_volatile_goto issue again
In src/cc/export/helpers.h, we tried to define asm_volatile_goto to something else if it is defined through uapi bpf.h. #ifdef asm_volatile_goto #undef asm_volatile_goto #define asm_volatile_goto(x...) asm volatile("invalid use of asm_volatile_goto") #endif
It is possible that due to different kernel configurations, asm_volatile_goto may not be defined after uapi bpf.h. To prevent compilation errors, let us unconditionally define asm_volatile_goto here.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| src/cc/export/helpers.h (diff) |
|
| .travis.yml (diff) |
|
| src/python/bcc/table.py (diff) |
|
| .travis.yml (diff) |
|
| .travis.yml (diff) |
|
| .travis.yml (diff) |
|
| examples/tracing/stack_buildid_example.py (diff) |
|
| tests/python/test_probe_count.py (diff) |
|
| src/cc/frontends/p4/compiler/ebpfDeparser.py (diff) |
|
| src/cc/frontends/p4/compiler/target.py (diff) |
|
| src/cc/frontends/p4/compiler/ebpfDeparser.py (diff) |
|
| src/cc/frontends/p4/test/endToEndTest.py (diff) |
|
| src/cc/frontends/p4/compiler/p4toEbpf.py (diff) |
|
| src/cc/frontends/p4/compiler/ebpfStructType.py (diff) |
|
| src/python/bcc/__init__.py (diff) |
|
| tests/python/test_lru.py (diff) |
|
| .travis.yml (diff) |
|
| .travis.yml (diff) |
|
| .travis.yml (diff) |
|
| .travis.yml (diff) |
|
| .travis.yml (diff) |
|
| .travis.yml (diff) |
|
| .travis.yml (diff) |
|
| scripts/py-style-check.sh (diff) |
|
| .travis.yml (diff) |
|
| src/lua/README.md (diff) |
|
| tools/bashreadline.py (diff) |
Commit
36219753ee17fc0af37c20828eef02520e1602dc
by yonghong-songUse bpf_prog_load function from ljsyscall module in LuaJIT compiler
At various points in the compiler code, an attempt to load the BPF program is made. In order to do this, a bpf() syscall needs to happen with BPF_PROG_LOAD as the first argument (Consult the bpf man page, under the 'eBPF programs' section). The module ljsyscall does this via the bpf_prog_load function.
At the time of writing, this function is declared in the file:
syscall/linux/syscalls.lua
In the repo:
https://github.com/justincormack/ljsyscall.git
|
| src/lua/bpf/bpf.lua (diff) |
Commit
50aeaed4d101f22027eaf07186418ec8dcbab019
by yonghong-songReport proper module on kernel backtrace
Raghavendra Rao reported that memleak does not display proper name of the related kernel module, but just the "kernel" string, like here for xfs module functions:
131072 bytes in 4 allocations from stack .. bvec_alloc+0x92 [kernel] bio_alloc_bioset+0x13f [kernel] xfs_add_to_ioend+0x2df [kernel] xfs_do_writepage+0x148 [kernel] write_cache_pages+0x171 [kernel] xfs_vm_writepages+0x59 [kernel] do_writepages+0x43 [kernel] ...
The kernel resolver code is parsing /proc/kallsyms, which already has the module information in.
This patch is adding support to parse the module info from /proc/kallsyms and initialize the module with proper value.
Above memleak backtrace now looks like:
131072 bytes in 4 allocations from stack
bvec_alloc+0x92 [kernel] bio_alloc_bioset+0x13f [kernel] xfs_add_to_ioend+0x2df [xfs] xfs_do_writepage+0x148 [xfs] write_cache_pages+0x171 [kernel] xfs_vm_writepages+0x59 [xfs] do_writepages+0x43 [kernel] ...
Reported-by: Raghavendra Rao <ragrao@redhat.com> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
|
| src/cc/bcc_proc.h (diff) |
| src/cc/bcc_proc.c (diff) |
| src/cc/syms.h (diff) |
| src/cc/bcc_syms.cc (diff) |
| tests/cc/test_c_api.cc (diff) |
|
| src/cc/libbpf (diff) |
Commit
6af649a9a1939b9bbda7f410dd115c06f89dcf14
by yonghong-songtools: fix printb usage in solisten
Since its conversion to printb, solisten has suffers from yet another python2/3 bytes/str issue:
Traceback (most recent call last): File "_ctypes/callbacks.c", line 234, in 'calling callback function' File "/usr/lib/python3.6/site-packages/bcc/table.py", line 581, in raw_cb_ callback(cpu, data, size) File "/usr/share/bcc/tools/solisten", line 176, in print_event event.lport, address, TypeError: %b requires a bytes-like object, or an object that implements __bytes__, not 'str'
This patch fix the issue on python3. The tools still works on python2.
|
| tools/solisten.py (diff) |
Commit
237a4b46567c75834476beadfb76b7c5d5b97877
by yonghong-songTurn on lazy symbolize by default
This turns on lazy symbolization by default. Symbol names will be resolved the first time they're requested and then cached for future access. This can reduce bcc memory usage by quite a bit in certain workloads.
|
| src/cc/usdt/usdt_args.cc (diff) |
| src/cc/api/BPFTable.cc (diff) |
| src/cc/bcc_syms.cc (diff) |
| examples/cpp/pyperf/PyPerfUtil.cc (diff) |
Commit
9518a5b74105a16f5c3ad3d7e0f717b153965f6e
by yonghong-songtools/tcpconnect: add option -c to count connects
Add -c to count all active connections per dest ip/port so we can easily spot the heavy outbound connection attempts.
# ./tcpconnect.py -c Tracing connect ... Hit Ctrl-C to end ^C LADDR RADDR RPORT CONNECTS 192.168.10.50 172.217.21.194 443 70 192.168.10.50 172.213.11.195 443 34 192.168.10.50 172.212.22.194 443 21 [...]
|
| man/man8/tcpconnect.8 (diff) |
| tools/tcpconnect_example.txt (diff) |
| tools/tcpconnect.py (diff) |
|
| src/cc/libbpf (diff) |
|
| CMakeLists.txt (diff) |
Commit
0206fc4e3568eab6cacfc1d5916258a9ba764f5d
by yonghong-songtools: fix vfscount output when no duration is specified
Since commit a2e71a9eb71a ("vfscount.py: add args time (#2344)"), vfscount does not show any output when it is interrupted by a key press, which is the only way out when no time limit is specified. I assume the exit() that has been added in the keyboard interrupt handler is there so that no output is displayed when the program has been interrupted early when a time limit has been specified. But since the tool still invite the user to use Ctrl-C to end the tracing in that case, it seems more consistent to show an output in that case too.
This patch removes the exit() and the tools always show a result at the end. It also adds the duration argument to the synopsis and the option section in the man page.
|
| man/man8/vfscount.8 (diff) |
| tools/vfscount.py (diff) |
Commit
68b8d3017c296d3c266e540f27ea5cf04c6c0f72
by yonghong-songSupport perf's symfs mechanism for debuginfo lookup.
Symfs is a file path prefix that needs to be prepended to full path of a library to compute location of corresponding debuginfo. It will allow bcc users to provide debug symbols if only they can write to at least one directory. Nothing else needs to be assumed regarding the system bcc runs on.
My intention is to make debuginfo lookup work on Android in one form or another. None of the gdb rules works out of the box: - native libraries are often managed by Android apps themselves and uncompressed by apps into private directories. Sideloading debuginfo into those directories might be not feasible. What's more it's desirable to remove data like debuglink from release builds of mobile apps. At the same time those builds are the most interesting ones to investigate with bcc. - there is no /usr directory on Android, so there is no /usr/lib/debug/. It could be created with some effort, but symfs is much more convenient and already used when profiling with simpleperf (fork of perf for Android).
|
| src/cc/bcc_elf.c (diff) |
Commit
33c9c571057b75ec979cc74121a0d3cb3a19be1b
by jmarchanman: fixes some man pages
In the man pages of tcplife and tcpstates, the name of the field for the remote port and address (DPORT, DADDR) differs from the tool itself (RPORT, RADDR). This patch fix the man pages.
The man page of tcpdrop mentions options that do not exists. This patch fix that. It also fix the comment at the head of the code that too mentions inexistents options.
The man pages for solisten and sofdsnoop are missing. This patch adds them.
The deadlock_detector tools has been rename simply deadlock, but its manpage is still named deadlock_detector although its content has been updated. This patch rename the manpage.
|
| man/man8/deadlock_detector.8 |
| tools/sofdsnoop.py (diff) |
| tools/solisten.py (diff) |
| tools/tcpdrop.py (diff) |
| man/man8/deadlock.8 |
| man/man8/sofdsnoop.8 |
| tools/sofdsnoop_example.txt (diff) |
| man/man8/solisten.8 |
| man/man8/tcpdrop.8 (diff) |
| man/man8/tcplife.8 (diff) |
| man/man8/tcpstates.8 (diff) |
|
| tools/offwaketime.py (diff) |
|
| src/cc/usdt/usdt.cc (diff) |
|
| docs/reference_guide.md (diff) |
|
| examples/tracing/mysqld_query.py (diff) |
|
| examples/tracing/mallocstacks.py (diff) |
|
| tools/tcptop.py (diff) |
|
| src/cc/bcc_common.h (diff) |
| src/python/bcc/__init__.py (diff) |
| src/cc/bpf_module.cc (diff) |
| tests/cc/test_static.c (diff) |
| src/cc/bcc_common.cc (diff) |
| examples/networking/xdp/xdp_drop_count.py (diff) |
| src/cc/bpf_module.h (diff) |
| src/python/bcc/libbcc.py (diff) |
|
| src/python/bcc/__init__.py (diff) |
|
| tools/stackcount.py (diff) |
Commit
ba64f031f2435aad5a85f8f37dbbe2a982cbbe6b
by yonghong-songFixes #2518 -- weird behaviour of lookup_or_init (#2520)
* Allow lookup_or_init to return NULL (rather than just returning from the current function) * Fixed a couple of bad edits found when running tests. Also fixed a bug in the test runner. Also fixed a bug in libbcc where the python signature did not match the actual implementation.
|
| tools/biotop.py (diff) |
| tools/old/offcputime.py (diff) |
| examples/networking/vlan_learning/vlan_learning.c (diff) |
| examples/networking/tunnel_monitor/monitor.c (diff) |
| examples/networking/distributed_bridge/tunnel.c (diff) |
| examples/lua/offcputime.lua (diff) |
| tools/old/profile.py (diff) |
| tests/python/test_trace2.c (diff) |
| src/python/bcc/libbcc.py (diff) |
| tests/python/test_percpu.py (diff) |
| tools/old/wakeuptime.py (diff) |
| tests/python/test_lru.py (diff) |
| tools/lib/uflow.py (diff) |
| tools/lib/ustat.py (diff) |
| examples/cpp/UseExternalMap.cc (diff) |
| tools/old/softirqs.py (diff) |
| tests/lua/test_clang.lua (diff) |
| examples/tracing/mallocstacks.py (diff) |
| tests/python/test_clang.py (diff) |
| tests/python/test_trace4.py (diff) |
| tools/filetop.py (diff) |
| tools/syscount.py (diff) |
| examples/cpp/LLCStat.cc (diff) |
| tests/cc/test_bpf_table.cc (diff) |
| tools/lib/ucalls.py (diff) |
| tools/lib/uobjnew.py (diff) |
| tests/python/test_stat1.c (diff) |
| tests/python/test_license.py (diff) |
| tools/old/offwaketime.py (diff) |
| docs/reference_guide.md (diff) |
| tools/slabratetop.py (diff) |
| examples/lua/task_switch.lua (diff) |
| examples/tracing/strlen_count.py (diff) |
| src/cc/frontends/clang/b_frontend_action.cc (diff) |
| tests/python/test_trace_maxactive.py (diff) |
| tests/python/test_trace2.py (diff) |
| docs/tutorial_bcc_python_developer.md (diff) |
| tests/python/test_trace3.c (diff) |
| examples/tracing/task_switch.c (diff) |
| tests/wrapper.sh.in (diff) |
| tools/old/stackcount.py (diff) |
| examples/cpp/TCPSendStack.cc (diff) |
| tests/python/test_tracepoint.py (diff) |
Commit
84d9798aec01bc8486f3fc88afcbe37988e3ee58
by noreplyFAQ: fix error message
The package is called bcc, and not bpf:
from bcc import BPF
If that is not available the error message reads
ModuleNotFoundError: No module named 'bcc'
and not `No module named 'bpf'`
|
| FAQ.txt (diff) |
|
| INSTALL.md (diff) |
|
| docs/reference_guide.md (diff) |
Commit
c02e5eb13d154661af39a27f202ee64ad6be63a1
by noreplyfix compilation errors with clang CreateFromArgs() change (#2528)
Upstream change https://reviews.llvm.org/D66797 (in llvm 10) changed signature of CreateFromArgs(). Compiled with latest upstream, we will have compilation error like: /home/yhs/work/bcc/src/cc/frontends/clang/loader.cc:343:57: error: ‘cargs’ was not declared in this scope; did you mean ‘ccargs’? 343 | if (!CompilerInvocation::CreateFromArgs( invocation0, cargs. diags)) | ^~~~~ | ccargs
Adjust bcc codes to use the new func signature.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| src/cc/frontends/clang/loader.cc (diff) |
Commit
903513e454c9847370f7e54797ff29f12e1de4d9
by noreplycmakefile change to require c++14 (#2529)
The latest llvm trunk (llvm 10) built require c++14. Built with gcc and llvm 10 headers, the following error will show up: ... /home/yhs/work/llvm-project/llvm/build/install/include/llvm/Support/RWMutex.h: At global scope: /home/yhs/work/llvm-project/llvm/build/install/include/llvm/Support/RWMutex.h:101:8: error: ‘shared_t$ med_mutex’ in namespace ‘std’ does not name a type std::shared_timed_mutex impl; ... /home/yhs/work/llvm-project/llvm/build/install/include/llvm/Support/TrailingObjects.h:252:19: error: ‘is_final’ is not a member of ‘std’ static_assert(std::is_final<BaseTy>(), "BaseTy must be final."); ...
std::shared_timed_mutex and std::is_final etc. are all c++14 features. Most compilers should already support c++14. Let us require it in Makefile now.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| CMakeLists.txt (diff) |
Commit
115b959d866159eecd09ca703197c809aa19ceda
by noreplyFix a file descriptor leak when module is deleted (#2530)
Fix issue #989
When module is cleaned up, let us also close all bpf program file descriptors to avoid fd leaking.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| src/python/bcc/__init__.py (diff) |
|
| FAQ.txt (diff) |
Commit
c00d10d4552f647491395e326d2e4400f3a0b6c5
by yonghong-songAdd sampe code for cgoup test (#2522)
How to run this test: 0. Make sure you have cgroup2 mounted: $ mount -t cgroup2 cgroup on /sys/fs/cgroup/unified type cgroup2 (rw,nosuid,nodev,noexec,relatime) 1. Create a test cgroup in cgroup2 fs: $ sudo mkdir /sys/fs/cgroup/unified/test 2. Run this program in a bash: $ sudo CGroupTest /sys/fs/cgroup/unified/test 3. In another bash window, do the following: $ echo $$ > /sys/fs/cgroup/unified/test/cgroup.procs $ run some other commands 4. You should be able to see lots of prints like: 'file ... was opened!'
|
| examples/cpp/CMakeLists.txt (diff) |
| examples/cpp/CGroupTest.cc |
Commit
4c2cb869dc559af2bbd92dafbf769412e638093b
by yonghong-songINSTALL.md: Fedora 30: note about kernel lockdown (#2536)
Add a note about the kernel lockdown challenge to the "Fedora 30 and newer" section.
Motivation: Fedora 30 users are likely to follow the instructions in the "Fedora 30 and newer" section of INSTALL.md. They will run into the kernel lockdown challenge.
|
| INSTALL.md (diff) |
|
| src/cc/libbpf.c (diff) |
| introspection/bps.c (diff) |
| src/cc/libbpf (diff) |
| docs/kernel-versions.md (diff) |
| src/cc/compat/linux/virtual_bpf.h (diff) |
| src/cc/export/helpers.h (diff) |
Commit
0fa419a64e71984d42f107c210d3d3f0cc82d59a
by noreplydebian changelog for v0.11.0 tag (#2541)
the main changes from v0.10.0 to v0.11.0 tag: * Support for kernel up to 5.3 * Corresponding libbpf submodule release is v0.0.5 * Fix USDT issue with multi-threaded applications * Fixed the early return behavior of lookup_or_init * Support for nic hardware offload * Fixed and Enabled Travis CI * A lot of tools change with added new options, etc.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| debian/changelog (diff) |
Commit
76f31edfdbac03b02a4fc0bcd07fcd25c6dd5d03
by noreplysync with latest libbpf repo (#2545)
libbpf repo has a big sync from kernel side. Let us bring in to ensure bcc working fine and indeed it works fine.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| src/cc/libbpf (diff) |
| src/cc/compat/linux/virtual_bpf.h (diff) |
Commit
2d1497cde1cc9835f759a707b42dea83bee378b8
by yonghong-songRedefine asm_inline for Linux 5.4+, Fixes #2546 (#2547)
Here's the upstream commit that introduced `asm_inline`:
* https://github.com/torvalds/linux/commit/eb111869301e15b737315a46c913ae82bd19eb9d
Without this patch BCC fails with the following:
``` $ sudo /usr/share/bcc/tools/opensnoop In file included from /virtual/main.c:2: In file included from include/uapi/linux/ptrace.h:142: In file included from ./arch/x86/include/asm/ptrace.h:5: ./arch/x86/include/asm/segment.h:254:2: error: expected '(' after 'asm' alternative_io ("lsl %[seg],%[p]", ^ ./arch/x86/include/asm/alternative.h:240:2: note: expanded from macro 'alternative_io' asm_inline volatile (ALTERNATIVE(oldinstr, newinstr, feature) \ ^ include/linux/compiler_types.h:210:24: note: expanded from macro 'asm_inline' ^ ```
|
| src/cc/export/helpers.h (diff) |
|
| tools/gethostlatency.py (diff) |
| tools/gethostlatency_example.txt (diff) |
|
| README.md (diff) |
|
| tools/runqslower_example.txt (diff) |
|
| tools/drsnoop_example.txt (diff) |
|
| man/man8/tcpretrans.8 (diff) |
|
| src/python/bcc/__init__.py (diff) |
Commit
708f786e3784dc32570a079f2ed74c35731664ea
by noreplydocument the release info related to libbpf submodule (#2561)
Fix issue #2261. In INSTALL.md document that source code with libbpf submodule will be released as well for each bcc release in the future.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| INSTALL.md (diff) |
Commit
f04c6de5bfaa9137be09af0e6aaad040936bb148
by noreplyassign offset properly for btf DataSec (#2560)
The following test case failed: -bash-4.4$ cat test.py #!/usr/bin/python from bcc import BPF prog=""" BPF_ARRAY(array1, u64, 1); BPF_ARRAY(array2, u64, 1); """ b=BPF(text=prog, debug=0x20) -bash-4.4$ sudo ./test.py libbpf: Error loading BTF: Invalid argument(22) libbpf: magic: 0xeb9f version: 1 flags: 0x0 hdr_len: 24 ... [57] DATASEC array size=176 vlen=2 type_id=47 offset=0 size=88 type_id=49 offset=0 size=88 Invalid offset
Loading .BTF section failed -bash-4.4$
The reason is the data offset in DataSec VarInfo (e.g., type_id=47 offset=0 size=88) always have offset=0 since JIT won't do a final relocation for the record. Assign offset properly in bcc_btf before loading btf to the kernel. With this patch, test case can load btf properly. -bash-4.4$ cat test.py #!/usr/bin/python from bcc import BPF prog=""" BPF_ARRAY(array1, u64, 1); BPF_ARRAY(array2, u64, 1); """ b=BPF(text=prog, debug=0x20) -bash-4.4$ sudo ./test.py -bash-4.4$
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| src/cc/bcc_btf.cc (diff) |
Commit
c2a530b3adf91e5fe5886277e0f2abed4a77b8ea
by noreplysupport cgroup level tracing in trace.py (#2562)
This patch added cgroup based filtering in trace.py.
If a cgroup path is specified by the user, one cgroup array map will be added to the program: BPF_CGROUP_ARRAY(__cgroup, 1);
Each probe will have a filter like below: if (__cgroup.check_current_task(0) <= 0) { return 0; } to filter out any events not happening in the cgroup hierarchy as specified by the user.
The trace.py updated the `__cgroup` map with user provided cgroup path information before attaching bpf functions to events for probe function(s).
An example like below: $ trace.py -v -c /sys/fs/cgroup/system.slice/workload.service \ '__x64_sys_nanosleep' '__x64_sys_clone' PID TID COMM FUNC 3191578 3191583 BaseAgentEvents __x64_sys_nanosleep 3191578 3191579 FutureTimekeepr __x64_sys_clone 3191578 3191583 BaseAgentEvents __x64_sys_nanosleep 3191578 3191583 BaseAgentEvents __x64_sys_nanosleep since workload.service only contains one process 3191578.
Going up the hierarchy to system.slice will have more processes and hence more results: $ trace.py -v -c /sys/fs/cgroup/system.slice \ '__x64_sys_nanosleep' '__x64_sys_clone' PID TID COMM FUNC 591542 591677 dynoScribe __x64_sys_nanosleep 591610 591613 mcreplay2 __x64_sys_nanosleep 553252 553252 sleeperagent __x64_sys_nanosleep 591610 591613 mcreplay2 __x64_sys_nanosleep 553252 553252 sleeperagent __x64_sys_nanosleep
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| man/man8/trace.8 (diff) |
| tools/trace.py (diff) |
| tools/trace_example.txt (diff) |
|
| man/man8/shmsnoop.8 (diff) |
Commit
9b433f20ea0b5832c151e577268df66046c4bfe1
by tdecacqucpudist: create sufficiently large hash table to avoid missing tasks
This change fixes the cpudist tool to avoid issue when too many tasks are running.
Fixes #2567 -- cpudist stop working when there are too many fork
|
| tools/cpudist.py (diff) |
Commit
2dad4759a850bac6a0e3e1dd5fe35fc4c29419f0
by noreplyfix compilation errors with latest llvm trunk (#2575)
llvm commit https://reviews.llvm.org/D66795 changed the signature of function createMCAsmInfo(). - MCAsmInfo *createMCAsmInfo(const MCRegisterInfo &MRI, - StringRef TheTriple) const { + MCAsmInfo *createMCAsmInfo(const MCRegisterInfo &MRI, StringRef TheTriple, + const MCTargetOptions &Options) const {
Did similar adjustment in bcc to ensure compilation success.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| src/cc/bcc_debug.cc (diff) |
|
| src/cc/libbpf (diff) |
Commit
82f4302a651a6b46b0b090733d34af8201ecacb5
by noreplyintroduce map.lookup_or_try_init() (#2577)
Previously, map.lookup_or_init() may cause unexpected return from the function when lookup finds no element and init failed e.g. due to unlikely racy update or sometimes hash table full. This has caught surprise from many users. So, the commit https://github.com/iovisor/bcc/commit/ba64f031f2435aad5a85f8f37dbbe2a982cbbe6b attempts to remove the early return in map.lookup_or_init(). But then since NULL pointer could be returned, user will need to change their bpf program to check return value, otherwise, verifier will reject the program.
As described in the above, such an API behavior change may cause verifier failure and reject previously loadable bpf programs. bcc should try to maintain API stability, esp. to avoid subtle API behavior change.
This patch propose to restore the behavior of map.lookup_or_init() and introduce a new one map.lookup_or_try_init(), which will avoid unexpected return. The name is suggested by Alexei to reflect that init may fail. map.lookup_or_try_init() will be formally documented and used in bcc. A warning will be generated if map.lookup_or_init() is used. Documentation will make it clear that map.lookup_or_try_init() is preferred over map.lookup_or_init().
``` -bash-4.4$ sudo ./syscount.py /virtual/main.c:71:11: warning: lookup_or_init() may return from the function, use loopup_or_try_init() instead. val = data.lookup_or_init(&key, &zero); ^ 1 warning generated. Tracing syscalls, printing top 10... Ctrl+C to quit. ... ```
All uses in examples and tools are converted to use lookup_or_try_init(). Most tests are converted to use lookup_or_try_init() too except test_trace_maxactive.py and test_tracepoint.py to test lookup_or_init() functionality.
|
| tools/lib/ustat.py (diff) |
| tests/python/test_trace3.c (diff) |
| examples/usdt_sample/scripts/lat_avg.py (diff) |
| tests/lua/test_clang.lua (diff) |
| examples/tracing/strlen_count.py (diff) |
| tools/lib/ucalls.py (diff) |
| examples/networking/vlan_learning/vlan_learning.c (diff) |
| examples/networking/http_filter/http-parse-complete.c (diff) |
| examples/networking/tunnel_monitor/monitor.c (diff) |
| src/cc/frontends/clang/b_frontend_action.cc (diff) |
| tools/slabratetop.py (diff) |
| examples/lua/offcputime.lua (diff) |
| tests/python/test_trace2.c (diff) |
| tools/deadlock.c (diff) |
| tests/python/test_lru.py (diff) |
| tests/python/test_percpu.py (diff) |
| tests/python/test_trace4.py (diff) |
| tests/python/test_trace_maxactive.py (diff) |
| examples/cpp/TCPSendStack.cc (diff) |
| tools/biotop.py (diff) |
| examples/tracing/mallocstacks.py (diff) |
| tools/syscount.py (diff) |
| src/cc/export/helpers.h (diff) |
| examples/cpp/LLCStat.cc (diff) |
| docs/reference_guide.md (diff) |
| examples/tracing/task_switch.c (diff) |
| tests/cc/test_bpf_table.cc (diff) |
| docs/tutorial_bcc_python_developer.md (diff) |
| tests/python/test_tracepoint.py (diff) |
| examples/networking/distributed_bridge/tunnel.c (diff) |
| tools/filetop.py (diff) |
| examples/lua/task_switch.lua (diff) |
| examples/cpp/UseExternalMap.cc (diff) |
| tests/python/test_clang.py (diff) |
| tests/python/test_trace2.py (diff) |
| tests/python/test_license.py (diff) |
| tools/lib/uflow.py (diff) |
| tests/python/test_stat1.c (diff) |
| tools/lib/uobjnew.py (diff) |
Commit
58ff1b3647024bad1da4d20e9d0e99afa61fde51
by noreplyremove the warning for map.lookup_or_init() (#2581)
Commit 82f4302a651a ("introduce map.lookup_or_try_init()") introduced new API map.lookup_or_try_init(). A compile time warning is introduced if old map.lookup_or_init() is used to discourage the usage.
The API is still supported and documentation already recommends using the new one. So let us drop the warning.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| src/cc/frontends/clang/b_frontend_action.cc (diff) |
|
| docs/tutorial.md (diff) |
Commit
0429040559f9f324b0e1d3ed78b26e678499887f
by yonghong-songSupport attaching uprobe to offset (#2585)
* Support attaching uprobe to offset * C++ API support of attaching uprobe to offset * Update document of attach_uprobe() The document is taken from src/python/bcc/__init__.py:attach_upobe()
|
| docs/reference_guide.md (diff) |
| src/cc/api/BPF.cc (diff) |
| src/python/bcc/__init__.py (diff) |
| src/lua/bcc/bpf.lua (diff) |
| src/lua/bcc/sym.lua (diff) |
| src/cc/api/BPF.h (diff) |
Commit
9cede20f9ff19784bba4ef5473b396fa58b5302c
by yonghong-songtools/tcpretrans: add tracepoint support (#2574)
If tracepoint tcp:tcp_retransmit_skb exists (kernel version >= 4.15) we use tracepoint instead of kprobe for efficiency.
Co-authored-by: Runlong Lin <linrunlong@bytedance.com>
|
| tools/tcpretrans.py (diff) |
Commit
d4b3bf03d9c67324ff85f9d3c74b201b7e427615
by jolsaAdd libbcc-no-libbpf.so library
Which links libbpf.so dynamicaly, instead of its current static inclusion in libbcc.so.
The compilation needs to define CMAKE_USE_LIBBPF_PACKAGE variable to enable search for libbpf package. If the package is found it is used to build all the bcc libs.
The libbcc.so and libbcc_bpf.so (and their static versions) remain the same.
The new library libbcc-no-libbpf.so is built from all libcc.so sources including libbpf_bcc.so's sources: libbpf.c perf_reader.c and dynamically linked to libbpf.so library.
With libbcc-no-libbpf.so symbols are versioned, so there's no chance of being mixed:
Symbols exported from libbpf.so:
$ objdump -T /usr/lib64/libbpf.so | grep bpf_map_lookup_elem 0000000000006df0 g DF .text 000000000000006e LIBBPF_0.0.1 bpf_map_lookup_elem 0000000000006e60 g DF .text 0000000000000076 LIBBPF_0.0.2 bpf_map_lookup_elem_flags
Symbol needed by libbcc-no-libbpf.so:
$ objdump -T /opt/bcc/lib64/libbcc-no-libbpf.so | grep bpf_map_lookup_elem 0000000000000000 DF *UND* 0000000000000000 LIBBPF_0.0.1 bpf_map_lookup_elem
Symbols exported by current libbcc.so:
$ objdump -T /opt/bcc/lib64/libbcc.so | grep bpf_map_lookup_elem 00000000023ad843 g DF .text 0000000000000082 Base bpf_map_lookup_elem_flags 00000000023ad7d3 g DF .text 0000000000000070 Base bpf_map_lookup_elem
Besides that it's better to share common source of libbpf code, it also prevents issues when having application that links to libbpf and libbcc, where you could end up conflicting functions and segfaults if those 2 libbpf libs are not on the same version.
All installed libraries now:
total 259096 lrwxrwxrwx. 1 root root 15 Nov 8 15:24 libbcc_bpf.so -> libbcc_bpf.so.0 lrwxrwxrwx. 1 root root 20 Nov 8 15:24 libbcc_bpf.so.0 -> libbcc_bpf.so.0.11.0 -rwxr-xr-x. 1 root root 453416 Nov 11 17:03 libbcc_bpf.so.0.11.0 lrwxrwxrwx. 1 root root 21 Nov 8 15:24 libbcc-no-libbpf.so -> libbcc-no-libbpf.so.0 lrwxrwxrwx. 1 root root 26 Nov 8 15:24 libbcc-no-libbpf.so.0 -> libbcc-no-libbpf.so.0.11.0 -rwxr-xr-x. 1 root root 132276312 Nov 11 17:04 libbcc-no-libbpf.so.0.11.0 lrwxrwxrwx. 1 root root 11 Nov 8 15:24 libbcc.so -> libbcc.so.0 lrwxrwxrwx. 1 root root 16 Nov 8 15:24 libbcc.so.0 -> libbcc.so.0.11.0 -rwxr-xr-x. 1 root root 132579280 Nov 11 17:04 libbcc.so.0.11.0 drwxr-xr-x. 2 root root 23 Nov 11 21:49 pkgconfig
Signed-off-by: Jiri Olsa jolsa@kernel.org
|
| CMakeLists.txt (diff) |
| cmake/FindLibBpf.cmake |
| src/cc/CMakeLists.txt (diff) |
Commit
19c625e65f6726913ef435b1882d50da49bf43e0
by jolsaLink test_libbcc directly with libbcc.so
Linking with bcc-shared will use all the libraries in bcc-shared which compose libbcc, instead of libbcc.so dynamic link.
Signed-off-by: Jiri Olsa jolsa@kernel.org
|
| tests/cc/CMakeLists.txt (diff) |
Commit
7ec8bde336af400fc691dba864b62e5733e82bb3
by jolsaAdd test_libbcc_no_libbpf test
It's the same code as for test_libbcc test, but linked with libbcc-no-libbpf.so library.
Added LIBBCC_NAME macro to be used in dynamic loader test where we need to provide the library name.
Signed-off-by: Jiri Olsa jolsa@kernel.org
|
| tests/cc/CMakeLists.txt (diff) |
| tests/cc/test_c_api.cc (diff) |
|
| docs/reference_guide.md (diff) |
Commit
992e482b5d06c58888b3821a96a41e48aff678d0
by noreplysync with latest libbpf (#2594)
The following helpers are sync'ed into bcc and will be available in linux 5.5. bpf_probe_read_kernel bpf_probe_read_kernel_str bpf_probe_read_user bpf_probe_read_user_str
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| src/cc/export/helpers.h (diff) |
| src/cc/libbpf (diff) |
| src/cc/libbpf.c (diff) |
| src/cc/compat/linux/virtual_bpf.h (diff) |
| docs/kernel-versions.md (diff) |
| introspection/bps.c (diff) |
Commit
ccf8261e89eede7b6c9c949c1913610fe1bd9a5c
by yonghong-songadd BPF::init_usdt function to init a single USDT so folks can handle partial init failure of list of USDTs.
modify BPF::init so that failure doesn't leave the BPF object in a broken state such that subsequent inits will also fail
|
| docs/reference_guide.md (diff) |
| src/cc/api/BPF.cc (diff) |
| src/cc/api/BPF.h (diff) |
| tests/cc/test_usdt_probes.cc (diff) |
|
| man/man8/compactsnoop.8 |
| tools/old/compactsnoop.py |
| tools/compactsnoop_example.txt |
| tools/compactsnoop.py |
| tests/python/test_tools_smoke.py (diff) |
| snapcraft/snapcraft.yaml (diff) |
| README.md (diff) |
|
| docs/reference_guide.md (diff) |
|
| docs/kernel-versions.md (diff) |
Commit
6ee245bd9d2d548bb82437a7a32740e7570737b8
by yonghong-songfix a bug in mountsnoop.py with 4.17+ kernels
in 4.17+ kernels, syscall parameters are wrapped in the first parammeter in pt_regs. So put the 5th parameter in the syscall__ parameter list so it can be handled properly by the rewriter.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| tools/mountsnoop.py (diff) |
|
| src/cc/bcc_elf.h (diff) |
Commit
ac00ac5d7fec86524ff815360d0cda2ec583cf24
by yonghong-songAdd lockstat tool
Adding lockstat tool to trace kernel mutex lock events and display locks statistics and displays following data:
Caller Avg Spin Count Max spin Total spin psi_avgs_work+0x2e 3675 5 5468 18379 flush_to_ldisc+0x22 2833 2 4210 5667 n_tty_write+0x30c 3914 1 3914 3914 isig+0x5d 2390 1 2390 2390 tty_buffer_flush+0x2a 1604 1 1604 1604 commit_echoes+0x22 1400 1 1400 1400 n_tty_receive_buf_common+0x3b9 1399 1 1399 1399
Caller Avg Hold Count Max hold Total hold flush_to_ldisc+0x22 42558 2 76135 85116 psi_avgs_work+0x2e 14821 5 20446 74106 n_tty_receive_buf_common+0x3b9 12300 1 12300 12300 n_tty_write+0x30c 10712 1 10712 10712 isig+0x5d 3362 1 3362 3362 tty_buffer_flush+0x2a 3078 1 3078 3078 commit_echoes+0x22 3017 1 3017 3017
Every caller to using kernel's mutex is displayed on every line.
First portion of lines show the lock acquiring data, showing the amount of time it took to acquired given lock.
'Caller' - symbol acquiring the mutex 'Average Spin' - average time to acquire the mutex 'Count' - number of times mutex was acquired 'Max spin' - maximum time to acquire the mutex 'Total spin' - total time spent in acquiring the mutex
Second portion of lines show the lock holding data, showing the amount of time it took to hold given lock.
'Caller' - symbol holding the mutex 'Average Hold' - average time mutex was held 'Count' - number of times mutex was held 'Max hold' - maximum time mutex was held 'Total hold' - total time spent in holding the mutex
This works by tracing mutex_lock/unlock kprobes, udating the lock stats in maps and processing them in the python part.
Examples: lockstats # trace system wide lockstats -d 5 # trace for 5 seconds only lockstats -i 5 # display stats every 5 seconds lockstats -p 123 # trace locks for PID 123 lockstats -t 321 # trace locks for PID 321 lockstats -c pipe_ # display stats only for lock callers with 'pipe_' substring lockstats -S acq_count # sort lock acquired results on acquired count lockstats -S hld_total # sort lock held results on total held time lockstats -S acq_count,hld_total # combination of above lockstats -n 3 # display 3 locks lockstats -s 3 # display 3 levels of stack
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
|
| snapcraft/snapcraft.yaml (diff) |
| tools/lockstat.py |
| tests/python/test_tools_smoke.py (diff) |
| tools/offwaketime.py (diff) |
| man/man8/lockstat.8 |
| tools/lockstat_example.txt |
| README.md (diff) |
|
| src/cc/bcc_exception.h (diff) |
Commit
3032347541d8b121598e220ec782aceb642ebf55
by yonghong-songMake StatusTuple code and msg methods const (#2603)
I ran into this while trying to write a method that takes a const StatusTuple reference, these methods should be marked const. I also fixed an unnecessary string copy in msg.
|
| src/cc/bcc_exception.h (diff) |
Commit
f68d818085c2c26a88606d4976474a08cfe7c9ee
by yonghong-songupdate INSTALL.md for new llvm source compilation
clang/llvm has moved from old svn with git mirror to github based source control. The new github address is https://github.com/llvm/llvm-project which includes clang, llvm and other related projects.
This patch updated instruction how to build clang/llvm library with new llvm-project setup.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| INSTALL.md (diff) |
Commit
65885f34d5ea1acb6a014615f1eea08fc6c5514d
by yonghong-songtools/runqslower.py: Fix raw tracepoint code
Closes: #2588
It is was observed that many unrelated process names were reported for the same pid.
The cause of the bug was the use of bpf_get_current_comm() which operates on the current process which might already be different than the 'next' task we captured. The fix is to use bpf_probe_read_str() instead.
Also removing dead code related to tgid extraction which is not used at all.
|
| tools/runqslower.py (diff) |
|
| docs/kernel-versions.md (diff) |
Commit
149c1c8857652997622fc2a30747a60e0c9c17dc
by yonghong-songAdd map-in-map support
Add BPF_MAP_TYPE_HASH_OF_MAPS and BPF_MAP_TYPE_HASH_OF_MAPS supports in bcc. Two new constructs below are introduced to bpf program: BPF_HASH_OF_MAPS(map_name, "inner_map_name", max_entries) BPF_ARRAY_OF_MAPS(map_name, "inner_map_name", max_entries) In the above, "inner_map_name" is for metadata purpose and there must be a map defined in bpf program with map name "inner_map_name".
Both python and C++ APIs are added.
For python, a new Table API get_fd() is introduced to get the fd of a map so that the fd can be used by a map-in-map do update. The get_fd() is already exposed as API function in C++. For C++, without get_fd(), we will need to templatize basic functions like update_value etc, which I feed too heavy weight. Because of C++ using get_fd() mechanism, so I exposed similar API on python side for parity reason.
For map-in-map, the inner map lookup/update/delete won't have explicit map names. Considering map-in-map is not used very frequently, I feel looking primitive bpf_map_{lookup,update,delete}_elem() probably okay, so I did not create any new bcc specific constructs for this purpose.
Added both C++ and python test cases to show how to use the above two new map type in bcc.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| tests/cc/CMakeLists.txt (diff) |
| src/cc/export/helpers.h (diff) |
| src/cc/api/BPFTable.cc (diff) |
| tests/python/test_map_in_map.py |
| tests/cc/test_map_in_map.cc |
| src/cc/bpf_module.h (diff) |
| src/cc/api/BPF.h (diff) |
| src/cc/table_storage.h (diff) |
| docs/reference_guide.md (diff) |
| src/cc/api/BPFTable.h (diff) |
| src/cc/bpf_module.cc (diff) |
| src/cc/api/BPF.cc (diff) |
| src/cc/frontends/clang/b_frontend_action.h (diff) |
| src/cc/frontends/clang/b_frontend_action.cc (diff) |
| src/python/bcc/table.py (diff) |
Commit
a1a04f49ac736bc0ddd341258b8a56f2a25d30c5
by yonghong-songDo not traverse attributes during JSON generation (Fixes #2605)
Previously, __attribute__((aligned(sizeof(...)))) would cause the type inside sizeof() to be appended after the JSON type information for the struct in some clang versions, generating invalid JSON. Inhibit attribute traversal, since we only want to visit the fields.
|
| src/cc/json_map_decl_visitor.cc (diff) |
Commit
90f2086c8dd073792b0be382944440e3d0f1977f
by yonghong-songdo not use BPF_F_REUSE_STACKID incorrectly
Do not use BPF_F_REUSE_STACKID if the stack id is used together with process specific info like pid/tgid/comm. Using BPF_F_REUSE_STACKID may cause stack id pointing to a different stack later on.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| tools/stackcount.py (diff) |
| tools/deadlock.c (diff) |
| tools/trace.py (diff) |
| tools/memleak.py (diff) |
| tools/old/profile.py (diff) |
| tools/stacksnoop.lua (diff) |
| tools/wakeuptime.py (diff) |
|
| tools/lockstat.py (diff) |
Commit
feadea6d789f54e304e9c2f570ed87299e6f4e5e
by yonghong-songSupport a BPF program larger than BPF_MAXINSNS
A privileged user can load bpf program whose size is at most BPF_COMPLEXITY_LIMIT_INSNS (which is larger than BPF_MAXINSNS) in Linux 5.3 (https://github.com/torvalds/linux/commit/c04c0d2b968ac45d6ef020316808ef6c82325a82). Currently, however, `bcc_prog_load_xattr()` return error if a bpf program size is larger than BPF_MAXINSNS before loading the program. To cope with this, change the function so that first trying to load a bpf program and print an error message if bpf_program_load_xattr() fails with -E2BIG. This strategy is the same as libbpf's `load_program` (https://github.com/libbpf/libbpf/blob/9ef191ea7dca6815e75dab341f2f7a346d979c66/src/libbpf.c#L3792) The Error message should use BPF_COMPLEXITY_LIMIT_INSNS when appropriate, but it is not defined in uapi headers yet.
Signed-off-by: Masanori Misono <m.misono760@gmail.com>
|
| src/cc/libbpf.c (diff) |
Commit
556d9ec9ca0c142d38b08c5d93420ab06df4e6e0
by yonghong-songUse integer types for enums in JSON (Fixes #2615)
The JSON generated for enums wasn't being handled, and caused exceptions. Since the enum values aren't needed (and would've been useless without the associated numerical values, anyway), just use the matching integer type instead.
|
| tests/python/test_clang.py (diff) |
| src/cc/json_map_decl_visitor.cc (diff) |
Commit
e09116d3e777782cfdf1a129f8ca8f2981505fb2
by yonghong-songUse libbpf-static instead of libbpf-debugsource for CMAKE_USE_LIBBPF_PACKAGE
Currently when building with CMAKE_USE_LIBBPF_PACKAGE we assume that 'source' package is available to build libbcc_bpf libraries.
However It turned on that using debugsource (in Fedora) package is not suitable or even possible, so we are switching to use the libbpf-static package instead.
Adding libbpf-static package detection and removing source package detection.
Using ar to extract objects from archive and linking them with both libbcc_bpf.so and libbcc_bpf.a.
Using always uapi headers from the latest libbpf Github repo, because there are not packaged, but they are backwards compatible, so it's no problem to have older libbpf package with newer uapi headers.
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
|
| src/cc/CMakeLists.txt (diff) |
| cmake/FindLibBpf.cmake (diff) |
|
| man/man8/filetop.8 (diff) |
Commit
0bca64555ab30b37d23f6898f2eec4528d4d4ec7
by yonghong-songman: fix the explanation of filename
Below filenames currently come from dentry->d_name.name * btrfsslower * ext4slower * fileslower * nfsslower * xfsslower * zfsslower
Signed-off-by: Kenta Tada <Kenta.Tada@sony.com>
|
| man/man8/ext4slower.8 (diff) |
| man/man8/zfsslower.8 (diff) |
| man/man8/btrfsslower.8 (diff) |
| man/man8/fileslower.8 (diff) |
| man/man8/xfsslower.8 (diff) |
| man/man8/nfsslower.8 (diff) |
|
| tools/mysqld_qslower.py (diff) |
Commit
b040635d86fa7eba195ec3f43f91a6f72806fb05
by yonghong-songman: fix a reference to runqlat in runqslower man page
The runqslower man page obviously derived from the man page of runqlat. It seems that a reference to runqlat in the NAME section has been overlooked.
|
| man/man8/runqslower.8 (diff) |
Commit
71f9c2a7469cc73bdba4b3b9f49991930ac572f9
by yonghong-songrename tool lockstat.py to klockstat.py
The current lockstat.py is tracing three kernel functions mutex_lock_enter(), mutex_unlock_enter(), mutex_lock_return() for kernel locking statistics.
There are some other efforts trying to get user lock stats by tracing e.g. pthread locking primitives. For example, Sasha Goldshtein's linux-tracing-workshop https://github.com/goldshtn/linux-tracing-workshop is referenced in bcc/docs/tutorial_bcc_python_developer.md. It has a tool called lockstat.py which traces pthread_mutex_init to collect some lock statistics for userspace locks.
In bcc, in the past, we also had an effort to gather userspace lock statistics with the same name lockstat.py. https://github.com/iovisor/bcc/pull/1268
In the future, bcc could have a lockstat tool tracing userspace locks. So let us rename the current lockstat.py to klockstat.py to clearly express its scope.
|
| snapcraft/snapcraft.yaml (diff) |
| tools/lockstat.py |
| man/man8/lockstat.8 |
| tools/lockstat_example.txt |
| tools/klockstat_example.txt |
| tools/klockstat.py |
| man/man8/klockstat.8 |
| README.md (diff) |
| tests/python/test_tools_smoke.py (diff) |
Commit
e7ddcbcc5e939ac91e16b42fca303c31816590a5
by yonghong-songremove inproper usage of BPF_F_REUSE_STACKID in examples
When the application bundles stack id with process specific info (like pid, comm, etc.), BPF_F_REUSE_STACKID should not be used as it may associate wrong stack with processes.
This patch corrected several such uses in examples/ directory.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| examples/lua/memleak.lua (diff) |
| examples/tracing/stacksnoop.py (diff) |
| examples/tracing/mallocstacks.py (diff) |
| examples/lua/offcputime.lua (diff) |
|
| tools/trace.py (diff) |
| man/man8/trace.8 (diff) |
| tools/trace_example.txt (diff) |
Commit
5cf529eeb448fa5422f305727ee4be7d01ebf391
by yonghong-songtools/trace.py: add msg filter of event
In the normal develop, will produce many event on the same tracepoint, like do_sys_open, a executable program will open many files but developer only has interesting on the specific file. So this filter will help developer to get their interesting msg
Signed-off-by: tty5 <tty.fqq@gmail.com>
|
| tools/trace_example.txt (diff) |
| man/man8/trace.8 (diff) |
| tools/trace.py (diff) |
Commit
f9f1050f0d61e56ed43df0f1338a30389bfcc2ba
by yonghong-songfix a compilation error with latest llvm 10
Two issues: First, the recent llvm commit "[Alignment][NFC] CreateMemSet use MaybeAlign" (https://reviews.llvm.org/D71213) changed IR/IRBuilder.h CreateMemSet() signature which caused the following compilation error: [ 16%] Building CXX object src/cc/frontends/b/CMakeFiles/b_frontend.dir/codegen_llvm.cc.o /home/yhs/work/bcc/src/cc/frontends/b/codegen_llvm.cc: In member function ‘virtual ebpf::StatusTuple ebpf::cc::CodegenLLVM::visit_table_index_expr_node(ebpf::cc::TableIndexExprNode*)’: /home/yhs/work/bcc/src/cc/frontends/b/codegen_llvm.cc:824:96: error: no matching function for call to ‘llvm::IRBuilder<>::CreateMemSet(llvm::Value*&, llvm::ConstantInt*, llvm::ConstantInt*, int)’ B.CreateMemSet(leaf_ptr, B.getInt8(0), B.getInt64(n->table_->leaf_id()->bit_width_ >> 3), 1); ^ .... /home/yhs/work/llvm-project/llvm/build/install/include/llvm/IR/IRBuilder.h:460:13: note: candidate: llvm::CallInst* llvm::IRBuilderBase::CreateMemSet(llvm::Value*, llvm::Value*, llvm::Value*, llvm::MaybeAlign, bool, llvm::MDNode*, llvm::MDNode*, llvm::MDNode*) CallInst *CreateMemSet(Value *Ptr, Value *Val, Value *Size, MaybeAlign Align, ^~~~~~~~~~~~ /home/yhs/work/llvm-project/llvm/build/install/include/llvm/IR/IRBuilder.h:460:13: note: no known conversion for argument 4 from ‘int’ to ‘llvm::MaybeAlign’
Second, the commit "[OpenMP][NFCI] Introduce llvm/IR/OpenMPConstants.h" (https://reviews.llvm.org/D69853) introduced a new library "FrontendOpenMP" which is used by clang Parser, and caused the following errors: [ 99%] Building CXX object tests/cc/CMakeFiles/test_libbcc.dir/test_hash_table.cc.o /home/yhs/work/llvm-project/llvm/build/install/lib/libclangParse.a(ParseOpenMP.cpp.o): In function `clang::Parser::ParseOpenMPDeclareReductionDirective(clang::AccessSpecifier)': ParseOpenMP.cpp:(.text._ZN5clang6Parser36ParseOpenMPDeclareReductionDirectiveENS_15AccessSpecifierE+0x86): undefined reference to `llvm::omp::getOpenMPDirectiveName(llvm::omp::Directive)'
This patch fixed both issues and bcc can compile with latest llvm 10.
|
| src/cc/frontends/b/codegen_llvm.cc (diff) |
| cmake/clang_libs.cmake (diff) |
|
| introspection/CMakeLists.txt (diff) |
| src/cc/libbpf (diff) |
| src/cc/compat/linux/virtual_bpf.h (diff) |
Commit
368a5b0714961953f3e3f61607fa16cb71449c1b
by yonghong-songdebian changelog for v0.12.0 tag
the main changes from v0.11.0 to v0.12.0 tag: * Support for kernel up to 5.4 * klockstat tool to track kernel mutex lock statistics * cmake option CMAKE_USE_LIBBPF_PACKAGE to build a bcc shared library linking with distro libbpf_static.a * new map.lookup_or_try_init() API to remove hidden return in map.lookup_or_init() * BPF_ARRAY_OF_MAPS and BPF_HASH_OF_MAPS support * support symbol offset for uprobe in both C++ and python API, kprobe already has the support * bug fixes for trace.py, tcpretrans.py, runqslower.py, etc.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| debian/changelog (diff) |
Commit
2283996f0acd80c304541540570825da7fae77d9
by yonghong-songFix s390 kprobes support
Ever since Linux kernel commit aa0d6e70d, kprobes on s390 could no longer be found due to a change in symbol names. Symptom: $ ./tools/execsnoop.py cannot attach kprobe, probe entry may not exist [...]
Signed-off-by: Stefan Raspl <raspl@linux.ibm.com>
|
| src/python/bcc/__init__.py (diff) |
|
| tools/filetop.py (diff) |
|
| man/man8/biolatency.8 (diff) |
|
| man/man8/klockstat.8 (diff) |
| tools/klockstat.py (diff) |
Commit
0aca2c71c9b9e6b3d3335b6df288ad01a09c3ed6
by yonghong-songRemove kretprobe__ prefix from program names
Such prefixes are currently removed for kprobes, tracepoints, and raw tracepoints, but not for kretprobes. This commit removes it for kretprobe as well, for consistency.
Signed-off-by: Paul Chaignon <paul.chaignon@orange.com>
|
| src/cc/libbpf.c (diff) |
Commit
b2aa29fa3269ec54b2c4d95a55559deb4c32b7b6
by yonghong-songtools: cgroup filtering in execsnoop/opensnoop
Add a new option --cgroupmap in execsnoop and opensnoop to only display results from processes that belong to one of the cgroups whose id, returned by bpf_get_current_cgroup_id(), is in a pinned BPF hash map.
Examples of commands: # opensnoop --cgroupmap /sys/fs/bpf/test01 # execsnoop --cgroupmap /sys/fs/bpf/test01
Cgroup ids can be discovered in userspace by the system call name_to_handle_at(); an example of C program doing that is available in examples/cgroupid/cgroupid.c.
More complete documentation is added in docs/filtering_by_cgroups.md
The documentation is independent from Kubernetes. However, my goal is to use this feature in Kubernetes: I am preparing to use this in Inspektor Gadget to select specific Kubernetes pods, depending on a Kubernetes label selector. Kubernetes pods matching the label selector can come and go during the execution of the bcc tools; Inspektor Gadget is updating the BPF hash map used by the bcc tools accordingly.
|
| tools/execsnoop_example.txt (diff) |
| tools/opensnoop_example.txt (diff) |
| tools/opensnoop.py (diff) |
| examples/cgroupid/cgroupid.c |
| examples/cgroupid/Dockerfile |
| .gitignore (diff) |
| examples/cgroupid/Makefile |
| docs/filtering_by_cgroups.md |
| tools/execsnoop.py (diff) |
|
| src/cc/CMakeLists.txt (diff) |
| introspection/CMakeLists.txt (diff) |
| src/cc/libbpf (diff) |
|
| tools/trace.py (diff) |
Commit
977a7e3a568c4c929fabeb4a025528d9b6f1e84c
by yonghong-songchange version.cmake to check all tags
Fix issue #2666
Currently, in master where latest tag is v0.12.0, the build still says is it v0.11.0.
[ben@centos bcc]$ cd build/ [ben@centos build]$ cmake .. -DCMAKE_INSTALL_PREFIX=/usr -- Latest recognized Git tag is v0.11.0
The reason is the git_describe by default only checks annotated tag while tag v0.12.0 is tagged through github release process which just tags whatever the top of the master.
Making git_describe to check all tags fixed the issue.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| cmake/version.cmake (diff) |
Commit
4f0a887a1530c716190454b824a7f003fde8b9e8
by yonghong-songman: fix required kernel version in man pages
Several man pages state that Linux 4.5 is required because the tool relies on the bpf_perf_event_output helper. However, bpf_perf_event_output was introduced in Linux 4.4.
In addition, mountsnoop requires Linux 4.8 because it now uses the bpf_get_current_task helper.
Signed-off-by: Paul Chaignon <paul.chaignon@orange.com>
|
| man/man8/syncsnoop.8 (diff) |
| man/man8/killsnoop.8 (diff) |
| man/man8/bashreadline.8 (diff) |
| man/man8/filelife.8 (diff) |
| man/man8/statsnoop.8 (diff) |
| man/man8/mountsnoop.8 (diff) |
| man/man8/biosnoop.8 (diff) |
| man/man8/drsnoop.8 (diff) |
| man/man8/opensnoop.8 (diff) |
| man/man8/gethostlatency.8 (diff) |
|
| src/cc/CMakeLists.txt (diff) |
Commit
dc336aa42dee99e3b38b8c760c39cc8fafe9deca
by yonghong-songPackage static archives, closes #1938
This should help embed libbcc into bpftrace:
* https://github.com/iovisor/bpftrace/issues/342
As well as other tools like ebpf_exporter, so that there is no longer a requirement to have a particular version libbcc installed.
|
| src/cc/CMakeLists.txt (diff) |
Commit
5098c9dd2538d6256a10f1a67a36ebc867549e7f
by yonghong-songfix test_map_in_map.cc compilation error
fix issue #2679 where test_map_in_map.cc has a compilation error on ppc64le due to conflicting type __u64. Let us just remove the typedef.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| tests/cc/test_map_in_map.cc (diff) |
Commit
e47f9d0294a23fe125e577a5649c936ea7d6f814
by yonghong-songsanitize btf VAR and DATASEC types
bcc does not use these types yet. Let us sanitize them with int/void-pointer types so old kernels can continue to work with latest llvm compiler.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| src/cc/bcc_btf.cc (diff) |
Commit
db8264413135c808bd5d530537e9cccabf6186a3
by yonghong-songtools/runqslower.py: Option for --pid or --tid (#2635)
* tools/runqslower.py: Option for --pid or --tid
Closes: #2607
Option for --pid or --tid tracing. Enable group leader level tracing. * --pid <pid>: will trace every task that has <pid> as group leader. Meaning it will trace the parent and its direct children. * --tid <tid>: will trace the given thread * Reporting TID instead of PID in the report column. * Update the example file to reflect the TID/PID change
|
| tools/runqslower_example.txt (diff) |
| man/man8/runqslower.8 (diff) |
| tools/runqslower.py (diff) |
Commit
c6b287ca4ca30de94d1082ebed0a7330796b717a
by yonghong-songsupport BPF_MAP_TYPE_SK_STORAGE map
kernel sk local storage is introduced at 5.2. https://github.com/torvalds/linux/commit/6ac99e8f23d4b10258406ca0dd7bffca5f31da9d this patch supports BPF_MAP_TYPE_SK_STORAGE in bcc. tested C++ user space APIs and loading of the bpf programs using helpers map.sk_storage_get() and map.sk_storage_delete().
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| src/cc/export/helpers.h (diff) |
| tests/cc/CMakeLists.txt (diff) |
| src/cc/api/BPF.h (diff) |
| src/cc/api/BPFTable.h (diff) |
| src/cc/frontends/clang/b_frontend_action.cc (diff) |
| tests/cc/test_sk_storage.cc |
|
| tools/offcputime.py (diff) |
|
| LINKS.md (diff) |
Commit
1a780e97ff6678583c5398230c579cc81cfbf2bb
by yonghong-songrewriter: Fix tracking of pointers with several indirections
The rewriter tracks, with nb_derefs, the number of indirections of external pointers, to rewrite only the appropriate dereference into a call to bpf_probe_read.
In ProbeChecker, however, nb_derefs has a different meaning: it counts the number of dereferences encountered. This difference resulted in an error when ProbeChecker is traversing the right-hand side of an assignment. This commit fixes the error and adds tests for the two cases of assignments: when the right-hand side is an external pointer with several indirection levels and when it is a call to a function returning an external pointer with several indirection levels.
This commit also changes ProbeSetter and assignsExtPtr to count dereferences instead of addrof in an effort to use nb_derefs more consistently across the code to mean "number of dereferences needed to get to the external pointer".
Signed-off-by: Paul Chaignon <paul.chaignon@orange.com>
|
| src/cc/frontends/clang/b_frontend_action.cc (diff) |
| tests/python/test_clang.py (diff) |
|
| INSTALL.md (diff) |
Commit
590ac9dcb67aff673b38855b76eaf45b5269fd41
by yonghong-songUbuntu Eon build dependencies and version numbers
- Add updated list of dependencies to build on Ubuntu Eon (19.10) - Add Ubuntu version numbers for increased clarity - Capitalize release names to match official branding
|
| INSTALL.md (diff) |
|
| src/cc/api/BPFTable.cc (diff) |
|
| man/man8/filetop.8 (diff) |
| tools/capable.py (diff) |
| man/man8/runqlen.8 (diff) |
| tools/compactsnoop_example.txt (diff) |
| src/cc/bcc_elf.h (diff) |
| tests/python/include/folly/tracing/StaticTracepoint-ELF.h (diff) |
| tools/profile.py (diff) |
| tools/runqlen_example.txt (diff) |
| tools/old/profile.py (diff) |
| examples/cpp/TCPSendStack.cc (diff) |
| tools/reset-trace_example.txt (diff) |
| tools/tcpstates_example.txt (diff) |
| tools/cachetop.py (diff) |
| tools/inject.py (diff) |
| src/cc/export/helpers.h (diff) |
| tools/nfsslower.py (diff) |
| tools/solisten_example.txt (diff) |
| tools/tcplife.lua (diff) |
| tools/compactsnoop.py (diff) |
| examples/networking/http_filter/http-parse-complete.py (diff) |
| man/man8/dbslower.8 (diff) |
| src/cc/frontends/b/codegen_llvm.cc (diff) |
| src/cc/frontends/b/parser.yy (diff) |
| tools/tcpstates.py (diff) |
| src/cc/libbpf.h (diff) |
| tools/tcplife.py (diff) |
| tools/tcpsubnet_example.txt (diff) |
| src/cc/frontends/p4/compiler/ebpfTable.py (diff) |
| tools/reset-trace.sh (diff) |
| tools/tcpaccept.py (diff) |
| tools/tcplife_example.txt (diff) |
| tests/lua/luaunit.lua (diff) |
| tools/offwaketime.py (diff) |
| docs/reference_guide.md (diff) |
| man/man8/compactsnoop.8 (diff) |
| man/man8/criticalstat.8 (diff) |
| examples/networking/http_filter/http-parse-complete.c (diff) |
| src/cc/libbpf.c (diff) |
| tools/criticalstat_example.txt (diff) |
| examples/tracing/dddos.py (diff) |
| tools/offcputime.py (diff) |
| src/cc/api/BPF.cc (diff) |
| tools/tcptracer_example.txt (diff) |
| tools/klockstat.py (diff) |
| tests/cc/test_perf_event.cc (diff) |
|
| src/cc/bcc_debug.cc (diff) |
|
| docs/kernel-versions.md (diff) |
Commit
18e0991f7057922b4735de013e1dc06f6260f8f3
by yonghong-songSecure Boot: physical keypress to disable lockdown
Ubuntu 19.10 with secure boot enabled doesn't allow the kernel lockdown to be lifted by echo, even from root: ``` # echo 1 > /proc/sys/kernel/sysrq # echo x > /proc/sysrq-trigger ``` dmesg says: ``` This sysrq operation is disabled from userspace. ```
I pressed Alt-PrtScr-x and that worked: ``` sysrq: Disabling Secure Boot restrictions Lifting lockdown ```
I can now run eBPF tools, such as execsnoop-bpfcc.
|
| FAQ.txt (diff) |
Commit
670aad2e7fd9e8f21db56ee188cbb4ab010f91c0
by yonghong-songsanitize BTF_KIND_FUNC
The llvm patch https://reviews.llvm.org/D71638 extends BTF_KIND_FUNC to include scope of the function, static, global and extern, with btf_type->info vlen encoding since vlen is always 0 before the extension.
This patch did the sanitization so that the bcc with latest llvm can still work on older kernels.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| src/cc/bcc_btf.cc (diff) |
| src/cc/bcc_btf.h (diff) |
Commit
071eef6b1571f23be6f0fc03787523cb06b70659
by yonghong-songsync with latest libbpf repo
sync with latest libbpf repo upto the following commit: https://github.com/libbpf/libbpf/commit/868739519894fbf2cdb81f1f9222f1b665670096
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| docs/kernel-versions.md (diff) |
| src/cc/libbpf (diff) |
| src/cc/compat/linux/virtual_bpf.h (diff) |
| src/cc/libbpf.c (diff) |
| introspection/bps.c (diff) |
Commit
bbafe998921792839d5c09f76705dd30849140ba
by yonghong-songFix CentOS 6 support.
CentOS 6 support was added in #1504 and inadvertently reverted in #1763 leading to builds failing due to undefined reference to "clock_gettime".
To re-add support for building on CentOS 6 and keep binary size down, only add librt to the list of target_link_libraries to allow "clock_gettime" to be resolved.
|
| introspection/CMakeLists.txt (diff) |
Commit
304d95cf48c256cbf5bb27d68193db4f01afb9e8
by yonghong-songbpflist: list only real bpf objects
The regular expression '.*bpf-(\\w+)' used to grep for bpf objects would also list regular files. For example, a process like `vim /tmp/bpf-woo` would be listed in the output and the type of the BPF object will be 'woo'. Fix this by correcting the regular expression.
Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
|
| tools/bpflist.py (diff) |
Commit
90937ce0237f72ccf18142296a6d5c97cc823791
by yonghong-songbpflist: use smarter print format
BPF object type can be wider than 8 characters, e.g., for the "raw-tracepoint" type. Compute the printing format automatically based on the maximum length of BPF objects to be listed.
Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
|
| tools/bpflist.py (diff) |
Commit
4f0c29ea2c072c29e9ed064a1494f333e2378cf3
by yonghong-songfix llvm compilation error
The following changes from llvm 10 https://github.com/llvm/llvm-project/commit/6fdd6a7b3f696972edc244488f59532d05136a27#diff-37c83c70858df19cb097e36b13b7c112 changed MCDisassembler::getInstruction() signature. Do the corresponding change in bcc_debug.cc to fix the issue.
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| src/cc/bcc_debug.cc (diff) |
|
| docs/kernel-versions.md (diff) |
Commit
dce8e9daf59f44dec4e3500d39a82a8ce59e43ba
by yonghong-songsync with latest libbpf repo
sync libbpf submodule upto the following commit: commit 033ad7ee78e8f266fdd27ee2675090ccf4402f3f Author: Andrii Nakryiko <andriin@fb.com> Date: Fri Jan 17 16:22:23 2020 -0800
sync: latest libbpf changes from kernel
Signed-off-by: Yonghong Song <yhs@fb.com>
|
| docs/kernel-versions.md (diff) |
| src/cc/compat/linux/virtual_bpf.h (diff) |
| src/cc/libbpf (diff) |
| src/cc/libbpf.c (diff) |
|
| INSTALL.md (diff) |
|
| tests/cc/test_c_api.cc (diff) |
| .github/workflows/bcc-test.yml |
| tests/cc/test_usdt_probes.cc (diff) |
| Dockerfile.tests |
|
| .github/workflows/bcc-test.yml (diff) |