| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
[Changes from V2:
- no-strict-aliasing is only applied when building with GCC.
- cpumask_failure.c is excluded, as it doesn't use __imm_insn.]
The __imm_insn macro is defined in bpf_misc.h as:
#define __imm_insn(name, expr) [name]"i"(*(long *)&(expr))
This may lead to type-punning and strict aliasing rules violations in
it's typical usage where the address of a struct bpf_insn is passed as
expr, like in:
__imm_insn(st_mem,
BPF_ST_MEM(BPF_W, BPF_REG_1, offsetof(struct __sk_buff, mark), 42))
Where:
#define BPF_ST_MEM(SIZE, DST, OFF, IMM) \
((struct bpf_insn) { \
.code = BPF_ST | BPF_SIZE(SIZE) | BPF_MEM, \
.dst_reg = DST, \
.src_reg = 0, \
.off = OFF, \
.imm = IMM })
In all the actual instances of this in the BPF selftests the value is
fed to a volatile asm statement as soon as it gets read from memory,
and thus it is unlikely anti-aliasing rules breakage may lead to
misguided optimizations.
However, GCC detects the potential problem (indirectly) by issuing a
warning stating that a temporary <Uxxxxxx> is used uninitialized,
where the temporary corresponds to the memory read by *(long *).
This patch adds -fno-strict-aliasing to the compilation flags of the
particular selftests that do type punning via __imm_insn, only for
GCC.
Tested in master bpf-next.
No regressions.
Signed-off-by: Jose E. Marchesi <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Yonghong Song <[email protected]>
Cc: Eduard Zingerman <[email protected]>
Acked-by: Yonghong Song <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
[Changes from V1:
- The warning to disable is -Wmaybe-uninitialized, not -Wuninitialized.
- This warning is only supported in GCC.]
The BPF selftest verifier_global_subprogs.c contains code that
purposedly performs out of bounds access to memory, to check whether
the kernel verifier is able to catch them. For example:
__noinline int global_unsupp(const int *mem)
{
if (!mem)
return 0;
return mem[100]; /* BOOM */
}
With -O1 and higher and no inlining, GCC notices this fact and emits a
"maybe uninitialized" warning. This is by design. Note that the
emission of these warnings is highly dependent on the precise
optimizations that are performed.
This patch adds a compiler pragma to verifier_global_subprogs.c to
ignore these warnings.
Tested in bpf-next master.
No regressions.
Signed-off-by: Jose E. Marchesi <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Yonghong Song <[email protected]>
Cc: Eduard Zingerman <[email protected]>
Acked-by: Yonghong Song <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
When LSE atomics are available, BPF atomic instructions are implemented
as single ARM64 atomic instructions, therefore it is easy to enable
these in bpf_arena using the currently available exception handling
setup.
LL_SC atomics use loops and therefore would need more work to enable in
bpf_arena.
Enable LSE atomics based instructions in bpf_arena and use the
bpf_jit_supports_insn() callback to reject atomics in bpf_arena if LSE
atomics are not available.
All atomics and arena_atomics selftests are passing:
[root@ip-172-31-2-216 bpf]# ./test_progs -a atomics,arena_atomics
#3/1 arena_atomics/add:OK
#3/2 arena_atomics/sub:OK
#3/3 arena_atomics/and:OK
#3/4 arena_atomics/or:OK
#3/5 arena_atomics/xor:OK
#3/6 arena_atomics/cmpxchg:OK
#3/7 arena_atomics/xchg:OK
#3 arena_atomics:OK
#10/1 atomics/add:OK
#10/2 atomics/sub:OK
#10/3 atomics/and:OK
#10/4 atomics/or:OK
#10/5 atomics/xor:OK
#10/6 atomics/cmpxchg:OK
#10/7 atomics/xchg:OK
#10 atomics:OK
Summary: 2/14 PASSED, 0 SKIPPED, 0 FAILED
Signed-off-by: Puranjay Mohan <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
When creating the topology for the test, three veth pairs are created in
the initial network namespace before being moved to one of the network
namespaces created by the test.
On systems where systemd-udev uses MACAddressPolicy=persistent (default
since systemd version 242), this will result in some net devices having
the same MAC address since they were created with the same name in the
initial network namespace. In turn, this leads to arping / ndisc6
failing since packets are dropped by the bridge's loopback filter.
Fix by creating each net device in the correct network namespace instead
of moving it there from the initial network namespace.
Reported-by: Jakub Kicinski <[email protected]>
Closes: https://lore.kernel.org/netdev/[email protected]/
Fixes: 7648ac72dcd7 ("selftests: net: Add bridge neighbor suppression test")
Signed-off-by: Ido Schimmel <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Without this change the created netns instances are not cleared after
this script execution. To fix this problem the cleanup_all_ns function
from ../lib.sh is called.
Signed-off-by: Lukasz Majewski <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
Add tests covering following functionality on KSZ9477 switch family:
- default port priority
- global DSCP to Internal Priority Mapping
- apptrust configuration
This script was tested on KSZ9893R
Signed-off-by: Oleksij Rempel <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
|
|
When building with clang, via:
make LLVM=1 -C tools/testing/selftest
...clang warns about three variables that are not initialized in all
cases:
1) The opt_ipproto_off variable is used uninitialized if "testname" is
not "ip". Willem de Bruijn pointed out that this is an actual bug, and
suggested the fix that I'm using here (thanks!).
2) The addr_len is used uninitialized, but only in the assert case,
which bails out, so this is harmless.
3) The family variable in add_listener() is only used uninitialized in
the error case (neither IPv4 nor IPv6 is specified), so it's also
harmless.
Fix by initializing each variable.
Signed-off-by: John Hubbard <[email protected]>
Reviewed-by: Willem de Bruijn <[email protected]>
Acked-by: Mat Martineau <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
connection attempt
Netdev CI reports occasional failures with this test
("ERROR: ns2-dX6bUE did not pick up tcp connection from peer").
Add explicit busywait call until the initial connection attempt shows
up in conntrack rather than a one-shot 'must exist' check.
Signed-off-by: Florian Westphal <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Drive-by clean up, we shouldn't use meaningless "test_" prefix for
subtest names.
Signed-off-by: Andrii Nakryiko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin KaFai Lau <[email protected]>
|
|
Add a simple test that validates that libbpf will reject isolated
struct_ops program early with helpful warning message.
Also validate that explicit use of such BPF program through BPF skeleton
after BPF object is open won't trigger any warnings.
Signed-off-by: Andrii Nakryiko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin KaFai Lau <[email protected]>
|
|
Extend libbpf's pre-load checks for BPF programs, detecting more typical
conditions that are destinated to cause BPF program failure. This is an
opportunity to provide more helpful and actionable error message to
users, instead of potentially very confusing BPF verifier log and/or
error.
In this case, we detect struct_ops BPF program that was not referenced
anywhere, but still attempted to be loaded (according to libbpf logic).
Suggest that the program might need to be used in some struct_ops
variable. User will get a message of the following kind:
libbpf: prog 'test_1_forgotten': SEC("struct_ops") program isn't referenced anywhere, did you forget to use it?
Suggested-by: Tejun Heo <[email protected]>
Signed-off-by: Andrii Nakryiko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin KaFai Lau <[email protected]>
|
|
strerror_r(), used from libbpf-specific libbpf_strerror_r() wrapper is
documented to return error in two different ways, depending on glibc
version. Take that into account when handling strerror_r()'s own errors,
which happens when we pass some non-standard (internal) kernel error to
it. Before this patch we'd have "ERROR: strerror_r(524)=22", which is
quite confusing. Now for the same situation we'll see a bit less
visually scary "unknown error (-524)".
At least we won't confuse user with irrelevant EINVAL (22).
Signed-off-by: Andrii Nakryiko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin KaFai Lau <[email protected]>
|
|
Add a test which tests the case that was just fixed. Kernel has full
type information about callback, but user explicitly nulls out the
reference to declaratively set BPF program reference.
Signed-off-by: Andrii Nakryiko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin KaFai Lau <[email protected]>
|
|
There is yet another corner case where user can set STRUCT_OPS program
reference in STRUCT_OPS map to NULL, but libbpf will fail to disable
autoload for such BPF program. This time it's the case of "new" kernel
which has type information about callback field, but user explicitly
nulled-out program reference from user-space after opening BPF object.
Fix, hopefully, the last remaining unhandled case.
Fixes: 0737df6de946 ("libbpf: better fix for handling nulled-out struct_ops program")
Fixes: f973fccd43d3 ("libbpf: handle nulled-out program in struct_ops correctly")
Signed-off-by: Andrii Nakryiko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin KaFai Lau <[email protected]>
|
|
libbpf ensures that BPF program references set in map->st_ops->progs[i]
during open phase are always valid STRUCT_OPS programs. This is done in
bpf_object__collect_st_ops_relos(). So there is no need to double-check
that in bpf_map__init_kern_struct_ops().
Simplify the code by removing unnecessary check. Also, we avoid using
local prog variable to keep code similar to the upcoming fix, which adds
similar logic in another part of bpf_map__init_kern_struct_ops().
Signed-off-by: Andrii Nakryiko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Martin KaFai Lau <[email protected]>
|
|
The test_xdp_noinline.c contains 2 functions that use more then 5
arguments. This patch collapses the 2 last arguments in an array.
Also in GCC and ipa_sra optimization increases the number of arguments
used in function encap_v4. This pass disables the optimization for that
particular file.
Signed-off-by: Cupertino Miranda <[email protected]>
Signed-off-by: Andrii Nakryiko <[email protected]>
Acked-by: Yonghong Song <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
|
|
This patch adds support to specify CFLAGS per source file and per test
runner.
Signed-off-by: Cupertino Miranda <[email protected]>
Signed-off-by: Andrii Nakryiko <[email protected]>
Acked-by: Yonghong Song <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
|
|
The vmlinux.h file generated by bpftool makes use of compiler pragmas
in order to install the CO-RE preserve_access_index in all the struct
types derived from the BTF info:
#ifndef __VMLINUX_H__
#define __VMLINUX_H__
#ifndef BPF_NO_PRESERVE_ACCESS_INDEX
#pragma clang attribute push (__attribute__((preserve_access_index)), apply_t = record
#endif
[... type definitions generated from kernel BTF ... ]
#ifndef BPF_NO_PRESERVE_ACCESS_INDEX
#pragma clang attribute pop
#endif
The `clang attribute push/pop' pragmas are specific to clang/llvm and
are not supported by GCC.
At the moment the BTF dumping services in libbpf do not support
dicriminating between types dumped because they are directly referred
and types dumped because they are dependencies. A suitable API is
being worked now. See [1] and [2].
In the interim, this patch changes the selftests/bpf Makefile so it
passes -DBPF_NO_PRESERVE_ACCESS_INDEX to GCC when it builds the
selftests. This workaround is temporary, and may have an impact on
the results of the GCC-built tests.
[1] https://lore.kernel.org/bpf/[email protected]/T/#u
[2] https://lore.kernel.org/bpf/[email protected]/T/#u
Tested in bpf-next master.
No regressions.
Signed-off-by: Jose E. Marchesi <[email protected]>
Signed-off-by: Andrii Nakryiko <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
|
|
This patch modifies selftests/bpf/Makefile to pass -Wno-attributes to
GCC. This is because of the following attributes which are ignored:
- btf_decl_tag
- btf_type_tag
There are many of these. At the moment none of these are
recognized/handled by gcc-bpf.
We are aware that btf_decl_tag is necessary for some of the
selftest harness to communicate test failure/success. Support for
it is in progress in GCC upstream:
https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650482.html
However, the GCC master branch is not yet open, so the series
above (currently under review upstream) wont be able to make it
there until 14.1 gets released, probably mid next week.
As for btf_type_tag, more extensive work will be needed in GCC
upstream to support it in both BTF and DWARF. We have a WIP big
patch for that, but that is not needed to compile/build the
selftests.
- used
There are SEC macros defined in the selftests as:
#define SEC(N) __attribute__((section(N),used))
The SEC macro is used for both functions and global variables.
According to the GCC documentation `used' attribute is really only
meaningful for functions, and it warns when the attribute is used
for other global objects, like for example ctl_array in
test_xdp_noinline.c.
Ignoring this is benign.
- align_value
In progs/test_cls_redirect.c:127 there is:
typedef uint8_t *net_ptr __attribute__((align_value(8)));
GCC warns that it is ignoring this attribute, because it is not
implemented by GCC.
I think ignoring this attribute in GCC is benign, because according
to the clang documentation [1] its purpose seems to be merely
declarative and doesn't seem to translate into extra checks at
run-time, only to perhaps better optimized code ("runtime behavior
is undefined if the pointed memory object is not aligned to the
specified alignment").
[1] https://clang.llvm.org/docs/AttributeReference.html#align-value
Tested in bpf-next master.
Signed-off-by: Jose E. Marchesi <[email protected]>
Signed-off-by: Andrii Nakryiko <[email protected]>
Acked-by: Yonghong Song <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
|
|
An object defined as `static' defaults to hidden visibility. If
additionally the visibility(__weak__) compiler attribute is applied to
the declaration of the object, GCC warns that the attribute gets
ignored.
This patch removes the only instance of this problem among the BPF
selftests.
Tested in bpf-next master.
Signed-off-by: Jose E. Marchesi <[email protected]>
Signed-off-by: Andrii Nakryiko <[email protected]>
Acked-by: Yonghong Song <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
|
|
udev-hid-bpf is still not installed everywhere, and we should probably
not assume it is installed automatically.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Peter Hutterer <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>
|
|
The only interesting bit is the HAT switch, and we use a BPF program
to fix it. So ensure this works correctly.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Peter Hutterer <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>
|
|
More in line with the other test_* files.
No code change
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Peter Hutterer <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>
|
|
We need to slightly change base_device.py for supporting HID-BPF,
so instead of monkey patching, let's just embed it in the kernel tree.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Peter Hutterer <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>
|
|
This tablets gets a lot of things wrong:
- the secondary button is reported through Secondary Tip Switch
- the third button is reported through Invert
We need to add some out of proximity intermediate state when moving
back and forth with the eraser mode as it can only be triggered by
physically returning the pen, meaning that the tolerated transitions
can never happen.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Peter Hutterer <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>
|
|
The values are taken from the HID-BPF file.
Basically we are recomputing the array provided there.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Peter Hutterer <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>
|
|
Those tablets don't need special initialization, but are reporting
the events with the wrong usages:
- tip switch is used when the eraser should be used
- eraser is used instead of the secondary barrel switch
Add tests for those so we don't regress in the future.
Currently we set x/y tilt to 0 to not trigger the bpf program
compensate_coordinates_by_tilt()
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Peter Hutterer <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>
|
|
All the *_WITH*BUTTON states were almost identical except for the
button itself.
I need to add a new device with a third button, and adding a bunch of
states is going to be quite cumbersome.
So convert the `button` parameter of PenState as a boolean, and store
which button is the target as an argument to all functions that need it.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Peter Hutterer <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>
|
|
few required changes:
- we need to count how many times a udev 'bind' event happens
- we need to tell `udev-hid-bpf` to not automatically attach the
provided HID-BPF objects
- we need to manually attach the ones from the kernel tree, and wait
for the second udev 'bind' event to happen
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Peter Hutterer <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>
|
|
We need to slightly change base_device.py for supporting HID-BPF,
so instead of monkey patching, let's just embed it in the kernel tree.
Link: https://lore.kernel.org/r/[email protected]
Reviewed-by: Peter Hutterer <[email protected]>
Signed-off-by: Benjamin Tissoires <[email protected]>
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into soc/drivers
RISC-V SoC Kconfig Updates for v6.10
A few different bits of SoC-related Kconfig work. The first part of
this is shared with the DT updates - the modification of all SOC_CANAAN
users to SOC_CANAAN_K210 to split the existing m-mode nommu k210 away
from the k230 that is able to be used in a "common" kernel.
The other thing here is the removal of most of the SOC_VENDOR options,
with their ARCH_VENDOR equivalents that've been waiting in the wings for
1 year+ now made visible. Due a lapse on my part when originally adding
the ARCH_VENDOR stuff, the Microchip transition isn't complete - the
_POLARFIRE was a mistake to keep as there's gonna be non-PolarFire
RISC-V stuff from Microchip soonTM.
Signed-off-by: Conor Dooley <[email protected]>
* tag 'riscv-config-for-v6.10' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux:
riscv: config: enable ARCH_CANAAN in defconfig
RISC-V: drop SOC_VIRT for ARCH_VIRT
RISC-V: drop SOC_SIFIVE for ARCH_SIFIVE
RISC-V: drop SOC_MICROCHIP_POLARFIRE for ARCH_MICROCHIP
RISC-V: Drop unused SOC_CANAAN
reset: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210
pinctrl: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210
clk: k210: Deprecate SOC_CANAAN and use SOC_CANAAN_K210
soc: canaan: Deprecate SOC_CANAAN and use SOC_CANAAN_K210 for K210
riscv: Kconfig.socs: Split ARCH_CANAAN and SOC_CANAAN_K210
Link: https://lore.kernel.org/r/20240503-mardi-underling-3d81a9f97329@spud
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
Added a test for bound computation in MUL when non constant
values are used and both registers have bounded ranges.
Signed-off-by: Cupertino Miranda <[email protected]>
Acked-by: Eduard Zingerman <[email protected]>
Acked-by: Andrii Nakryiko <[email protected]>
Cc: Yonghong Song <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: David Faust <[email protected]>
Cc: Jose Marchesi <[email protected]>
Cc: Elena Zannoni <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
Added a test for bound computation in XOR and OR when non constant
values are used and both registers have bounded ranges.
Signed-off-by: Cupertino Miranda <[email protected]>
Acked-by: Eduard Zingerman <[email protected]>
Cc: Yonghong Song <[email protected]>
Cc: Alexei Starovoitov <[email protected]>
Cc: David Faust <[email protected]>
Cc: Jose Marchesi <[email protected]>
Cc: Elena Zannoni <[email protected]>
Cc: Andrii Nakryiko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Alexei Starovoitov <[email protected]>
|
|
When building either tools/bpf/bpftool, or tools/testing/selftests/hid,
(the same Makefile is used for these), clang generates many instances of
the following:
"clang: warning: -lLLVM-17: 'linker' input unused"
Quentin points out that the LLVM version is only required in $(LIBS),
not in $(CFLAGS), so the fix is to remove it from CFLAGS.
Suggested-by: Quentin Monnet <[email protected]>
Signed-off-by: John Hubbard <[email protected]>
Signed-off-by: Andrii Nakryiko <[email protected]>
Acked-by: Quentin Monnet <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
|
|
Cast operation has a higher precedence than addition. The code here
wants to zero the 2nd half of the 64-bit metadata, but due to a pointer
arithmetic mistake, it writes the zero at offset 16 instead.
Just adding parentheses around "data + 4" would fix this, but I think
this will be slightly better readable with array syntax.
I was unable to test this with tools/testing/selftests/bpf/vmtest.sh,
because my glibc is newer than glibc in the provided VM image.
So I just checked the difference in the compiled code.
objdump -S tools/testing/selftests/bpf/xdp_do_redirect.test.o:
- *((__u32 *)data) = 0x42; /* metadata test value */
+ ((__u32 *)data)[0] = 0x42; /* metadata test value */
be7: 48 8d 85 30 fc ff ff lea -0x3d0(%rbp),%rax
bee: c7 00 42 00 00 00 movl $0x42,(%rax)
- *((__u32 *)data + 4) = 0;
+ ((__u32 *)data)[1] = 0;
bf4: 48 8d 85 30 fc ff ff lea -0x3d0(%rbp),%rax
- bfb: 48 83 c0 10 add $0x10,%rax
+ bfb: 48 83 c0 04 add $0x4,%rax
bff: c7 00 00 00 00 00 movl $0x0,(%rax)
Fixes: 5640b6d89434 ("selftests/bpf: fix "metadata marker" getting overwritten by the netstack")
Signed-off-by: Michal Schmidt <[email protected]>
Signed-off-by: Andrii Nakryiko <[email protected]>
Reviewed-by: Toke Høiland-Jørgensen <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
|
|
The bpf programs that this patch changes require the BPF_PROG macro.
The BPF_PROG macro is defined in the libbpf's bpf_tracing.h.
Some tests include bpf_tcp_helpers.h which includes bpf_tracing.h.
They don't need other things from bpf_tcp_helpers.h other than
bpf_tracing.h. This patch simplifies it by directly including
the bpf_tracing.h.
The motivation of this unnecessary code churn is to retire
the bpf_tcp_helpers.h by directly using vmlinux.h. Right now,
the main usage of the bpf_tcp_helpers.h is the partial kernel
socket definitions (e.g. socket, sock, tcp_sock). While the test
cases continue to grow, fields are kept adding to those partial
socket definitions (e.g. the recent bpf_cc_cubic.c test which
tried to extend bpf_tcp_helpers.c but eventually used the
vmlinux.h instead).
The idea is to retire bpf_tcp_helpers.c and consistently use
vmlinux.h for the tests that require the kernel sockets. This
patch tackles the obvious tests that can directly use bpf_tracing.h
instead of bpf_tcp_helpers.h.
Signed-off-by: Martin KaFai Lau <[email protected]>
Signed-off-by: Andrii Nakryiko <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
|
|
Align the behavior for gcc and clang builds by interpreting unset
`ARCH` and `CROSS_COMPILE` variables in `LLVM` builds as a sign that the
user wants to build for the host architecture.
This patch preserves the properties that setting the `ARCH` variable to an
unknown value will trigger an error that complains about insufficient
information, and that a set `CROSS_COMPILE` variable will override the
target triple that is determined based on presence/absence of `ARCH`.
When compiling with clang, i.e., `LLVM` is set, an unset `ARCH` variable in
combination with an unset `CROSS_COMPILE` variable, i.e., compiling for
the host architecture, leads to compilation failures since `lib.mk` can
not determine the clang target triple. In this case, the following error
message is displayed for each subsystem that does not set `ARCH` in its
own Makefile before including `lib.mk` (lines wrapped at 75 chrs):
make[1]: Entering directory '/mnt/build/linux/tools/testing/selftests/
sysctl'
../lib.mk:33: *** Specify CROSS_COMPILE or add '--target=' option to
lib.mk. Stop.
make[1]: Leaving directory '/mnt/build/linux/tools/testing/selftests/
sysctl'
In the same scenario a gcc build would default to the host architecture,
i.e., it would use plain `gcc`.
Fixes: 795285ef2425 ("selftests: Fix clang cross compilation")
Reviewed-by: Mark Brown <[email protected]>
Signed-off-by: Valentin Obst <[email protected]>
Reviewed-by: John Hubbard <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|
|
First of all, in order to build with clang at all, one must first apply
Valentin Obst's build fix for LLVM [1]. Once that is done, then when
building with clang, via:
make LLVM=1 -C tools/testing/selftests
...the following error occurs:
clang: error: cannot specify -o when generating multiple output files
This is because clang, unlike gcc, won't accept invocations of this
form:
clang file1.c header2.h
Fix this by using selftests/lib.mk facilities for tracking local header
file dependencies: add them to LOCAL_HDRS, leaving only the .c files to
be passed to the compiler.
[1] https://lore.kernel.org/all/20240329-selftests-libmk-llvm-rfc-v1-1-2f9ed7d1c49f@valentinobst.de/
Fixes: 8e289f454289 ("selftests/resctrl: Add resctrl.h into build deps")
Cc: Ilpo Järvinen <[email protected]>
Signed-off-by: John Hubbard <[email protected]>
Acked-by: Reinette Chatre <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|
|
First of all, in order to build with clang at all, one must first apply
Valentin Obst's build fix for LLVM [1]. Once that is done, then when
building with clang, via:
make LLVM=1 -C tools/testing/selftests
...the following error occurs:
clang: error: cannot specify -o when generating multiple output files
This is because clang, unlike gcc, won't accept invocations of this
form:
clang file1.c header2.h
While trying to fix this, I noticed that:
a) selftests/lib.mk already avoids the problem, and
b) The binderfs Makefile indavertently bypasses the selftests/lib.mk
build system, and quitely uses Make's implicit build rules for .c files
instead.
The Makefile attempts to set up both a dependency and a source file,
neither of which was needed, because lib.mk is able to automatically
handle both. This line:
binderfs_test: binderfs_test.c
...causes Make's implicit rules to run, which builds binderfs_test
without ever looking at lib.mk.
Fix this by simply deleting the "binderfs_test:" Makefile target and
letting lib.mk handle it instead.
[1] https://lore.kernel.org/all/20240329-selftests-libmk-llvm-rfc-v1-1-2f9ed7d1c49f@valentinobst.de/
Fixes: 6e29225af902 ("binderfs: port tests to test harness infrastructure")
Cc: Christian Brauner <[email protected]>
Signed-off-by: John Hubbard <[email protected]>
Reviewed-by: Christian Brauner <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|
|
Commit f7d5bcd35d42 ("selftests: kselftest: Mark functions that
unconditionally call exit() as __noreturn") marked functions that call
exit() as __noreturn but it did not change the return type of these
functions from 'void' to 'int' like it should have (since a noreturn
function by definition cannot return an integer because it does not
return...) because there were many tests that return the result of the
ksft_exit functions, even though it has never been used due to calling
exit().
Now that all uses of 'return ksft_exit...()' have been cleaned up
properly, change the types of the ksft_exit...() functions to void to
match their __noreturn nature.
Reviewed-by: Muhammad Usama Anjum <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|
|
After commit f7d5bcd35d42 ("selftests: kselftest: Mark functions that
unconditionally call exit() as __noreturn"), ksft_exit_...() functions
are marked as __noreturn, which means the return type should not be
'int' but 'void' because they are not returning anything (and never were
since exit() has always been called).
To facilitate updating the return type of these functions, remove
'return' before the call to ksft_exit_pass(), as __noreturn prevents the
compiler from warning that a caller of ksft_exit_pass() does not return
a value because the program will terminate upon calling these functions.
Reviewed-by: Muhammad Usama Anjum <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|
|
After commit f7d5bcd35d42 ("selftests: kselftest: Mark functions that
unconditionally call exit() as __noreturn"), ksft_exit_...() functions
are marked as __noreturn, which means the return type should not be
'int' but 'void' because they are not returning anything (and never were
since exit() has always been called).
To facilitate updating the return type of these functions, remove
'return' before the calls to ksft_exit_...(), as __noreturn prevents the
compiler from warning that a caller of the ksft_exit functions does not
return a value because the program will terminate upon calling these
functions.
Reviewed-by: Muhammad Usama Anjum <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|
|
After commit f7d5bcd35d42 ("selftests: kselftest: Mark functions that
unconditionally call exit() as __noreturn"), ksft_exit_...() functions
are marked as __noreturn, which means the return type should not be
'int' but 'void' because they are not returning anything (and never were
since exit() has always been called).
To facilitate updating the return type of these functions, remove
'return' before the call to ksft_exit_pass(), as __noreturn prevents the
compiler from warning that a caller of ksft_exit_pass() does not return
a value because the program will terminate upon calling these functions
(which is what the comment alluded to as well).
Reviewed-by: Muhammad Usama Anjum <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|
|
After commit f7d5bcd35d42 ("selftests: kselftest: Mark functions that
unconditionally call exit() as __noreturn"), ksft_exit_...() functions
are marked as __noreturn, which means the return type should not be
'int' but 'void' because they are not returning anything (and never were
since exit() has always been called).
To facilitate updating the return type of these functions, remove
'return' before the calls to ksft_exit_skip(), as __noreturn prevents
the compiler from warning that a caller of ksft_exit_skip() does not
return a value because the program will terminate upon calling these
functions.
Reviewed-by: Muhammad Usama Anjum <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|
|
After commit f7d5bcd35d42 ("selftests: kselftest: Mark functions that
unconditionally call exit() as __noreturn"), ksft_exit_...() functions
are marked as __noreturn, which means the return type should not be
'int' but 'void' because they are not returning anything (and never were
since exit() has always been called).
To facilitate updating the return type of these functions, remove
'return' before the calls to ksft_exit_{pass,fail}(), as __noreturn
prevents the compiler from warning that a caller of the ksft_exit
functions does not return a value because the program will terminate
upon calling these functions.
Just removing 'return' would have resulted in
!ret ? ksft_exit_pass() : ksft_exit_fail();
so convert that into the more idiomatic
if (ret)
ksft_exit_fail();
ksft_exit_pass();
Reviewed-by: Muhammad Usama Anjum <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|
|
After commit f7d5bcd35d42 ("selftests: kselftest: Mark functions that
unconditionally call exit() as __noreturn"), ksft_exit_...() functions
are marked as __noreturn, which means the return type should not be
'int' but 'void' because they are not returning anything (and never were
since exit() has always been called).
To facilitate updating the return type of these functions, remove
'return' before the calls to ksft_exit_...(), as __noreturn prevents the
compiler from warning that a caller of the ksft_exit functions does not
return a value because the program will terminate upon calling these
functions.
Reviewed-by: Muhammad Usama Anjum <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|
|
After commit f7d5bcd35d42 ("selftests: kselftest: Mark functions that
unconditionally call exit() as __noreturn"), ksft_exit_...() functions
are marked as __noreturn, which means the return type should not be
'int' but 'void' because they are not returning anything (and never were
since exit() has always been called).
To facilitate updating the return type of these functions, remove
'return' before the calls to ksft_exit_pass(), as __noreturn prevents
the compiler from warning that a caller of ksft_exit_pass() does not
return a value because the program will terminate upon calling these
functions.
Reviewed-by: Muhammad Usama Anjum <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|
|
After commit f7d5bcd35d42 ("selftests: kselftest: Mark functions that
unconditionally call exit() as __noreturn"), ksft_exit_...() functions
are marked as __noreturn, which means the return type should not be
'int' but 'void' because they are not returning anything (and never were
since exit() has always been called).
To facilitate updating the return type of these functions, remove
'return' before the calls to ksft_exit_...(), as __noreturn prevents the
compiler from warning that a caller of the ksft_exit functions does not
return a value because the program will terminate upon calling these
functions.
Reviewed-by: Muhammad Usama Anjum <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|
|
After commit f7d5bcd35d42 ("selftests: kselftest: Mark functions that
unconditionally call exit() as __noreturn"), ksft_exit_...() functions
are marked as __noreturn, which means the return type should not be
'int' but 'void' because they are not returning anything (and never were
since exit() has always been called).
To facilitate updating the return type of these functions, remove
'return' before the calls to ksft_exit_{pass,fail}(), as __noreturn
prevents the compiler from warning that a caller of the ksft_exit
functions does not return a value because the program will terminate
upon calling these functions.
Just removing 'return' would have resulted in
!ret ? ksft_exit_pass() : ksft_exit_fail();
so convert that into the more idiomatic
if (ret)
ksft_exit_fail();
ksft_exit_pass();
Reviewed-by: Muhammad Usama Anjum <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Nathan Chancellor <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|
|
There is one use of bash specific syntax in the script. Change it to the
equivalent POSIX syntax. This doesn't change functionality and allows
the test to be run on shells other than bash.
Reported-by: Mike Looijmans <[email protected]>
Closes: https://lore.kernel.org/all/[email protected]/
Fixes: 4a679c5afca0 ("selftests: Add test to verify power supply properties")
Signed-off-by: Nícolas F. R. A. Prado <[email protected]>
Reviewed-by: Muhammad Usama Anjum <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|