Sync with upstream #4
Merged
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.
With this commit, pushes to branches can trigger tests directly on
Github Actions.
Here it will be able to test against kernel 4.14 and 5.0.0, which correspond
to the latest Ubuntu LTS kernel releases.
Tests are run for both Debug and Release modes.
Tests run inside docker, in an ubuntu 19.04 container base.
For the github workflow:
- The test_libbcc suite is run first, to potentially fail fast on these faster
unit tests.
- The Python test suite is run
Some of these tests are allowed to fail, but the failure is still reported:
- In catch2 tests, using the [!mayfail] tag, where this will be displayed in
the test summary
- In Python unittests, using the `@mayFail("Reason")` decorator, which is
introduce for consistency with catch2. These will report the reason for the
failure, and log this to an artifact of the test.
solves #2722
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.
pzakha
approved these changes
Feb 25, 2020
|
Should be good to merge anytime. |
prakashsurya
pushed a commit
that referenced
this pull request
Nov 8, 2022
There are two pass managers in LLVM. Currently BCC uses the legacy one.
Switch to the new pass manager because the legacy one will be removed
in upcoming releases of LLVM.
Running the following script:
```
from bcc import BPF
bpf_text = '''
static int foobar()
{
bpf_trace_printk("enter vfs_read");
return 0;
}
KFUNC_PROBE(vfs_read)
{
return foobar();
}
'''
BPF(text=bpf_text, debug=1)
```
The IR output is the same with or without this change using LLVM 15:
; ModuleID = 'sscanf'
source_filename = "sscanf"
; ModuleID = '/virtual/main.c'
source_filename = "/virtual/main.c"
target datalayout = "e-m:e-p:64:64-i64:64-i128:128-n32:64-S128"
target triple = "bpf-pc-linux"
@_version = dso_local global i32 332032, section "version", align 4, !dbg !0
@_license = dso_local global [4 x i8] c"GPL\00", section "license", align 1, !dbg !5
@__const.foobar._fmt = private unnamed_addr constant [15 x i8] c"enter vfs_read\00", align 1
@llvm.compiler.used = appending global [2 x ptr] [ptr @_license, ptr @_version], section "llvm.metadata"
; Function Attrs: alwaysinline nounwind
define dso_local i32 @kfunc__vfs_read(ptr nocapture noundef readnone %0) local_unnamed_addr #0 section ".bpf.fn.kfunc__vfs_read" !dbg !33 {
%2 = alloca [15 x i8], align 1
call void @llvm.dbg.value(metadata ptr %0, metadata !39, metadata !DIExpression()), !dbg !41
call void @llvm.dbg.value(metadata ptr undef, metadata !42, metadata !DIExpression()) #4, !dbg !45
call void @llvm.lifetime.start.p0(i64 15, ptr nonnull %2) #4, !dbg !47
call void @llvm.dbg.declare(metadata ptr %2, metadata !53, metadata !DIExpression()) #4, !dbg !58
call void @llvm.memcpy.p0.p0.i64(ptr noundef nonnull align 1 dereferenceable(15) %2, ptr noundef nonnull align 1 dereferenceable(15) @__const.foobar._fmt, i64 15, i1 false) #4, !dbg !58
%3 = call i32 (ptr, i64, ...) inttoptr (i64 6 to ptr)(ptr noundef nonnull %2, i64 noundef 15) #4, !dbg !59
call void @llvm.lifetime.end.p0(i64 15, ptr nonnull %2) #4, !dbg !60
call void @llvm.dbg.value(metadata i32 0, metadata !40, metadata !DIExpression()), !dbg !41
ret i32 0, !dbg !61
}
; Function Attrs: alwaysinline mustprogress nocallback nofree nosync nounwind readnone speculatable willreturn
declare void @llvm.dbg.declare(metadata, metadata, metadata) #1
; Function Attrs: alwaysinline argmemonly mustprogress nocallback nofree nosync nounwind willreturn
declare void @llvm.lifetime.start.p0(i64 immarg, ptr nocapture) #2
; Function Attrs: alwaysinline argmemonly mustprogress nocallback nofree nosync nounwind willreturn
declare void @llvm.lifetime.end.p0(i64 immarg, ptr nocapture) #2
; Function Attrs: alwaysinline argmemonly mustprogress nofree nounwind willreturn
declare void @llvm.memcpy.p0.p0.i64(ptr noalias nocapture writeonly, ptr noalias nocapture readonly, i64, i1 immarg) #3
; Function Attrs: alwaysinline mustprogress nocallback nofree nosync nounwind readnone speculatable willreturn
declare void @llvm.dbg.value(metadata, metadata, metadata) #1
attributes #0 = { alwaysinline nounwind "frame-pointer"="none" "min-legal-vector-width"="0" "no-jump-tables"="true" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" }
attributes #1 = { alwaysinline mustprogress nocallback nofree nosync nounwind readnone speculatable willreturn }
attributes #2 = { alwaysinline argmemonly mustprogress nocallback nofree nosync nounwind willreturn }
attributes #3 = { alwaysinline argmemonly mustprogress nofree nounwind willreturn }
attributes #4 = { nounwind }
!llvm.dbg.cu = !{!2}
!llvm.module.flags = !{!27, !28, !29, !30, !31}
!llvm.ident = !{!32}
!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
!1 = distinct !DIGlobalVariable(name: "_version", scope: !2, file: !14, line: 526, type: !26, isLocal: false, isDefinition: true)
!2 = distinct !DICompileUnit(language: DW_LANG_C99, file: !3, producer: "Ubuntu clang version 15.0.0-++20220426083628+d738d4717f6d-1~exp1~20220426203725.435", isOptimized: true, runtimeVersion: 0, emissionKind: FullDebug, globals: !4, splitDebugInlining: false, nameTableKind: None)
!3 = !DIFile(filename: "/virtual/main.c", directory: "/home/ubuntu/sources/bpf-next")
!4 = !{!0, !5, !12}
!5 = !DIGlobalVariableExpression(var: !6, expr: !DIExpression())
!6 = distinct !DIGlobalVariable(name: "_license", scope: !2, file: !7, line: 26, type: !8, isLocal: false, isDefinition: true)
!7 = !DIFile(filename: "/virtual/include/bcc/footer.h", directory: "")
!8 = !DICompositeType(tag: DW_TAG_array_type, baseType: !9, size: 32, elements: !10)
!9 = !DIBasicType(name: "char", size: 8, encoding: DW_ATE_signed_char)
!10 = !{!11}
!11 = !DISubrange(count: 4)
!12 = !DIGlobalVariableExpression(var: !13, expr: !DIExpression())
!13 = distinct !DIGlobalVariable(name: "bpf_trace_printk_", scope: !2, file: !14, line: 542, type: !15, isLocal: true, isDefinition: true)
!14 = !DIFile(filename: "/virtual/include/bcc/helpers.h", directory: "")
!15 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !16, size: 64)
!16 = !DISubroutineType(types: !17)
!17 = !{!18, !19, !21, null}
!18 = !DIBasicType(name: "int", size: 32, encoding: DW_ATE_signed)
!19 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !20, size: 64)
!20 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !9)
!21 = !DIDerivedType(tag: DW_TAG_typedef, name: "u64", file: !22, line: 23, baseType: !23)
!22 = !DIFile(filename: "include/asm-generic/int-ll64.h", directory: "/home/ubuntu/sources/bpf-next")
!23 = !DIDerivedType(tag: DW_TAG_typedef, name: "__u64", file: !24, line: 31, baseType: !25)
!24 = !DIFile(filename: "include/uapi/asm-generic/int-ll64.h", directory: "/home/ubuntu/sources/bpf-next")
!25 = !DIBasicType(name: "unsigned long long", size: 64, encoding: DW_ATE_unsigned)
!26 = !DIBasicType(name: "unsigned int", size: 32, encoding: DW_ATE_unsigned)
!27 = !{i32 7, !"Dwarf Version", i32 4}
!28 = !{i32 2, !"Debug Info Version", i32 3}
!29 = !{i32 1, !"wchar_size", i32 4}
!30 = !{i32 7, !"PIC Level", i32 2}
!31 = !{i32 7, !"PIE Level", i32 2}
!32 = !{!"Ubuntu clang version 15.0.0-++20220426083628+d738d4717f6d-1~exp1~20220426203725.435"}
!33 = distinct !DISubprogram(name: "kfunc__vfs_read", scope: !34, file: !34, line: 23, type: !35, scopeLine: 23, flags: DIFlagPrototyped | DIFlagAllCallsDescribed, spFlags: DISPFlagDefinition | DISPFlagOptimized, unit: !2, retainedNodes: !38)
!34 = !DIFile(filename: "/virtual/main.c", directory: "")
!35 = !DISubroutineType(types: !36)
!36 = !{!18, !37}
!37 = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: !25, size: 64)
!38 = !{!39, !40}
!39 = !DILocalVariable(name: "ctx", arg: 1, scope: !33, file: !34, line: 23, type: !37)
!40 = !DILocalVariable(name: "__ret", scope: !33, file: !34, line: 23, type: !18)
!41 = !DILocation(line: 0, scope: !33)
!42 = !DILocalVariable(name: "ctx", arg: 1, scope: !43, file: !34, line: 23, type: !37)
!43 = distinct !DISubprogram(name: "____kfunc__vfs_read", scope: !34, file: !34, line: 23, type: !35, scopeLine: 24, flags: DIFlagPrototyped | DIFlagAllCallsDescribed, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition | DISPFlagOptimized, unit: !2, retainedNodes: !44)
!44 = !{!42}
!45 = !DILocation(line: 0, scope: !43, inlinedAt: !46)
!46 = distinct !DILocation(line: 23, column: 1, scope: !33)
!47 = !DILocation(line: 15, column: 5, scope: !48, inlinedAt: !57)
!48 = distinct !DILexicalBlock(scope: !49, file: !34, line: 15, column: 3)
!49 = distinct !DISubprogram(name: "foobar", scope: !34, file: !34, line: 13, type: !50, scopeLine: 14, flags: DIFlagAllCallsDescribed, spFlags: DISPFlagLocalToUnit | DISPFlagDefinition | DISPFlagOptimized, unit: !2, retainedNodes: !52)
!50 = !DISubroutineType(types: !51)
!51 = !{!18}
!52 = !{!53}
!53 = !DILocalVariable(name: "_fmt", scope: !48, file: !34, line: 15, type: !54)
!54 = !DICompositeType(tag: DW_TAG_array_type, baseType: !9, size: 120, elements: !55)
!55 = !{!56}
!56 = !DISubrange(count: 15)
!57 = distinct !DILocation(line: 25, column: 9, scope: !43, inlinedAt: !46)
!58 = !DILocation(line: 15, column: 10, scope: !48, inlinedAt: !57)
!59 = !DILocation(line: 15, column: 37, scope: !48, inlinedAt: !57)
!60 = !DILocation(line: 15, column: 76, scope: !49, inlinedAt: !57)
!61 = !DILocation(line: 23, column: 1, scope: !33)
Closes #3947.
References:
[0]: https://llvm.org/docs/NewPassManager.html
[1]: https://blog.llvm.org/posts/2021-03-26-the-new-pass-manager/
Signed-off-by: Hengqi Chen <chenhengqi@outlook.com>
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.
A while back we turned off auto-updates for bcc, opting instead to periodically merge in changes from upstream manually. This pulls in the last 9 months of changes. There were no merge conflicts.
Automated Testing
Manual Testing
estatcommand, made sure that it ran and that the output looked sane.bpftracecommands and confirmed that they produced the expected results