scripts: add script to sync kernel changes #13
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
scripts/sync-kernel.sh
Outdated
| echo "PATCHSET: /tmp/libbpf-${SUFFIX}.patchset" | ||
|
|
||
| cd ${LIBBPF_REPO} | ||
| git co -b libbpf-sync-${SUFFIX} |
There was a problem hiding this comment.
I assume this is git checkout?
There was a problem hiding this comment.
Ah, yes, it's my local alias. I'm so used to it that didn't even realize it's not standard feature, will fix.
|
Thanks for implementation. This is in the right direction for automation! I tried to add a few artificial patches in bpf-next and got the following failures: The command line I tried: in the libbpf repo directory. |
|
Can you publish full output and patches you applied on top of bpf-next, I'll try to repro locally. Also what was HEAD of libbpf and
8000
kernel? |
|
The kernel part: Individual commits: |
|
Next time I will remember to go to a repo I can push to github. |
|
What was sha on libbpf side? |
|
libbpf side |
|
ah, I get it, it's the logic of updating CHECKPOINT-COMMIT file, it never exists in linux repo, I have a simpler idea on how to handle that. Thanks for catching this! |
8521d84 to
4091954
Compare
|
ahah, so there are two problems:
I fixed first in updated pull request. Will fix second soon. BTW, if you are going to try again, keep in mind that you might need to do "git am --abort" in linux repo, and checkout your old HEAD (copy branch). |
This script automates the process of applying libbpf-relevant changes from kernel repository on top of current state of libbpf repository. It uses CHECKPOINT-COMMIT file to keep track of last commit in kernel repo up to which libbpf is in sync with. If there are any new libbpf changes in kernel repository, script extracts them, preserving original commit metadata. It also creates a "sync commit" using cover letter as a template, which nicely summarizes changes since last sync with kernel. Usage: ./scripts/sync-kernel.sh <linux-repo> <libbpf-repo> If it succeeds, script will create a bunch of local commits in <libbpf-repo> in separate branch, which can be easily pushed into github to create a pull request. Script tries to clean up after itself, except in case of failure. But it doesn't clean up timestamped branches it creates in both kernel and libbpf repositories for now. We can add that later. Signed-off-by: Andrii Nakryiko <andriin@fb.com>
4091954 to
88d35a3
Compare
|
Ok, fixed second problem as well by switching back to original working dir and then doing State after running script: |
4ast
reviewed
Feb 17, 2019
| git rebase --onto ${SQUASHED_BASELINE_COMMIT} ${BASELINE_COMMIT} libbpf-${SUFFIX} | ||
|
|
||
| # Move all libbpf files into libbpf-projection directory | ||
| git filter-branch --prune-empty -f --tree-filter ' \ |
There was a problem hiding this comment.
didn't know such git command exist :)
There was a problem hiding this comment.
it's a "with great power comes great responsibility" type of command :)
|
@yonghong-song, you can check how sync commit looks like here: https://github.com/libbpf/libbpf/compare/master...anakryiko:libbpf-sync-2019-02-17T02-58-38.109Z?expand=1 I'm not yet creating that pull request, because we should probably land this one first and then I'll rebase (otherwise we'll have conflicts on CHECKPOINT-COMMIT file). |
|
I got a failure like below: Any idea what's the issue? I have the same bpf-next hack earlier. |
|
Yeah, due to that initial bug, your linux repository now has |
|
thanks. this time succeeded! Look likes need to learn a few git advanced commands :-) |
evverx
added a commit
to evverx/libbpf
that referenced
this pull request
Apr 11, 2022
Fixes
```
./out/bpf-object-fuzzer: Running 1 inputs 1 time(s) each.
Running: CORPUS/036ff286c13e4590646c7ef59435ec642432da8e
elf_begin.c:232:20: runtime error: member access within misaligned address 0x000001655e71 for type 'Elf64_Shdr', which requires 8 byte alignment
0x000001655e71: note: pointer points here
00 00 00 7f 45 4c 46 02 02 01 00 00 00 07 fb 00 1d 00 00 6c 69 63 65 42 fb 00 41 00 57 03 00 20
^
#0 0x574d51 in get_shnum /home/libbpf/elfutils/libelf/elf_begin.c:232:20
#1 0x574d51 in file_read_elf /home/libbpf/elfutils/libelf/elf_begin.c:296:19
#2 0x569c2c in __libelf_read_mmaped_file /home/libbpf/elfutils/libelf/elf_begin.c:559:14
#3 0x58e812 in elf_memory /home/libbpf/elfutils/libelf/elf_memory.c:49:10
#4 0x4905b4 in bpf_object__elf_init /home/libbpf/src/libbpf.c:1255:9
#5 0x4905b4 in bpf_object_open /home/libbpf/src/libbpf.c:7104:8
libbpf#6 0x49144e in bpf_object__open_mem /home/libbpf/src/libbpf.c:7171:20
libbpf#7 0x483018 in LLVMFuzzerTestOneInput /home/libbpf/fuzz/bpf-object-fuzzer.c:16:8
libbpf#8 0x439389 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/libbpf/out/bpf-object-fuzzer+0x439389)
libbpf#9 0x419e2f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/libbpf/out/bpf-object-fuzzer+0x419e2f)
libbpf#10 0x421aee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/libbpf/out/bpf-object-fuzzer+0x421aee)
libbpf#11 0x410f96 in main (/home/libbpf/out/bpf-object-fuzzer+0x410f96)
libbpf#12 0x7f153e21255f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
libbpf#13 0x7f153e21260b in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2d60b)
libbpf#14 0x410fe4 in _start (/home/libbpf/out/bpf-object-fuzzer+0x410fe4)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior elf_begin.c:232:20 in
```
and
```
./out/bpf-object-fuzzer: Running 1 inputs 1 time(s) each.
Running: CORPUS/446b578d82c47fe177de6fd675f4cb6bae8d1ea9
elf_begin.c:485:40: runtime error: addition of unsigned offset to 0x000002277e70 overflowed to 0x0000021d7e6f
#0 0x5748f1 in file_read_elf /home/libbpf/elfutils/libelf/elf_begin.c:485:40
#1 0x569c2c in __libelf_read_mmaped_file /home/libbpf/elfutils/libelf/elf_begin.c:559:14
#2 0x58e812 in elf_memory /home/libbpf/elfutils/libelf/elf_memory.c:49:10
#3 0x4905b4 in bpf_object__elf_init /home/libbpf/src/libbpf.c:1255:9
#4 0x4905b4 in bpf_object_open /home/libbpf/src/libbpf.c:7104:8
#5 0x49144e in bpf_object__open_mem /home/libbpf/src/libbpf.c:7171:20
libbpf#6 0x483018 in LLVMFuzzerTestOneInput /home/libbpf/fuzz/bpf-object-fuzzer.c:16:8
libbpf#7 0x439389 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/libbpf/out/bpf-object-fuzzer+0x439389)
libbpf#8 0x419e2f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/libbpf/out/bpf-object-fuzzer+0x419e2f)
libbpf#9 0x421aee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/libbpf/out/bpf-object-fuzzer+0x421aee)
libbpf#10 0x410f96 in main (/home/libbpf/out/bpf-object-fuzzer+0x410f96)
libbpf#11 0x7f753e38255f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
libbpf#12 0x7f753e38260b in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2d60b)
libbpf#13 0x410fe4 in _start (/home/libbpf/out/bpf-object-fuzzer+0x410fe4)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior elf_begin.c:485:40 in
```
anakryiko
pushed a commit
that referenced
this pull request
Apr 11, 2022
Fixes
```
./out/bpf-object-fuzzer: Running 1 inputs 1 time(s) each.
Running: CORPUS/036ff286c13e4590646c7ef59435ec642432da8e
elf_begin.c:232:20: runtime error: member access within misaligned address 0x000001655e71 for type 'Elf64_Shdr', which requires 8 byte alignment
0x000001655e71: note: pointer points here
00 00 00 7f 45 4c 46 02 02 01 00 00 00 07 fb 00 1d 00 00 6c 69 63 65 42 fb 00 41 00 57 03 00 20
^
#0 0x574d51 in get_shnum /home/libbpf/elfutils/libelf/elf_begin.c:232:20
#1 0x574d51 in file_read_elf /home/libbpf/elfutils/libelf/elf_begin.c:296:19
#2 0x569c2c in __libelf_read_mmaped_file /home/libbpf/elfutils/libelf/elf_begin.c:559:14
#3 0x58e812 in elf_memory /home/libbpf/elfutils/libelf/elf_memory.c:49:10
#4 0x4905b4 in bpf_object__elf_init /home/libbpf/src/libbpf.c:1255:9
#5 0x4905b4 in bpf_object_open /home/libbpf/src/libbpf.c:7104:8
#6 0x49144e in bpf_object__open_mem /home/libbpf/src/libbpf.c:7171:20
#7 0x483018 in LLVMFuzzerTestOneInput /home/libbpf/fuzz/bpf-object-fuzzer.c:16:8
#8 0x439389 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/libbpf/out/bpf-object-fuzzer+0x439389)
#9 0x419e2f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/libbpf/out/bpf-object-fuzzer+0x419e2f)
#10 0x421aee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/libbpf/out/bpf-object-fuzzer+0x421aee)
#11 0x410f96 in main (/home/libbpf/out/bpf-object-fuzzer+0x410f96)
#12 0x7f153e21255f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
#13 0x7f153e21260b in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2d60b)
#14 0x410fe4 in _start (/home/libbpf/out/bpf-object-fuzzer+0x410fe4)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior elf_begin.c:232:20 in
```
and
```
./out/bpf-object-fuzzer: Running 1 inputs 1 time(s) each.
Running: CORPUS/446b578d82c47fe177de6fd675f4cb6bae8d1ea9
elf_begin.c:485:40: runtime error: addition of unsigned offset to 0x000002277e70 overflowed to 0x0000021d7e6f
#0 0x5748f1 in file_read_elf /home/libbpf/elfutils/libelf/elf_begin.c:485:40
#1 0x569c2c in __libelf_read_mmaped_file /home/libbpf/elfutils/libelf/elf_begin.c:559:14
#2 0x58e812 in elf_memory /home/libbpf/elfutils/libelf/elf_memory.c:49:10
#3 0x4905b4 in bpf_object__elf_init /home/libbpf/src/libbpf.c:1255:9
#4 0x4905b4 in bpf_object_open /home/libbpf/src/libbpf.c:7104:8
#5 0x49144e in bpf_object__open_mem /home/libbpf/src/libbpf.c:7171:20
#6 0x483018 in LLVMFuzzerTestOneInput /home/libbpf/fuzz/bpf-object-fuzzer.c:16:8
#7 0x439389 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/libbpf/out/bpf-object-fuzzer+0x439389)
#8 0x419e2f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/libbpf/out/bpf-object-fuzzer+0x419e2f)
#9 0x421aee in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/libbpf/out/bpf-object-fuzzer+0x421aee)
#10 0x410f96 in main (/home/libbpf/out/bpf-object-fuzzer+0x410f96)
#11 0x7f753e38255f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
#12 0x7f753e38260b in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2d60b)
#13 0x410fe4 in _start (/home/libbpf/out/bpf-object-fuzzer+0x410fe4)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior elf_begin.c:485:40 in
```
anakryiko
pushed a commit
to anakryiko/libbpf
that referenced
this pull request
Oct 17, 2022
ASAN reports an use-after-free in btf_dump_name_dups:
ERROR: AddressSanitizer: heap-use-after-free on address 0xffff927006db at pc 0xaaaab5dfb618 bp 0xffffdd89b890 sp 0xffffdd89b928
READ of size 2 at 0xffff927006db thread T0
#0 0xaaaab5dfb614 in __interceptor_strcmp.part.0 (test_progs+0x21b614)
libbpf#1 0xaaaab635f144 in str_equal_fn tools/lib/bpf/btf_dump.c:127
libbpf#2 0xaaaab635e3e0 in hashmap_find_entry tools/lib/bpf/hashmap.c:143
libbpf#3 0xaaaab635e72c in hashmap__find tools/lib/bpf/hashmap.c:212
libbpf#4 0xaaaab6362258 in btf_dump_name_dups tools/lib/bpf/btf_dump.c:1525
libbpf#5 0xaaaab636240c in btf_dump_resolve_name tools/lib/bpf/btf_dump.c:1552
libbpf#6 0xaaaab6362598 in btf_dump_type_name tools/lib/bpf/btf_dump.c:1567
libbpf#7 0xaaaab6360b48 in btf_dump_emit_struct_def tools/lib/bpf/btf_dump.c:912
libbpf#8 0xaaaab6360630 in btf_dump_emit_type tools/lib/bpf/btf_dump.c:798
libbpf#9 0xaaaab635f720 in btf_dump__dump_type tools/lib/bpf/btf_dump.c:282
libbpf#10 0xaaaab608523c in test_btf_dump_incremental tools/testing/selftests/bpf/prog_tests/btf_dump.c:236
libbpf#11 0xaaaab6097530 in test_btf_dump tools/testing/selftests/bpf/prog_tests/btf_dump.c:875
libbpf#12 0xaaaab6314ed0 in run_one_test tools/testing/selftests/bpf/test_progs.c:1062
libbpf#13 0xaaaab631a0a8 in main tools/testing/selftests/bpf/test_progs.c:1697
libbpf#14 0xffff9676d214 in __libc_start_main ../csu/libc-start.c:308
libbpf#15 0xaaaab5d65990 (test_progs+0x185990)
0xffff927006db is located 11 bytes inside of 16-byte region [0xffff927006d0,0xffff927006e0)
freed by thread T0 here:
#0 0xaaaab5e2c7c4 in realloc (test_progs+0x24c7c4)
libbpf#1 0xaaaab634f4a0 in libbpf_reallocarray tools/lib/bpf/libbpf_internal.h:191
libbpf#2 0xaaaab634f840 in libbpf_add_mem tools/lib/bpf/btf.c:163
libbpf#3 0xaaaab636643c in strset_add_str_mem tools/lib/bpf/strset.c:106
libbpf#4 0xaaaab6366560 in strset__add_str tools/lib/bpf/strset.c:157
libbpf#5 0xaaaab6352d70 in btf__add_str tools/lib/bpf/btf.c:1519
libbpf#6 0xaaaab6353e10 in btf__add_field tools/lib/bpf/btf.c:2032
libbpf#7 0xaaaab6084fcc in test_btf_dump_incremental tools/testing/selftests/bpf/prog_tests/btf_dump.c:232
libbpf#8 0xaaaab6097530 in test_btf_dump tools/testing/selftests/bpf/prog_tests/btf_dump.c:875
libbpf#9 0xaaaab6314ed0 in run_one_test tools/testing/selftests/bpf/test_progs.c:1062
libbpf#10 0xaaaab631a0a8 in main tools/testing/selftests/bpf/test_progs.c:1697
libbpf#11 0xffff9676d214 in __libc_start_main ../csu/libc-start.c:308
libbpf#12 0xaaaab5d65990 (test_progs+0x185990)
previously allocated by thread T0 here:
#0 0xaaaab5e2c7c4 in realloc (test_progs+0x24c7c4)
libbpf#1 0xaaaab634f4a0 in libbpf_reallocarray tools/lib/bpf/libbpf_internal.h:191
libbpf#2 0xaaaab634f840 in libbpf_add_mem tools/lib/bpf/btf.c:163
libbpf#3 0xaaaab636643c in strset_add_str_mem tools/lib/bpf/strset.c:106
libbpf#4 0xaaaab6366560 in strset__add_str tools/lib/bpf/strset.c:157
libbpf#5 0xaaaab6352d70 in btf__add_str tools/lib/bpf/btf.c:1519
libbpf#6 0xaaaab6353ff0 in btf_add_enum_common tools/lib/bpf/btf.c:2070
libbpf#7 0xaaaab6354080 in btf__add_enum tools/lib/bpf/btf.c:2102
libbpf#8 0xaaaab6082f50 in test_btf_dump_incremental tools/testing/selftests/bpf/prog_tests/btf_dump.c:162
libbpf#9 0xaaaab6097530 in test_btf_dump tools/testing/selftests/bpf/prog_tests/btf_dump.c:875
libbpf#10 0xaaaab6314ed0 in run_one_test tools/testing/selftests/bpf/test_progs.c:1062
libbpf#11 0xaaaab631a0a8 in main tools/testing/selftests/bpf/test_progs.c:1697
libbpf#12 0xffff9676d214 in __libc_start_main ../csu/libc-start.c:308
libbpf#13 0xaaaab5d65990 (test_progs+0x185990)
The reason is that the key stored in hash table name_map is a string
address, and the string memory is allocated by realloc() function, when
the memory is resized by realloc() later, the old memory may be freed,
so the address stored in name_map references to a freed memory, causing
use-after-free.
Fix it by storing duplicated string address in name_map.
Fixes: 919d2b1dbb07 ("libbpf: Allow modification of BTF and add btf__add_str API")
Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Martin KaFai Lau <martin.lau@kernel.org>
Link: https://lore.kernel.org/bpf/20221011120108.782373-2-xukuohai@huaweicloud.com
anakryiko
pushed a commit
that referenced
this pull request
Oct 17, 2022
ASAN reports an use-after-free in btf_dump_name_dups:
ERROR: AddressSanitizer: heap-use-after-free on address 0xffff927006db at pc 0xaaaab5dfb618 bp 0xffffdd89b890 sp 0xffffdd89b928
READ of size 2 at 0xffff927006db thread T0
#0 0xaaaab5dfb614 in __interceptor_strcmp.part.0 (test_progs+0x21b614)
#1 0xaaaab635f144 in str_equal_fn tools/lib/bpf/btf_dump.c:127
#2 0xaaaab635e3e0 in hashmap_find_entry tools/lib/bpf/hashmap.c:143
#3 0xaaaab635e72c in hashmap__find tools/lib/bpf/hashmap.c:212
#4 0xaaaab6362258 in btf_dump_name_dups tools/lib/bpf/btf_dump.c:1525
#5 0xaaaab636240c in btf_dump_resolve_name tools/lib/bpf/btf_dump.c:1552
#6 0xaaaab6362598 in btf_dump_type_name tools/lib/bpf/btf_dump.c:1567
#7 0xaaaab6360b48 in btf_dump_emit_struct_def tools/lib/bpf/btf_dump.c:912
#8 0xaaaab6360630 in btf_dump_emit_type tools/lib/bpf/btf_dump.c:798
#9 0xaaaab635f720 in btf_dump__dump_type tools/lib/bpf/btf_dump.c:282
#10 0xaaaab608523c in test_btf_dump_incremental tools/testing/selftests/bpf/prog_tests/btf_dump.c:236
#11 0xaaaab6097530 in test_btf_dump tools/testing/selftests/bpf/prog_tests/btf_dump.c:875
#12 0xaaaab6314ed0 in run_one_test tools/testing/selftests/bpf/test_progs.c:1062
#13 0xaaaab631a0a8 in main tools/testing/selftests/bpf/test_progs.c:1697
#14 0xffff9676d214 in __libc_start_main ../csu/libc-start.c:308
#15 0xaaaab5d65990 (test_progs+0x185990)
0xffff927006db is located 11 bytes inside of 16-byte region [0xffff927006d0,0xffff927006e0)
freed by thread T0 here:
#0 0xaaaab5e2c7c4 in realloc (test_progs+0x24c7c4)
#1 0xaaaab634f4a0 in libbpf_reallocarray tools/lib/bpf/libbpf_internal.h:191
#2 0xaaaab634f840 in libbpf_add_mem tools/lib/bpf/btf.c:163
#3 0xaaaab636643c in strset_add_str_mem tools/lib/bpf/strset.c:106
#4 0xaaaab6366560 in strset__add_str tools/lib/bpf/strset.c:157
#5 0xaaaab6352d70 in btf__add_str tools/lib/bpf/btf.c:1519
#6 0xaaaab6353e10 in btf__add_field tools/lib/bpf/btf.c:2032
#7 0xaaaab6084fcc in test_btf_dump_incremental tools/testing/selftests/bpf/prog_tests/btf_dump.c:232
#8 0xaaaab6097530 in test_btf_dump tools/testing/selftests/bpf/prog_tests/btf_dump.c:875
#9 0xaaaab6314ed0 in run_one_test tools/testing/selftests/bpf/test_progs.c:1062
#10 0xaaaab631a0a8 in main tools/testing/selftests/bpf/test_progs.c:1697
#11 0xffff9676d214 in __libc_start_main ../csu/libc-start.c:308
#12 0xaaaab5d65990 (test_progs+0x185990)
previously allocated by thread T0 here:
#0 0xaaaab5e2c7c4 in realloc (test_progs+0x24c7c4)
#1 0xaaaab634f4a0 in libbpf_reallocarray tools/lib/bpf/libbpf_internal.h:191
#2 0xaaaab634f840 in libbpf_add_mem tools/lib/bpf/btf.c:163
#3 0xaaaab636643c in strset_add_str_mem tools/lib/bpf/strset.c:106
#4 0xaaaab6366560 in strset__add_str tools/lib/bpf/strset.c:157
#5 0xaaaab6352d70 in btf__add_str tools/lib/bpf/btf.c:1519
#6 0xaaaab6353ff0 in btf_add_enum_common tools/lib/bpf/btf.c:2070
#7 0xaaaab6354080 in btf__add_enum tools/lib/bpf/btf.c:2102
#8 0xaaaab6082f50 in test_btf_dump_incremental tools/testing/selftests/bpf/prog_tests/btf_dump.c:162
#9 0xaaaab6097530 in test_btf_dump tools/testing/selftests/bpf/prog_tests/btf_dump.c:875
#10 0xaaaab6314ed0 in run_one_test tools/testing/selftests/bpf/test_progs.c:1062
#11 0xaaaab631a0a8 in main tools/testing/selftests/bpf/test_progs.c:1697
#12 0xffff9676d214 in __libc_start_main ../csu/libc-start.c:308
#13 0xaaaab5d65990 (test_progs+0x185990)
The reason is that the key stored in hash table name_map is a string
address, and the string memory is allocated by realloc() function, when
the memory is resized by realloc() later, the old memory may be freed,
so the address stored in name_map references to a freed memory, causing
use-after-free.
Fix it by storing duplicated string address in name_map.
Fixes: 919d2b1dbb07 ("libbpf: Allow modification of BTF and add btf__add_str API")
Signed-off-by: Xu Kuohai <xukuohai@huawei.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Acked-by: Martin KaFai Lau <martin.lau@kernel.org>
Link: https://lore.kernel.org/bpf/20221011120108.782373-2-xukuohai@huaweicloud.com
danielocfb
pushed a commit
to danielocfb/libbpf
that referenced
this pull request
Feb 15, 2023
Original change: undetermined Change-Id: I32955427576e59c77aeb84dcaab6aa72f1862490
danielocfb
pushed a commit
to danielocfb/libbpf
that referenced
this pull request
Feb 15, 2023
danielocfb
pushed a commit
to danielocfb/libbpf
that referenced
this pull request
Feb 15, 2023
anakryiko
pushed a commit
to anakryiko/libbpf
that referenced
this pull request
Apr 29, 2025
When the binary path is excessively long, the generated probe_name in libbpf exceeds the kernel's MAX_EVENT_NAME_LEN limit (64 bytes). This causes legacy uprobe event attachment to fail with error code -22. The fix reorders the fields to place the unique ID before the name. This ensures that even if truncation occurs via snprintf, the unique ID remains intact, preserving event name uniqueness. Additionally, explicit checks with MAX_EVENT_NAME_LEN are added to enforce length constraints. Before Fix: ./test_progs -t attach_probe/kprobe-long_name ...... libbpf: failed to add legacy kprobe event for 'bpf_testmod_looooooooooooooooooooooooooooooong_name+0x0': -EINVAL libbpf: prog 'handle_kprobe': failed to create kprobe 'bpf_testmod_looooooooooooooooooooooooooooooong_name+0x0' perf event: -EINVAL test_attach_kprobe_long_event_name:FAIL:attach_kprobe_long_event_name unexpected error: -22 test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec libbpf#13/11 attach_probe/kprobe-long_name:FAIL libbpf#13 attach_probe:FAIL ./test_progs -t attach_probe/uprobe-long_name ...... libbpf: failed to add legacy uprobe event for /root/linux-bpf/bpf-next/tools/testing/selftests/bpf/test_progs:0x13efd9: -EINVAL libbpf: prog 'handle_uprobe': failed to create uprobe '/root/linux-bpf/bpf-next/tools/testing/selftests/bpf/test_progs:0x13efd9' perf event: -EINVAL test_attach_uprobe_long_event_name:FAIL:attach_uprobe_long_event_name unexpected error: -22 libbpf#13/10 attach_probe/uprobe-long_name:FAIL libbpf#13 attach_probe:FAIL After Fix: ./test_progs -t attach_probe/uprobe-long_name libbpf#13/10 attach_probe/uprobe-long_name:OK libbpf#13 attach_probe:OK Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED ./test_progs -t attach_probe/kprobe-long_name libbpf#13/11 attach_probe/kprobe-long_name:OK libbpf#13 attach_probe:OK Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED Fixes: 46ed5fc33db9 ("libbpf: Refactor and simplify legacy kprobe code") Fixes: cc10623c6810 ("libbpf: Add legacy uprobe attaching support") Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Feng Yang <yangfeng@kylinos.cn> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20250417014848.59321-2-yangfeng59949@163.com
anakryiko
pushed a commit
that referenced
this pull request
Apr 29, 2025
When the binary path is excessively long, the generated probe_name in libbpf exceeds the kernel's MAX_EVENT_NAME_LEN limit (64 bytes). This causes legacy uprobe event attachment to fail with error code -22. The fix reorders the fields to place the unique ID before the name. This ensures that even if truncation occurs via snprintf, the unique ID remains intact, preserving event name uniqueness. Additionally, explicit checks with MAX_EVENT_NAME_LEN are added to enforce length constraints. Before Fix: ./test_progs -t attach_probe/kprobe-long_name ...... libbpf: failed to add legacy kprobe event for 'bpf_testmod_looooooooooooooooooooooooooooooong_name+0x0': -EINVAL libbpf: prog 'handle_kprobe': failed to create kprobe 'bpf_testmod_looooooooooooooooooooooooooooooong_name+0x0' perf event: -EINVAL test_attach_kprobe_long_event_name:FAIL:attach_kprobe_long_event_name unexpected error: -22 test_attach_probe:PASS:uprobe_ref_ctr_cleanup 0 nsec #13/11 attach_probe/kprobe-long_name:FAIL #13 attach_probe:FAIL ./test_progs -t attach_probe/uprobe-long_name ...... libbpf: failed to add legacy uprobe event for /root/linux-bpf/bpf-next/tools/testing/selftests/bpf/test_progs:0x13efd9: -EINVAL libbpf: prog 'handle_uprobe': failed to create uprobe '/root/linux-bpf/bpf-next/tools/testing/selftests/bpf/test_progs:0x13efd9' perf event: -EINVAL test_attach_uprobe_long_event_name:FAIL:attach_uprobe_long_event_name unexpected error: -22 #13/10 attach_probe/uprobe-long_name:FAIL #13 attach_probe:FAIL After Fix: ./test_progs -t attach_probe/uprobe-long_name #13/10 attach_probe/uprobe-long_name:OK #13 attach_probe:OK Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED ./test_progs -t attach_probe/kprobe-long_name #13/11 attach_probe/kprobe-long_name:OK #13 attach_probe:OK Summary: 1/1 PASSED, 0 SKIPPED, 0 FAILED Fixes: 46ed5fc33db9 ("libbpf: Refactor and simplify legacy kprobe code") Fixes: cc10623c6810 ("libbpf: Add legacy uprobe attaching support") Signed-off-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Feng Yang <yangfeng@kylinos.cn> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20250417014848.59321-2-yangfeng59949@163.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 script automates the process of applying libbpf-relevant changes
from kernel repository on top of current state of libbpf repository.
It uses CHECKPOINT-COMMIT file to keep track of last commit in kernel
repo up to which libbpf is in sync with. If there are any new libbpf
changes in kernel repository, script extracts them, preserving original
commit metadata. It also creates a "sync commit" using cover letter as
a template, which nicely summarizes changes since last sync with kernel.
Usage:
./scripts/sync-kernel.sh <linux-repo> <libbpf-repo>If it succeeds, script will create a bunch of local commits in
in separate branch, which can be easily pushed into github
to create a pull request.
Script tries to clean up after itself, except in case of failure. But it
doesn't clean up timestamped branches it creates in both kernel and
libbpf repositories for now. We can add that later.
Signed-off-by: Andrii Nakryiko andriin@fb.com