libbpf: add raw BTF type dumping #133
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
|
Master branch: 963ec27 |
|
Master branch: ea7da1d |
kernel-patches-bot
force-pushed
the
series/357435=>bpf-next
branch
from
b52f40f to
e0a3efe
Compare
Extend btf_dump APIs with ability to dump raw textual representation of BTF types, with the same format as used by `bpftool btf dump file` command. Such functionality is really useful for debugging issues with BTF, testing, BTF introspection, etc. It is going to be used in BPF selftests for validating BTF types. Signed-off-by: Andrii Nakryiko <[email protected]>
…ests Cross-validate raw BTF dump and writable BTF in a single selftest. Raw type dump checks also serve as a good self-documentation. Signed-off-by: Andrii Nakryiko <[email protected]>
|
Master branch: f4d385e |
kernel-patches-bot
force-pushed
the
series/357435=>bpf-next
branch
from
e0a3efe to
734fe8c
Compare
|
At least one diff in series https://patchwork.kernel.org/project/bpf/list/?series=357435 irrelevant now. Closing PR. |
kernel-patches-bot
pushed a commit
that referenced
this pull request
Feb 2, 2021
When handling an auth_gss downcall, it's possible to get 0-length opaque object for the acceptor. In the case of a 0-length XDR object, make sure simple_get_netobj() fills in dest->data = NULL, and does not continue to kmemdup() which will set dest->data = ZERO_SIZE_PTR for the acceptor. The trace event code can handle NULL but not ZERO_SIZE_PTR for a string, and so without this patch the rpcgss_context trace event will crash the kernel as follows: [ 162.887992] BUG: kernel NULL pointer dereference, address: 0000000000000010 [ 162.898693] #PF: supervisor read access in kernel mode [ 162.900830] #PF: error_code(0x0000) - not-present page [ 162.902940] PGD 0 P4D 0 [ 162.904027] Oops: 0000 [#1] SMP PTI [ 162.905493] CPU: 4 PID: 4321 Comm: rpc.gssd Kdump: loaded Not tainted 5.10.0 #133 [ 162.908548] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011 [ 162.910978] RIP: 0010:strlen+0x0/0x20 [ 162.912505] Code: 48 89 f9 74 09 48 83 c1 01 80 39 00 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee c3 0f 1f 80 00 00 00 00 <80> 3f 00 74 10 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 31 [ 162.920101] RSP: 0018:ffffaec900c77d90 EFLAGS: 00010202 [ 162.922263] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 00000000fffde697 [ 162.925158] RDX: 000000000000002f RSI: 0000000000000080 RDI: 0000000000000010 [ 162.928073] RBP: 0000000000000010 R08: 0000000000000e10 R09: 0000000000000000 [ 162.930976] R10: ffff8e698a590cb8 R11: 0000000000000001 R12: 0000000000000e10 [ 162.933883] R13: 00000000fffde697 R14: 000000010034d517 R15: 0000000000070028 [ 162.936777] FS: 00007f1e1eb93700(0000) GS:ffff8e6ab7d00000(0000) knlGS:0000000000000000 [ 162.940067] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 162.942417] CR2: 0000000000000010 CR3: 0000000104eba000 CR4: 00000000000406e0 [ 162.945300] Call Trace: [ 162.946428] trace_event_raw_event_rpcgss_context+0x84/0x140 [auth_rpcgss] [ 162.949308] ? __kmalloc_track_caller+0x35/0x5a0 [ 162.951224] ? gss_pipe_downcall+0x3a3/0x6a0 [auth_rpcgss] [ 162.953484] gss_pipe_downcall+0x585/0x6a0 [auth_rpcgss] [ 162.955953] rpc_pipe_write+0x58/0x70 [sunrpc] [ 162.957849] vfs_write+0xcb/0x2c0 [ 162.959264] ksys_write+0x68/0xe0 [ 162.960706] do_syscall_64+0x33/0x40 [ 162.962238] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 162.964346] RIP: 0033:0x7f1e1f1e57df Signed-off-by: Dave Wysochanski <[email protected]> Signed-off-by: Trond Myklebust <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Aug 17, 2023
LE Create CIS command shall not be sent before all CIS Established events from its previous invocation have been processed. Currently it is sent via hci_sync but that only waits for the first event, but there can be multiple. Make it wait for all events, and simplify the CIS creation as follows: Add new flag HCI_CONN_CREATE_CIS, which is set if Create CIS has been sent for the connection but it is not yet completed. Make BT_CONNECT state to mean the connection wants Create CIS. On events after which new Create CIS may need to be sent, send it if possible and some connections need it. These events are: hci_connect_cis, iso_connect_cfm, hci_cs_le_create_cis, hci_le_cis_estabilished_evt. The Create CIS status/completion events shall queue new Create CIS only if at least one of the connections transitions away from BT_CONNECT, so that we don't loop if controller is sending bogus events. This fixes sending multiple CIS Create for the same CIS in the "ISO AC 6(i) - Success" BlueZ test case: < HCI Command: LE Create Co.. (0x08|0x0064) plen 9 #129 [hci0] Number of CIS: 2 CIS Handle: 257 ACL Handle: 42 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 #130 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: Success (0x00) > HCI Event: LE Meta Event (0x3e) plen 29 #131 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 257 ... < HCI Command: LE Setup Is.. (0x08|0x006e) plen 13 #132 [hci0] ... > HCI Event: Command Complete (0x0e) plen 6 #133 [hci0] LE Setup Isochronous Data Path (0x08|0x006e) ncmd 1 ... < HCI Command: LE Create Co.. (0x08|0x0064) plen 5 #134 [hci0] Number of CIS: 1 CIS Handle: 258 ACL Handle: 42 > HCI Event: Command Status (0x0f) plen 4 #135 [hci0] LE Create Connected Isochronous Stream (0x08|0x0064) ncmd 1 Status: ACL Connection Already Exists (0x0b) > HCI Event: LE Meta Event (0x3e) plen 29 #136 [hci0] LE Connected Isochronous Stream Established (0x19) Status: Success (0x00) Connection Handle: 258 ... Fixes: c09b80b ("Bluetooth: hci_conn: Fix not waiting for HCI_EVT_LE_CIS_ESTABLISHED") Signed-off-by: Pauli Virtanen <[email protected]> Signed-off-by: Luiz Augusto von Dentz <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Dec 21, 2023
KASAN report following issue. The root cause is when opening 'hist'
file of an instance and accessing 'trace_event_file' in hist_show(),
but 'trace_event_file' has been freed due to the instance being removed.
'hist_debug' file has the same problem. To fix it, call
tracing_{open,release}_file_tr() in file_operations callback to have
the ref count and avoid 'trace_event_file' being freed.
BUG: KASAN: slab-use-after-free in hist_show+0x11e0/0x1278
Read of size 8 at addr ffff242541e336b8 by task head/190
CPU: 4 PID: 190 Comm: head Not tainted 6.7.0-rc5-g26aff849438c #133
Hardware name: linux,dummy-virt (DT)
Call trace:
dump_backtrace+0x98/0xf8
show_stack+0x1c/0x30
dump_stack_lvl+0x44/0x58
print_report+0xf0/0x5a0
kasan_report+0x80/0xc0
__asan_report_load8_noabort+0x1c/0x28
hist_show+0x11e0/0x1278
seq_read_iter+0x344/0xd78
seq_read+0x128/0x1c0
vfs_read+0x198/0x6c8
ksys_read+0xf4/0x1e0
__arm64_sys_read+0x70/0xa8
invoke_syscall+0x70/0x260
el0_svc_common.constprop.0+0xb0/0x280
do_el0_svc+0x44/0x60
el0_svc+0x34/0x68
el0t_64_sync_handler+0xb8/0xc0
el0t_64_sync+0x168/0x170
Allocated by task 188:
kasan_save_stack+0x28/0x50
kasan_set_track+0x28/0x38
kasan_save_alloc_info+0x20/0x30
__kasan_slab_alloc+0x6c/0x80
kmem_cache_alloc+0x15c/0x4a8
trace_create_new_event+0x84/0x348
__trace_add_new_event+0x18/0x88
event_trace_add_tracer+0xc4/0x1a0
trace_array_create_dir+0x6c/0x100
trace_array_create+0x2e8/0x568
instance_mkdir+0x48/0x80
tracefs_syscall_mkdir+0x90/0xe8
vfs_mkdir+0x3c4/0x610
do_mkdirat+0x144/0x200
__arm64_sys_mkdirat+0x8c/0xc0
invoke_syscall+0x70/0x260
el0_svc_common.constprop.0+0xb0/0x280
do_el0_svc+0x44/0x60
el0_svc+0x34/0x68
el0t_64_sync_handler+0xb8/0xc0
el0t_64_sync+0x168/0x170
Freed by task 191:
kasan_save_stack+0x28/0x50
kasan_set_track+0x28/0x38
kasan_save_free_info+0x34/0x58
__kasan_slab_free+0xe4/0x158
kmem_cache_free+0x19c/0x508
event_file_put+0xa0/0x120
remove_event_file_dir+0x180/0x320
event_trace_del_tracer+0xb0/0x180
__remove_instance+0x224/0x508
instance_rmdir+0x44/0x78
tracefs_syscall_rmdir+0xbc/0x140
vfs_rmdir+0x1cc/0x4c8
do_rmdir+0x220/0x2b8
__arm64_sys_unlinkat+0xc0/0x100
invoke_syscall+0x70/0x260
el0_svc_common.constprop.0+0xb0/0x280
do_el0_svc+0x44/0x60
el0_svc+0x34/0x68
el0t_64_sync_handler+0xb8/0xc0
el0t_64_sync+0x168/0x170
Link: https://lore.kernel.org/linux-trace-kernel/[email protected]
Suggested-by: Steven Rostedt <[email protected]>
Signed-off-by: Zheng Yejian <[email protected]>
Signed-off-by: Steven Rostedt (Google) <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Mar 3, 2024
Creating sysfs files for all Cells caused a boot failure for linux-6.8-rc1 on Apple M1, which (in downstream dts files) has multiple nvmem cells that use the same byte address. This causes the device probe to fail with [ 0.605336] sysfs: cannot create duplicate filename '/devices/platform/soc@200000000/2922bc000.efuse/apple_efuses_nvmem0/cells/efuse@a10' [ 0.605347] CPU: 7 PID: 1 Comm: swapper/0 Tainted: G S 6.8.0-rc1-arnd-5+ #133 [ 0.605355] Hardware name: Apple Mac Studio (M1 Ultra, 2022) (DT) [ 0.605362] Call trace: [ 0.605365] show_stack+0x18/0x2c [ 0.605374] dump_stack_lvl+0x60/0x80 [ 0.605383] dump_stack+0x18/0x24 [ 0.605388] sysfs_warn_dup+0x64/0x80 [ 0.605395] sysfs_add_bin_file_mode_ns+0xb0/0xd4 [ 0.605402] internal_create_group+0x268/0x404 [ 0.605409] sysfs_create_groups+0x38/0x94 [ 0.605415] devm_device_add_groups+0x50/0x94 [ 0.605572] nvmem_populate_sysfs_cells+0x180/0x1b0 [ 0.605682] nvmem_register+0x38c/0x470 [ 0.605789] devm_nvmem_register+0x1c/0x6c [ 0.605895] apple_efuses_probe+0xe4/0x120 [ 0.606000] platform_probe+0xa8/0xd0 As far as I can tell, this is a problem for any device with multiple cells on different bits of the same address. Avoid the issue by changing the file name to include the first bit number. Fixes: 0331c61 ("nvmem: core: Expose cells through sysfs") Link: https://github.com/AsahiLinux/linux/blob/bd0a1a7d4/arch/arm64/boot/dts/apple/t600x-dieX.dtsi#L156 Cc: <[email protected]> Cc: Miquel Raynal <[email protected]> Cc: Rafał Miłecki <[email protected]> Cc: Chen-Yu Tsai <[email protected]> Cc: Srinivas Kandagatla <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: <[email protected]> Cc: Sven Peter <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]> Signed-off-by: Srinivas Kandagatla <[email protected]> Reviewed-by: Eric Curtin <[email protected]> Reviewed-by: Miquel Raynal <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Sep 14, 2024
Ksym addr access is restricted by ``kptr_restrict``(/proc/sys/kernel/kptr_restrict). On some OS systems(like Android), ksym addr access is not accessed because ``kptr_restrict=2`. And it took me a long time to find the root case. -When ``kptr_restrict==0``, addr is accessed. # echo 0 > /proc/sys/kernel/kptr_restrict # cat /proc/kallsyms | grep bpf_link_fops ffffffd6bfd3fb60 d bpf_link_fops -When ``kptr_restrict==2``, addr is replaced by ZERO. # echo 2 > /proc/sys/kernel/kptr_restrict # cat /proc/kallsyms | grep bpf_link_fops 0000000000000000 d bpf_link_fops -When ``kptr_restrict==1``, addr is accessed for user having CAP_SYSLOG. So we should perform a check to remind users for these conditions before reading /proc/kallsyms. [before]: # echo 2 > /proc/sys/kernel/kptr_restrict # ./test_progs -t ksyms #133 ksyms:FAIL [after]: # echo 2 > /proc/sys/kernel/kptr_restrict # ./test_progs -t ksym ksyms restricted, please check /proc/sys/kernel/kptr_restrict #133 ksyms:FAIL Signed-off-by: Lin Yikai <[email protected]>
chantra
pushed a commit
to chantra/kernel-patches-bpf
that referenced
this pull request
Sep 15, 2024
Ksym addr access is restricted by ``kptr_restrict``(/proc/sys/kernel/kptr_restrict). On some OS systems(like Android), ksym addr access is not accessed because ``kptr_restrict=2`. And it took me a long time to find the root case. -When ``kptr_restrict==0``, addr is accessed. # echo 0 > /proc/sys/kernel/kptr_restrict # cat /proc/kallsyms | grep bpf_link_fops ffffffd6bfd3fb60 d bpf_link_fops -When ``kptr_restrict==2``, addr is replaced by ZERO. # echo 2 > /proc/sys/kernel/kptr_restrict # cat /proc/kallsyms | grep bpf_link_fops 0000000000000000 d bpf_link_fops -When ``kptr_restrict==1``, addr is accessed for user having CAP_SYSLOG. So we should perform a check to remind users for these conditions before reading /proc/kallsyms. [before]: # echo 2 > /proc/sys/kernel/kptr_restrict # ./test_progs -t ksyms kernel-patches#133 ksyms:FAIL [after]: # echo 2 > /proc/sys/kernel/kptr_restrict # ./test_progs -t ksym ksyms restricted, please check /proc/sys/kernel/kptr_restrict kernel-patches#133 ksyms:FAIL Signed-off-by: Lin Yikai <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Sep 21, 2024
Ksym addr access is restricted by ``kptr_restrict``(/proc/sys/kernel/kptr_restrict). On some OS systems(like Android), ksym addr access is not accessed because ``kptr_restrict=2`. And it took me a long time to find the root case. -When ``kptr_restrict==0``, addr is accessed. # echo 0 > /proc/sys/kernel/kptr_restrict # cat /proc/kallsyms | grep bpf_link_fops ffffffd6bfd3fb60 d bpf_link_fops -When ``kptr_restrict==2``, addr is replaced by ZERO. # echo 2 > /proc/sys/kernel/kptr_restrict # cat /proc/kallsyms | grep bpf_link_fops 0000000000000000 d bpf_link_fops -When ``kptr_restrict==1``, addr is accessed for user having CAP_SYSLOG. So we should perform a check to remind users for these conditions before reading /proc/kallsyms. [before]: # echo 2 > /proc/sys/kernel/kptr_restrict # ./test_progs -t ksyms #133 ksyms:FAIL [after]: # echo 2 > /proc/sys/kernel/kptr_restrict # ./test_progs -t ksym ksyms restricted, please check /proc/sys/kernel/kptr_restrict #133 ksyms:FAIL Signed-off-by: Lin Yikai <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Sep 23, 2024
Ksym addr access is restricted by ``kptr_restrict``(/proc/sys/kernel/kptr_restrict). On some OS systems(like Android), ksym addr access is not accessed because ``kptr_restrict=2`. And it took me a long time to find the root case. -When ``kptr_restrict==0``, addr is accessed. # echo 0 > /proc/sys/kernel/kptr_restrict # cat /proc/kallsyms | grep bpf_link_fops ffffffd6bfd3fb60 d bpf_link_fops -When ``kptr_restrict==2``, addr is replaced by ZERO. # echo 2 > /proc/sys/kernel/kptr_restrict # cat /proc/kallsyms | grep bpf_link_fops 0000000000000000 d bpf_link_fops -When ``kptr_restrict==1``, addr is accessed for user having CAP_SYSLOG. So we should perform a check to remind users for these conditions before reading /proc/kallsyms. [before]: # echo 2 > /proc/sys/kernel/kptr_restrict # ./test_progs -t ksyms #133 ksyms:FAIL [after]: # echo 2 > /proc/sys/kernel/kptr_restrict # ./test_progs -t ksym ksyms restricted, please check /proc/sys/kernel/kptr_restrict #133 ksyms:FAIL Signed-off-by: Lin Yikai <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Sep 23, 2024
Ksym addr access is restricted by ``kptr_restrict``(/proc/sys/kernel/kptr_restrict). On some OS systems(like Android), ksym addr access is not accessed because ``kptr_restrict=2`. And it took me a long time to find the root case. -When ``kptr_restrict==0``, addr is accessed. # echo 0 > /proc/sys/kernel/kptr_restrict # cat /proc/kallsyms | grep bpf_link_fops ffffffd6bfd3fb60 d bpf_link_fops -When ``kptr_restrict==2``, addr is replaced by ZERO. # echo 2 > /proc/sys/kernel/kptr_restrict # cat /proc/kallsyms | grep bpf_link_fops 0000000000000000 d bpf_link_fops -When ``kptr_restrict==1``, addr is accessed for user having CAP_SYSLOG. So we should perform a check to remind users for these conditions before reading /proc/kallsyms. [before]: # echo 2 > /proc/sys/kernel/kptr_restrict # ./test_progs -t ksyms #133 ksyms:FAIL [after]: # echo 2 > /proc/sys/kernel/kptr_restrict # ./test_progs -t ksym ksyms restricted, please check /proc/sys/kernel/kptr_restrict #133 ksyms:FAIL Signed-off-by: Lin Yikai <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Sep 24, 2024
Ksym addr access is restricted by ``kptr_restrict``(/proc/sys/kernel/kptr_restrict). On some OS systems(like Android), ksym addr access is not accessed because ``kptr_restrict=2`. And it took me a long time to find the root case. -When ``kptr_restrict==0``, addr is accessed. # echo 0 > /proc/sys/kernel/kptr_restrict # cat /proc/kallsyms | grep bpf_link_fops ffffffd6bfd3fb60 d bpf_link_fops -When ``kptr_restrict==2``, addr is replaced by ZERO. # echo 2 > /proc/sys/kernel/kptr_restrict # cat /proc/kallsyms | grep bpf_link_fops 0000000000000000 d bpf_link_fops -When ``kptr_restrict==1``, addr is accessed for user having CAP_SYSLOG. So we should perform a check to remind users for these conditions before reading /proc/kallsyms. [before]: # echo 2 > /proc/sys/kernel/kptr_restrict # ./test_progs -t ksyms #133 ksyms:FAIL [after]: # echo 2 > /proc/sys/kernel/kptr_restrict # ./test_progs -t ksym ksyms restricted, please check /proc/sys/kernel/kptr_restrict #133 ksyms:FAIL Signed-off-by: Lin Yikai <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Sep 24, 2024
Ksym addr access is restricted by ``kptr_restrict``(/proc/sys/kernel/kptr_restrict). On some OS systems(like Android), ksym addr access is not accessed because ``kptr_restrict=2`. And it took me a long time to find the root case. -When ``kptr_restrict==0``, addr is accessed. # echo 0 > /proc/sys/kernel/kptr_restrict # cat /proc/kallsyms | grep bpf_link_fops ffffffd6bfd3fb60 d bpf_link_fops -When ``kptr_restrict==2``, addr is replaced by ZERO. # echo 2 > /proc/sys/kernel/kptr_restrict # cat /proc/kallsyms | grep bpf_link_fops 0000000000000000 d bpf_link_fops -When ``kptr_restrict==1``, addr is accessed for user having CAP_SYSLOG. So we should perform a check to remind users for these conditions before reading /proc/kallsyms. [before]: # echo 2 > /proc/sys/kernel/kptr_restrict # ./test_progs -t ksyms #133 ksyms:FAIL [after]: # echo 2 > /proc/sys/kernel/kptr_restrict # ./test_progs -t ksym ksyms restricted, please check /proc/sys/kernel/kptr_restrict #133 ksyms:FAIL Signed-off-by: Lin Yikai <[email protected]>
kernel-patches-daemon-bpf bot
pushed a commit
that referenced
this pull request
Sep 24, 2024
Ksym addr access is restricted by ``kptr_restrict``(/proc/sys/kernel/kptr_restrict). On some OS systems(like Android), ksym addr access is not accessed because ``kptr_restrict=2`. And it took me a long time to find the root case. -When ``kptr_restrict==0``, addr is accessed. # echo 0 > /proc/sys/kernel/kptr_restrict # cat /proc/kallsyms | grep bpf_link_fops ffffffd6bfd3fb60 d bpf_link_fops -When ``kptr_restrict==2``, addr is replaced by ZERO. # echo 2 > /proc/sys/kernel/kptr_restrict # cat /proc/kallsyms | grep bpf_link_fops 0000000000000000 d bpf_link_fops -When ``kptr_restrict==1``, addr is accessed for user having CAP_SYSLOG. So we should perform a check to remind users for these conditions before reading /proc/kallsyms. [before]: # echo 2 > /proc/sys/kernel/kptr_restrict # ./test_progs -t ksyms #133 ksyms:FAIL [after]: # echo 2 > /proc/sys/kernel/kptr_restrict # ./test_progs -t ksym ksyms restricted, please check /proc/sys/kernel/kptr_restrict #133 ksyms:FAIL Signed-off-by: Lin Yikai <[email protected]>
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.
Pull request for series with
subject: libbpf: add raw BTF type dumping
version: 1
url: https://patchwork.kernel.org/project/bpf/list/?series=357435