<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/samples/bpf, branch v6.8-rc5</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>work around gcc bugs with 'asm goto' with outputs</title>
<updated>2024-02-09T23:57:48+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2024-02-09T20:39:31+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=4356e9f841f7fbb945521cef3577ba394c65f3fc'/>
<id>4356e9f841f7fbb945521cef3577ba394c65f3fc</id>
<content type='text'>
We've had issues with gcc and 'asm goto' before, and we created a
'asm_volatile_goto()' macro for that in the past: see commits
3f0116c3238a ("compiler/gcc4: Add quirk for 'asm goto' miscompilation
bug") and a9f180345f53 ("compiler/gcc4: Make quirk for
asm_volatile_goto() unconditional").

Then, much later, we ended up removing the workaround in commit
43c249ea0b1e ("compiler-gcc.h: remove ancient workaround for gcc PR
58670") because we no longer supported building the kernel with the
affected gcc versions, but we left the macro uses around.

Now, Sean Christopherson reports a new version of a very similar
problem, which is fixed by re-applying that ancient workaround.  But the
problem in question is limited to only the 'asm goto with outputs'
cases, so instead of re-introducing the old workaround as-is, let's
rename and limit the workaround to just that much less common case.

It looks like there are at least two separate issues that all hit in
this area:

 (a) some versions of gcc don't mark the asm goto as 'volatile' when it
     has outputs:

        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98619
        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110420

     which is easy to work around by just adding the 'volatile' by hand.

 (b) Internal compiler errors:

        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110422

     which are worked around by adding the extra empty 'asm' as a
     barrier, as in the original workaround.

but the problem Sean sees may be a third thing since it involves bad
code generation (not an ICE) even with the manually added 'volatile'.

but the same old workaround works for this case, even if this feels a
bit like voodoo programming and may only be hiding the issue.

Reported-and-tested-by: Sean Christopherson &lt;seanjc@google.com&gt;
Link: https://lore.kernel.org/all/20240208220604.140859-1-seanjc@google.com/
Cc: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Cc: Uros Bizjak &lt;ubizjak@gmail.com&gt;
Cc: Jakub Jelinek &lt;jakub@redhat.com&gt;
Cc: Andrew Pinski &lt;quic_apinski@quicinc.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We've had issues with gcc and 'asm goto' before, and we created a
'asm_volatile_goto()' macro for that in the past: see commits
3f0116c3238a ("compiler/gcc4: Add quirk for 'asm goto' miscompilation
bug") and a9f180345f53 ("compiler/gcc4: Make quirk for
asm_volatile_goto() unconditional").

Then, much later, we ended up removing the workaround in commit
43c249ea0b1e ("compiler-gcc.h: remove ancient workaround for gcc PR
58670") because we no longer supported building the kernel with the
affected gcc versions, but we left the macro uses around.

Now, Sean Christopherson reports a new version of a very similar
problem, which is fixed by re-applying that ancient workaround.  But the
problem in question is limited to only the 'asm goto with outputs'
cases, so instead of re-introducing the old workaround as-is, let's
rename and limit the workaround to just that much less common case.

It looks like there are at least two separate issues that all hit in
this area:

 (a) some versions of gcc don't mark the asm goto as 'volatile' when it
     has outputs:

        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98619
        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110420

     which is easy to work around by just adding the 'volatile' by hand.

 (b) Internal compiler errors:

        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110422

     which are worked around by adding the extra empty 'asm' as a
     barrier, as in the original workaround.

but the problem Sean sees may be a third thing since it involves bad
code generation (not an ICE) even with the manually added 'volatile'.

but the same old workaround works for this case, even if this feels a
bit like voodoo programming and may only be hiding the issue.

Reported-and-tested-by: Sean Christopherson &lt;seanjc@google.com&gt;
Link: https://lore.kernel.org/all/20240208220604.140859-1-seanjc@google.com/
Cc: Nick Desaulniers &lt;ndesaulniers@google.com&gt;
Cc: Uros Bizjak &lt;ubizjak@gmail.com&gt;
Cc: Jakub Jelinek &lt;jakub@redhat.com&gt;
Cc: Andrew Pinski &lt;quic_apinski@quicinc.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>samples/bpf: Use %lu format specifier for unsigned long values</title>
<updated>2023-12-20T14:28:59+00:00</updated>
<author>
<name>Colin Ian King</name>
<email>colin.i.king@gmail.com</email>
</author>
<published>2023-12-19T15:23:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=32f24938a1fce95fce314c1fa9a72af74588ea6c'/>
<id>32f24938a1fce95fce314c1fa9a72af74588ea6c</id>
<content type='text'>
Currently %ld format specifiers are being used for unsigned long
values. Fix this by using %lu instead. Cleans up cppcheck warnings:

warning: %ld in format string (no. 1) requires 'long' but the argument
type is 'unsigned long'. [invalidPrintfArgType_sint]

Signed-off-by: Colin Ian King &lt;colin.i.king@gmail.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Reviewed-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Link: https://lore.kernel.org/bpf/20231219152307.368921-1-colin.i.king@gmail.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently %ld format specifiers are being used for unsigned long
values. Fix this by using %lu instead. Cleans up cppcheck warnings:

warning: %ld in format string (no. 1) requires 'long' but the argument
type is 'unsigned long'. [invalidPrintfArgType_sint]

Signed-off-by: Colin Ian King &lt;colin.i.king@gmail.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Reviewed-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Link: https://lore.kernel.org/bpf/20231219152307.368921-1-colin.i.king@gmail.com
</pre>
</div>
</content>
</entry>
<entry>
<title>samples/bpf: Allow building with custom bpftool</title>
<updated>2023-10-26T13:32:13+00:00</updated>
<author>
<name>Viktor Malik</name>
<email>vmalik@redhat.com</email>
</author>
<published>2023-10-25T06:19:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=37db10bc247d5d0b448babd7ff386f092246e732'/>
<id>37db10bc247d5d0b448babd7ff386f092246e732</id>
<content type='text'>
samples/bpf build its own bpftool boostrap to generate vmlinux.h as well
as some BPF objects. This is a redundant step if bpftool has been
already built, so update samples/bpf/Makefile such that it accepts a
path to bpftool passed via the BPFTOOL variable. The approach is
practically the same as tools/testing/selftests/bpf/Makefile uses.

Signed-off-by: Viktor Malik &lt;vmalik@redhat.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Link: https://lore.kernel.org/bpf/bd746954ac271b02468d8d951ff9f11e655d485b.1698213811.git.vmalik@redhat.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
samples/bpf build its own bpftool boostrap to generate vmlinux.h as well
as some BPF objects. This is a redundant step if bpftool has been
already built, so update samples/bpf/Makefile such that it accepts a
path to bpftool passed via the BPFTOOL variable. The approach is
practically the same as tools/testing/selftests/bpf/Makefile uses.

Signed-off-by: Viktor Malik &lt;vmalik@redhat.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Link: https://lore.kernel.org/bpf/bd746954ac271b02468d8d951ff9f11e655d485b.1698213811.git.vmalik@redhat.com
</pre>
</div>
</content>
</entry>
<entry>
<title>samples/bpf: Fix passing LDFLAGS to libbpf</title>
<updated>2023-10-26T13:32:13+00:00</updated>
<author>
<name>Viktor Malik</name>
<email>vmalik@redhat.com</email>
</author>
<published>2023-10-25T06:19:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f56bcfadf7d6d56b099726df4fc262b76486b0e0'/>
<id>f56bcfadf7d6d56b099726df4fc262b76486b0e0</id>
<content type='text'>
samples/bpf/Makefile passes LDFLAGS=$(TPROGS_LDFLAGS) to libbpf build
without surrounding quotes, which may cause compilation errors when
passing custom TPROGS_USER_LDFLAGS.

For example:

    $ make -C samples/bpf/ TPROGS_USER_LDFLAGS="-Wl,--as-needed -specs=/usr/lib/gcc/x86_64-redhat-linux/13/libsanitizer.spec"
    make: Entering directory './samples/bpf'
    make -C ../../ M=./samples/bpf BPF_SAMPLES_PATH=./samples/bpf
    make[1]: Entering directory '.'
    make -C ./samples/bpf/../../tools/lib/bpf RM='rm -rf' EXTRA_CFLAGS="-Wall -O2 -Wmissing-prototypes -Wstrict-prototypes  -I./usr/include -I./tools/testing/selftests/bpf/ -I./samples/bpf/libbpf/include -I./tools/include -I./tools/perf -I./tools/lib -DHAVE_ATTR_TEST=0" \
            LDFLAGS=-Wl,--as-needed -specs=/usr/lib/gcc/x86_64-redhat-linux/13/libsanitizer.spec srctree=./samples/bpf/../../ \
            O= OUTPUT=./samples/bpf/libbpf/ DESTDIR=./samples/bpf/libbpf prefix= \
            ./samples/bpf/libbpf/libbpf.a install_headers
    make: invalid option -- 'c'
    make: invalid option -- '='
    make: invalid option -- '/'
    make: invalid option -- 'u'
    make: invalid option -- '/'
    [...]

Fix the error by properly quoting $(TPROGS_LDFLAGS).

Suggested-by: Donald Zickus &lt;dzickus@redhat.com&gt;
Signed-off-by: Viktor Malik &lt;vmalik@redhat.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Link: https://lore.kernel.org/bpf/c690de6671cc6c983d32a566d33fd7eabd18b526.1698213811.git.vmalik@redhat.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
samples/bpf/Makefile passes LDFLAGS=$(TPROGS_LDFLAGS) to libbpf build
without surrounding quotes, which may cause compilation errors when
passing custom TPROGS_USER_LDFLAGS.

For example:

    $ make -C samples/bpf/ TPROGS_USER_LDFLAGS="-Wl,--as-needed -specs=/usr/lib/gcc/x86_64-redhat-linux/13/libsanitizer.spec"
    make: Entering directory './samples/bpf'
    make -C ../../ M=./samples/bpf BPF_SAMPLES_PATH=./samples/bpf
    make[1]: Entering directory '.'
    make -C ./samples/bpf/../../tools/lib/bpf RM='rm -rf' EXTRA_CFLAGS="-Wall -O2 -Wmissing-prototypes -Wstrict-prototypes  -I./usr/include -I./tools/testing/selftests/bpf/ -I./samples/bpf/libbpf/include -I./tools/include -I./tools/perf -I./tools/lib -DHAVE_ATTR_TEST=0" \
            LDFLAGS=-Wl,--as-needed -specs=/usr/lib/gcc/x86_64-redhat-linux/13/libsanitizer.spec srctree=./samples/bpf/../../ \
            O= OUTPUT=./samples/bpf/libbpf/ DESTDIR=./samples/bpf/libbpf prefix= \
            ./samples/bpf/libbpf/libbpf.a install_headers
    make: invalid option -- 'c'
    make: invalid option -- '='
    make: invalid option -- '/'
    make: invalid option -- 'u'
    make: invalid option -- '/'
    [...]

Fix the error by properly quoting $(TPROGS_LDFLAGS).

Suggested-by: Donald Zickus &lt;dzickus@redhat.com&gt;
Signed-off-by: Viktor Malik &lt;vmalik@redhat.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Link: https://lore.kernel.org/bpf/c690de6671cc6c983d32a566d33fd7eabd18b526.1698213811.git.vmalik@redhat.com
</pre>
</div>
</content>
</entry>
<entry>
<title>samples/bpf: Allow building with custom CFLAGS/LDFLAGS</title>
<updated>2023-10-26T13:32:12+00:00</updated>
<author>
<name>Viktor Malik</name>
<email>vmalik@redhat.com</email>
</author>
<published>2023-10-25T06:19:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=870f09f1ba3014e2c157b14299c172b4bb716638'/>
<id>870f09f1ba3014e2c157b14299c172b4bb716638</id>
<content type='text'>
Currently, it is not possible to specify custom flags when building
samples/bpf. The flags are defined in TPROGS_CFLAGS/TPROGS_LDFLAGS
variables, however, when trying to override those from the make command,
compilation fails.

For example, when trying to build with PIE:

    $ make -C samples/bpf TPROGS_CFLAGS="-fpie" TPROGS_LDFLAGS="-pie"

This is because samples/bpf/Makefile updates these variables, especially
appends include paths to TPROGS_CFLAGS and these updates are overridden
by setting the variables from the make command.

This patch introduces variables TPROGS_USER_CFLAGS/TPROGS_USER_LDFLAGS
for this purpose, which can be set from the make command and their
values are propagated to TPROGS_CFLAGS/TPROGS_LDFLAGS.

Signed-off-by: Viktor Malik &lt;vmalik@redhat.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Link: https://lore.kernel.org/bpf/2d81100b830a71f0e72329cc7781edaefab75f62.1698213811.git.vmalik@redhat.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, it is not possible to specify custom flags when building
samples/bpf. The flags are defined in TPROGS_CFLAGS/TPROGS_LDFLAGS
variables, however, when trying to override those from the make command,
compilation fails.

For example, when trying to build with PIE:

    $ make -C samples/bpf TPROGS_CFLAGS="-fpie" TPROGS_LDFLAGS="-pie"

This is because samples/bpf/Makefile updates these variables, especially
appends include paths to TPROGS_CFLAGS and these updates are overridden
by setting the variables from the make command.

This patch introduces variables TPROGS_USER_CFLAGS/TPROGS_USER_LDFLAGS
for this purpose, which can be set from the make command and their
values are propagated to TPROGS_CFLAGS/TPROGS_LDFLAGS.

Signed-off-by: Viktor Malik &lt;vmalik@redhat.com&gt;
Signed-off-by: Daniel Borkmann &lt;daniel@iogearbox.net&gt;
Link: https://lore.kernel.org/bpf/2d81100b830a71f0e72329cc7781edaefab75f62.1698213811.git.vmalik@redhat.com
</pre>
</div>
</content>
</entry>
<entry>
<title>samples: bpf: Fix syscall_tp openat argument</title>
<updated>2023-10-23T16:58:15+00:00</updated>
<author>
<name>Denys Zagorui</name>
<email>dzagorui@cisco.com</email>
</author>
<published>2023-10-19T11:35:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=69a19170303ff2f802049be94cfcf62f714002a3'/>
<id>69a19170303ff2f802049be94cfcf62f714002a3</id>
<content type='text'>
This modification doesn't change behaviour of the syscall_tp
But such code is often used as a reference so it should be
correct anyway

Signed-off-by: Denys Zagorui &lt;dzagorui@cisco.com&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20231019113521.4103825-1-dzagorui@cisco.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This modification doesn't change behaviour of the syscall_tp
But such code is often used as a reference so it should be
correct anyway

Signed-off-by: Denys Zagorui &lt;dzagorui@cisco.com&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20231019113521.4103825-1-dzagorui@cisco.com
</pre>
</div>
</content>
</entry>
<entry>
<title>samples/bpf: Add -fsanitize=bounds to userspace programs</title>
<updated>2023-09-28T16:31:05+00:00</updated>
<author>
<name>Ruowen Qin</name>
<email>ruowenq2@illinois.edu</email>
</author>
<published>2023-09-27T04:50:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9e09b75079e229b08f12a732712100fdb9af8cab'/>
<id>9e09b75079e229b08f12a732712100fdb9af8cab</id>
<content type='text'>
The sanitizer flag, which is supported by both clang and gcc, would make
it easier to debug array index out-of-bounds problems in these programs.

Make the Makfile smarter to detect ubsan support from the compiler and
add the '-fsanitize=bounds' accordingly.

Suggested-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Jinghao Jia &lt;jinghao@linux.ibm.com&gt;
Signed-off-by: Jinghao Jia &lt;jinghao7@illinois.edu&gt;
Signed-off-by: Ruowen Qin &lt;ruowenq2@illinois.edu&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Tested-by: Jiri Olsa &lt;jolsa@kernel.org&gt;
Acked-by: Jiri Olsa &lt;jolsa@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20230927045030.224548-2-ruowenq2@illinois.edu
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The sanitizer flag, which is supported by both clang and gcc, would make
it easier to debug array index out-of-bounds problems in these programs.

Make the Makfile smarter to detect ubsan support from the compiler and
add the '-fsanitize=bounds' accordingly.

Suggested-by: Mimi Zohar &lt;zohar@linux.ibm.com&gt;
Signed-off-by: Jinghao Jia &lt;jinghao@linux.ibm.com&gt;
Signed-off-by: Jinghao Jia &lt;jinghao7@illinois.edu&gt;
Signed-off-by: Ruowen Qin &lt;ruowenq2@illinois.edu&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Tested-by: Jiri Olsa &lt;jolsa@kernel.org&gt;
Acked-by: Jiri Olsa &lt;jolsa@kernel.org&gt;
Link: https://lore.kernel.org/bpf/20230927045030.224548-2-ruowenq2@illinois.edu
</pre>
</div>
</content>
</entry>
<entry>
<title>samples/bpf: syscall_tp_user: Fix array out-of-bound access</title>
<updated>2023-09-21T21:32:47+00:00</updated>
<author>
<name>Jinghao Jia</name>
<email>jinghao@linux.ibm.com</email>
</author>
<published>2023-09-17T21:42:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=9220c3ef6fefbf18f24aeedb1142a642b3de0596'/>
<id>9220c3ef6fefbf18f24aeedb1142a642b3de0596</id>
<content type='text'>
Commit 06744f24696e ("samples/bpf: Add openat2() enter/exit tracepoint
to syscall_tp sample") added two more eBPF programs to support the
openat2() syscall. However, it did not increase the size of the array
that holds the corresponding bpf_links. This leads to an out-of-bound
access on that array in the bpf_object__for_each_program loop and could
corrupt other variables on the stack. On our testing QEMU, it corrupts
the map1_fds array and causes the sample to fail:

  # ./syscall_tp
  prog #0: map ids 4 5
  verify map:4 val: 5
  map_lookup failed: Bad file descriptor

Dynamically allocate the array based on the number of programs reported
by libbpf to prevent similar inconsistencies in the future

Fixes: 06744f24696e ("samples/bpf: Add openat2() enter/exit tracepoint to syscall_tp sample")
Signed-off-by: Jinghao Jia &lt;jinghao@linux.ibm.com&gt;
Signed-off-by: Ruowen Qin &lt;ruowenq2@illinois.edu&gt;
Signed-off-by: Jinghao Jia &lt;jinghao7@illinois.edu&gt;
Link: https://lore.kernel.org/r/20230917214220.637721-4-jinghao7@illinois.edu
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 06744f24696e ("samples/bpf: Add openat2() enter/exit tracepoint
to syscall_tp sample") added two more eBPF programs to support the
openat2() syscall. However, it did not increase the size of the array
that holds the corresponding bpf_links. This leads to an out-of-bound
access on that array in the bpf_object__for_each_program loop and could
corrupt other variables on the stack. On our testing QEMU, it corrupts
the map1_fds array and causes the sample to fail:

  # ./syscall_tp
  prog #0: map ids 4 5
  verify map:4 val: 5
  map_lookup failed: Bad file descriptor

Dynamically allocate the array based on the number of programs reported
by libbpf to prevent similar inconsistencies in the future

Fixes: 06744f24696e ("samples/bpf: Add openat2() enter/exit tracepoint to syscall_tp sample")
Signed-off-by: Jinghao Jia &lt;jinghao@linux.ibm.com&gt;
Signed-off-by: Ruowen Qin &lt;ruowenq2@illinois.edu&gt;
Signed-off-by: Jinghao Jia &lt;jinghao7@illinois.edu&gt;
Link: https://lore.kernel.org/r/20230917214220.637721-4-jinghao7@illinois.edu
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>samples/bpf: syscall_tp_user: Rename num_progs into nr_tests</title>
<updated>2023-09-21T21:32:47+00:00</updated>
<author>
<name>Jinghao Jia</name>
<email>jinghao@linux.ibm.com</email>
</author>
<published>2023-09-17T21:42:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0ee352fe0d28015cab161b04d202fa3231c0ba3b'/>
<id>0ee352fe0d28015cab161b04d202fa3231c0ba3b</id>
<content type='text'>
The variable name num_progs causes confusion because that variable
really controls the number of rounds the test should be executed.

Rename num_progs into nr_tests for the sake of clarity.

Signed-off-by: Jinghao Jia &lt;jinghao@linux.ibm.com&gt;
Signed-off-by: Ruowen Qin &lt;ruowenq2@illinois.edu&gt;
Signed-off-by: Jinghao Jia &lt;jinghao7@illinois.edu&gt;
Link: https://lore.kernel.org/r/20230917214220.637721-3-jinghao7@illinois.edu
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The variable name num_progs causes confusion because that variable
really controls the number of rounds the test should be executed.

Rename num_progs into nr_tests for the sake of clarity.

Signed-off-by: Jinghao Jia &lt;jinghao@linux.ibm.com&gt;
Signed-off-by: Ruowen Qin &lt;ruowenq2@illinois.edu&gt;
Signed-off-by: Jinghao Jia &lt;jinghao7@illinois.edu&gt;
Link: https://lore.kernel.org/r/20230917214220.637721-3-jinghao7@illinois.edu
Signed-off-by: Alexei Starovoitov &lt;ast@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>selftests/bpf: trace_helpers.c: Optimize kallsyms cache</title>
<updated>2023-09-08T23:22:41+00:00</updated>
<author>
<name>Rong Tao</name>
<email>rongtao@cestc.cn</email>
</author>
<published>2023-09-07T01:59:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c698eaebdf4759d297343f20e00172610207b754'/>
<id>c698eaebdf4759d297343f20e00172610207b754</id>
<content type='text'>
Static ksyms often have problems because the number of symbols exceeds the
MAX_SYMS limit. Like changing the MAX_SYMS from 300000 to 400000 in
commit e76a014334a6("selftests/bpf: Bump and validate MAX_SYMS") solves
the problem somewhat, but it's not the perfect way.

This commit uses dynamic memory allocation, which completely solves the
problem caused by the limitation of the number of kallsyms. At the same
time, add APIs:

    load_kallsyms_local()
    ksym_search_local()
    ksym_get_addr_local()
    free_kallsyms_local()

There are used to solve the problem of selftests/bpf updating kallsyms
after attach new symbols during testmod testing.

Signed-off-by: Rong Tao &lt;rongtao@cestc.cn&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Acked-by: Jiri Olsa &lt;jolsa@kernel.org&gt;
Acked-by: Stanislav Fomichev &lt;sdf@google.com&gt;
Link: https://lore.kernel.org/bpf/tencent_C9BDA68F9221F21BE4081566A55D66A9700A@qq.com
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Static ksyms often have problems because the number of symbols exceeds the
MAX_SYMS limit. Like changing the MAX_SYMS from 300000 to 400000 in
commit e76a014334a6("selftests/bpf: Bump and validate MAX_SYMS") solves
the problem somewhat, but it's not the perfect way.

This commit uses dynamic memory allocation, which completely solves the
problem caused by the limitation of the number of kallsyms. At the same
time, add APIs:

    load_kallsyms_local()
    ksym_search_local()
    ksym_get_addr_local()
    free_kallsyms_local()

There are used to solve the problem of selftests/bpf updating kallsyms
after attach new symbols during testmod testing.

Signed-off-by: Rong Tao &lt;rongtao@cestc.cn&gt;
Signed-off-by: Andrii Nakryiko &lt;andrii@kernel.org&gt;
Acked-by: Jiri Olsa &lt;jolsa@kernel.org&gt;
Acked-by: Stanislav Fomichev &lt;sdf@google.com&gt;
Link: https://lore.kernel.org/bpf/tencent_C9BDA68F9221F21BE4081566A55D66A9700A@qq.com
</pre>
</div>
</content>
</entry>
</feed>
