-
Notifications
You must be signed in to change notification settings - Fork 9
Syncup 6.0/release with master #6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…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
update tools diagram for 2019
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.
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>
Add libbpf-based tools
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.
prakashsurya
approved these changes
Oct 20, 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. |
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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fast-forwards the 6.0/release branch to the same commit as master.
Testing