<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/tools/bpf, branch v5.15.161</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.15.161</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.15.161'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2024-06-16T11:39:50Z</updated>
<entry>
<title>bpf: Fix potential integer overflow in resolve_btfids</title>
<updated>2024-06-16T11:39:50Z</updated>
<author>
<name>Friedrich Vock</name>
<email>friedrich.vock@gmx.de</email>
</author>
<published>2024-05-14T07:09:31Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e5138f43c97de3330f4eb58cbc21e9b226e2605e'/>
<id>urn:sha1:e5138f43c97de3330f4eb58cbc21e9b226e2605e</id>
<content type='text'>
[ Upstream commit 44382b3ed6b2787710c8ade06c0e97f5970a47c8 ]

err is a 32-bit integer, but elf_update returns an off_t, which is 64-bit
at least on 64-bit platforms. If symbols_patch is called on a binary between
2-4GB in size, the result will be negative when cast to a 32-bit integer,
which the code assumes means an error occurred. This can wrongly trigger
build failures when building very large kernel images.

Fixes: fbbb68de80a4 ("bpf: Add resolve_btfids tool to resolve BTF IDs in ELF object")
Signed-off-by: Friedrich Vock &lt;friedrich.vock@gmx.de&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Acked-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Link: https://lore.kernel.org/bpf/20240514070931.199694-1-friedrich.vock@gmx.de
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bpftool: Silence build warning about calloc()</title>
<updated>2024-03-26T22:21:17Z</updated>
<author>
<name>Tiezhu Yang</name>
<email>yangtiezhu@loongson.cn</email>
</author>
<published>2024-01-16T06:19:20Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=e0d29c4def1591ba5a8ffcb4028e7f86e959c50c'/>
<id>urn:sha1:e0d29c4def1591ba5a8ffcb4028e7f86e959c50c</id>
<content type='text'>
[ Upstream commit f5f30386c78105cba520e443a6a9ee945ec1d066 ]

There exists the following warning when building bpftool:

  CC      prog.o
prog.c: In function ‘profile_open_perf_events’:
prog.c:2301:24: warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Wcalloc-transposed-args]
 2301 |                 sizeof(int), obj-&gt;rodata-&gt;num_cpu * obj-&gt;rodata-&gt;num_metric);
      |                        ^~~
prog.c:2301:24: note: earlier argument should specify number of elements, later size of each element

Tested with the latest upstream GCC which contains a new warning option
-Wcalloc-transposed-args. The first argument to calloc is documented to
be number of elements in array, while the second argument is size of each
element, just switch the first and second arguments of calloc() to silence
the build warning, compile tested only.

Fixes: 47c09d6a9f67 ("bpftool: Introduce "prog profile" command")
Signed-off-by: Tiezhu Yang &lt;yangtiezhu@loongson.cn&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Reviewed-by: Quentin Monnet &lt;quentin@isovalent.com&gt;
Link: https://lore.kernel.org/bpf/20240116061920.31172-1-yangtiezhu@loongson.cn
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bpftool: Use a local bpf_perf_event_value to fix accessing its fields</title>
<updated>2023-09-19T10:22:32Z</updated>
<author>
<name>Alexander Lobakin</name>
<email>alobakin@pm.me</email>
</author>
<published>2023-07-07T09:54:25Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=75d3960be702adaa6b55f353e4bc636bdbe252df'/>
<id>urn:sha1:75d3960be702adaa6b55f353e4bc636bdbe252df</id>
<content type='text'>
[ Upstream commit 658ac06801315b739774a15796ff06913ef5cad5 ]

Fix the following error when building bpftool:

  CLANG   profiler.bpf.o
  CLANG   pid_iter.bpf.o
skeleton/profiler.bpf.c:18:21: error: invalid application of 'sizeof' to an incomplete type 'struct bpf_perf_event_value'
        __uint(value_size, sizeof(struct bpf_perf_event_value));
                           ^     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
tools/bpf/bpftool/bootstrap/libbpf/include/bpf/bpf_helpers.h:13:39: note: expanded from macro '__uint'
tools/bpf/bpftool/bootstrap/libbpf/include/bpf/bpf_helper_defs.h:7:8: note: forward declaration of 'struct bpf_perf_event_value'
struct bpf_perf_event_value;
       ^

struct bpf_perf_event_value is being used in the kernel only when
CONFIG_BPF_EVENTS is enabled, so it misses a BTF entry then.
Define struct bpf_perf_event_value___local with the
`preserve_access_index` attribute inside the pid_iter BPF prog to
allow compiling on any configs. It is a full mirror of a UAPI
structure, so is compatible both with and w/o CO-RE.
bpf_perf_event_read_value() requires a pointer of the original type,
so a cast is needed.

Fixes: 47c09d6a9f67 ("bpftool: Introduce "prog profile" command")
Suggested-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Signed-off-by: Alexander Lobakin &lt;alobakin@pm.me&gt;
Signed-off-by: Quentin Monnet &lt;quentin@isovalent.com&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20230707095425.168126-5-quentin@isovalent.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bpftool: JIT limited misreported as negative value on aarch64</title>
<updated>2023-07-23T11:46:50Z</updated>
<author>
<name>Alan Maguire</name>
<email>alan.maguire@oracle.com</email>
</author>
<published>2023-05-12T11:31:34Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=534508689e897e8b6760d39d3dcd76722cc32609'/>
<id>urn:sha1:534508689e897e8b6760d39d3dcd76722cc32609</id>
<content type='text'>
[ Upstream commit 04cb8453a91c7c22f60ddadb6cef0d19abb33bb5 ]

On aarch64, "bpftool feature" reports an incorrect BPF JIT limit:

$ sudo /sbin/bpftool feature
Scanning system configuration...
bpf() syscall restricted to privileged users
JIT compiler is enabled
JIT compiler hardening is disabled
JIT compiler kallsyms exports are enabled for root
skipping kernel config, can't open file: No such file or directory
Global memory limit for JIT compiler for unprivileged users is -201326592 bytes

This is because /proc/sys/net/core/bpf_jit_limit reports

$ sudo cat /proc/sys/net/core/bpf_jit_limit
68169519595520

...and an int is assumed in read_procfs().  Change read_procfs()
to return a long to avoid negative value reporting.

Fixes: 7a4522bbef0c ("tools: bpftool: add probes for /proc/ eBPF parameters")
Reported-by: Nicky Veitch &lt;nicky.veitch@oracle.com&gt;
Signed-off-by: Alan Maguire &lt;alan.maguire@oracle.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Acked-by: Jiri Olsa &lt;jolsa@kernel.org&gt;
Acked-by: Quentin Monnet &lt;quentin@isovalent.com&gt;
Link: https://lore.kernel.org/bpf/20230512113134.58996-1-alan.maguire@oracle.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bpftool: Fix bug for long instructions in program CFG dumps</title>
<updated>2023-05-11T14:00:27Z</updated>
<author>
<name>Quentin Monnet</name>
<email>quentin@isovalent.com</email>
</author>
<published>2023-04-05T13:21:15Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=80bfd8b184d8dd87921d4f78ddea7fdc0077c1d6'/>
<id>urn:sha1:80bfd8b184d8dd87921d4f78ddea7fdc0077c1d6</id>
<content type='text'>
[ Upstream commit 67cf52cdb6c8fa6365d29106555dacf95c9fd374 ]

When dumping the control flow graphs for programs using the 16-byte long
load instruction, we need to skip the second part of this instruction
when looking for the next instruction to process. Otherwise, we end up
printing "BUG_ld_00" from the kernel disassembler in the CFG.

Fixes: efcef17a6d65 ("tools: bpftool: generate .dot graph from CFG information")
Signed-off-by: Quentin Monnet &lt;quentin@isovalent.com&gt;
Link: https://lore.kernel.org/r/20230405132120.59886-3-quentin@isovalent.com
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tools: bpftool: Remove invalid \' json escape</title>
<updated>2023-05-11T14:00:25Z</updated>
<author>
<name>Luis Gerhorst</name>
<email>gerhorst@cs.fau.de</email>
</author>
<published>2023-02-27T15:08:54Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2ba1e4a623bf4f0dfb3602f11c00715731455f7e'/>
<id>urn:sha1:2ba1e4a623bf4f0dfb3602f11c00715731455f7e</id>
<content type='text'>
[ Upstream commit c679bbd611c08b0559ffae079330bc4e5574696a ]

RFC8259 ("The JavaScript Object Notation (JSON) Data Interchange
Format") only specifies \", \\, \/, \b, \f, \n, \r, and \r as valid
two-character escape sequences. This does not include \', which is not
required in JSON because it exclusively uses double quotes as string
separators.

Solidus (/) may be escaped, but does not have to. Only reverse
solidus (\), double quotes ("), and the control characters have to be
escaped. Therefore, with this fix, bpftool correctly supports all valid
two-character escape sequences (but still does not support characters
that require multi-character escape sequences).

Witout this fix, attempting to load a JSON file generated by bpftool
using Python 3.10.6's default json.load() may fail with the error
"Invalid \escape" if the file contains the invalid escaped single
quote (\').

Fixes: b66e907cfee2 ("tools: bpftool: copy JSON writer from iproute2 repository")
Signed-off-by: Luis Gerhorst &lt;gerhorst@cs.fau.de&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Reviewed-by: Quentin Monnet &lt;quentin@isovalent.com&gt;
Link: https://lore.kernel.org/bpf/20230227150853.16863-1-gerhorst@cs.fau.de
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>tools bpftool: Fix compilation error with new binutils</title>
<updated>2023-03-17T07:49:04Z</updated>
<author>
<name>Andres Freund</name>
<email>andres@anarazel.de</email>
</author>
<published>2022-08-01T01:38:33Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4441a90091931fd81607567961dc122f24f735bb'/>
<id>urn:sha1:4441a90091931fd81607567961dc122f24f735bb</id>
<content type='text'>
commit 600b7b26c07a070d0153daa76b3806c1e52c9e00 upstream.

binutils changed the signature of init_disassemble_info(), which now causes
compilation to fail for tools/bpf/bpftool/jit_disasm.c, e.g. on debian
unstable.

Relevant binutils commit:

  https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=60a3da00bd5407f07

Wire up the feature test and switch to init_disassemble_info_compat(),
which were introduced in prior commits, fixing the compilation failure.

I verified that bpftool can still disassemble bpf programs, both with an
old and new dis-asm.h API. There are no output changes for plain and json
formats. When comparing the output from old binutils (2.35)
to new bintuils with the patch (upstream snapshot) there are a few output
differences, but they are unrelated to this patch. An example hunk is:

     2f:	pop    %r14
     31:	pop    %r13
     33:	pop    %rbx
  -  34:	leaveq
  -  35:	retq
  +  34:	leave
  +  35:	ret

Signed-off-by: Andres Freund &lt;andres@anarazel.de&gt;
Acked-by: Quentin Monnet &lt;quentin@isovalent.com&gt;
Cc: Alexei Starovoitov &lt;ast@kernel.org&gt;
Cc: Ben Hutchings &lt;benh@debian.org&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Quentin Monnet &lt;quentin@isovalent.com&gt;
Cc: Sedat Dilek &lt;sedat.dilek@gmail.com&gt;
Cc: bpf@vger.kernel.org
Link: http://lore.kernel.org/lkml/20220622181918.ykrs5rsnmx3og4sv@alap3.anarazel.de
Link: https://lore.kernel.org/r/20220801013834.156015-8-andres@anarazel.de
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Cc: Hauke Mehrtens &lt;hauke@hauke-m.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>tools bpf_jit_disasm: Fix compilation error with new binutils</title>
<updated>2023-03-17T07:49:04Z</updated>
<author>
<name>Andres Freund</name>
<email>andres@anarazel.de</email>
</author>
<published>2022-08-01T01:38:31Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1c27fab243333821375e4d63128d60093fdbe149'/>
<id>urn:sha1:1c27fab243333821375e4d63128d60093fdbe149</id>
<content type='text'>
commit 96ed066054abf11c7d3e106e3011a51f3f1227a3 upstream.

binutils changed the signature of init_disassemble_info(), which now causes
compilation to fail for tools/bpf/bpf_jit_disasm.c, e.g. on debian
unstable.

Relevant binutils commit:

  https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=60a3da00bd5407f07

Wire up the feature test and switch to init_disassemble_info_compat(),
which were introduced in prior commits, fixing the compilation failure.

I verified that bpf_jit_disasm can still disassemble bpf programs, both
with the old and new dis-asm.h API. With old binutils there's no change in
output before/after this patch. When comparing the output from old
binutils (2.35) to new bintuils with the patch (upstream snapshot) there
are a few output differences, but they are unrelated to this patch. An
example hunk is:

     f4:	mov    %r14,%rsi
     f7:	mov    %r15,%rdx
     fa:	mov    $0x2a,%ecx
  -  ff:	callq  0xffffffffea8c4988
  +  ff:	call   0xffffffffea8c4988
    104:	test   %rax,%rax
    107:	jge    0x0000000000000110
    109:	xor    %eax,%eax
  - 10b:	jmpq   0x0000000000000073
  + 10b:	jmp    0x0000000000000073
    110:	cmp    $0x16,%rax

However, I had to use an older kernel to generate the bpf_jit_enabled =
2 output, as that has been broken since 5.18 / 1022a5498f6f745c ("bpf,
x86_64: Use bpf_jit_binary_pack_alloc").

  https://lore.kernel.org/20220703030210.pmjft7qc2eajzi6c@alap3.anarazel.de

Signed-off-by: Andres Freund &lt;andres@anarazel.de&gt;
Acked-by: Quentin Monnet &lt;quentin@isovalent.com&gt;
Cc: Alexei Starovoitov &lt;ast@kernel.org&gt;
Cc: Ben Hutchings &lt;benh@debian.org&gt;
Cc: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Cc: Quentin Monnet &lt;quentin@isovalent.com&gt;
Cc: Sedat Dilek &lt;sedat.dilek@gmail.com&gt;
Cc: bpf@vger.kernel.org
Link: http://lore.kernel.org/lkml/20220622181918.ykrs5rsnmx3og4sv@alap3.anarazel.de
Link: https://lore.kernel.org/r/20220801013834.156015-6-andres@anarazel.de
Signed-off-by: Arnaldo Carvalho de Melo &lt;acme@redhat.com&gt;
Cc: Hauke Mehrtens &lt;hauke@hauke-m.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>bpftool: profile online CPUs instead of possible</title>
<updated>2023-03-10T08:39:13Z</updated>
<author>
<name>Tonghao Zhang</name>
<email>tong@infragraf.org</email>
</author>
<published>2023-02-02T13:17:01Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=9af6aa18b4e8cdcfbd85fee2c80d43fb1bf9672c'/>
<id>urn:sha1:9af6aa18b4e8cdcfbd85fee2c80d43fb1bf9672c</id>
<content type='text'>
[ Upstream commit 377c16fa3f3c60d21e4b05314c8be034ce37f2eb ]

The number of online cpu may be not equal to possible cpu.
"bpftool prog profile" can not create pmu event on possible
but on online cpu.

$ dmidecode -s system-product-name
PowerEdge R620
$ cat /sys/devices/system/cpu/possible
0-47
$ cat /sys/devices/system/cpu/online
0-31

Disable cpu dynamically:
$ echo 0 &gt; /sys/devices/system/cpu/cpuX/online

If one cpu is offline, perf_event_open will return ENODEV.
To fix this issue:
* check value returned and skip offline cpu.
* close pmu_fd immediately on error path, avoid fd leaking.

Fixes: 47c09d6a9f67 ("bpftool: Introduce "prog profile" command")
Signed-off-by: Tonghao Zhang &lt;tong@infragraf.org&gt;
Cc: Quentin Monnet &lt;quentin@isovalent.com&gt;
Cc: Alexei Starovoitov &lt;ast@kernel.org&gt;
Cc: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Cc: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Cc: Martin KaFai Lau &lt;martin.lau@linux.dev&gt;
Cc: Song Liu &lt;song@kernel.org&gt;
Cc: Yonghong Song &lt;yhs@fb.com&gt;
Cc: John Fastabend &lt;john.fastabend@gmail.com&gt;
Cc: KP Singh &lt;kpsingh@kernel.org&gt;
Cc: Stanislav Fomichev &lt;sdf@google.com&gt;
Cc: Hao Luo &lt;haoluo@google.com&gt;
Cc: Jiri Olsa &lt;jolsa@kernel.org&gt;
Acked-by: John Fastabend &lt;john.fastabend@gmail.com&gt;
Link: https://lore.kernel.org/r/20230202131701.29519-1-tong@infragraf.org
Signed-off-by: Martin KaFai Lau &lt;martin.lau@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>bpftool: Fix NULL pointer dereference when pin {PROG, MAP, LINK} without FILE</title>
<updated>2022-11-16T08:58:15Z</updated>
<author>
<name>Pu Lehui</name>
<email>pulehui@huawei.com</email>
</author>
<published>2022-11-02T08:40:34Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=6dcdd1b68b7f9333d48d48fc77b75e7f235f6a4a'/>
<id>urn:sha1:6dcdd1b68b7f9333d48d48fc77b75e7f235f6a4a</id>
<content type='text'>
[ Upstream commit 34de8e6e0e1f66e431abf4123934a2581cb5f133 ]

When using bpftool to pin {PROG, MAP, LINK} without FILE,
segmentation fault will occur. The reson is that the lack
of FILE will cause strlen to trigger NULL pointer dereference.
The corresponding stacktrace is shown below:

do_pin
  do_pin_any
    do_pin_fd
      mount_bpffs_for_pin
        strlen(name) &lt;- NULL pointer dereference

Fix it by adding validation to the common process.

Fixes: 75a1e792c335 ("tools: bpftool: Allow all prog/map handles for pinning objects")
Signed-off-by: Pu Lehui &lt;pulehui@huawei.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Reviewed-by: Quentin Monnet &lt;quentin@isovalent.com&gt;
Link: https://lore.kernel.org/bpf/20221102084034.3342995-1-pulehui@huaweicloud.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
