====================
Implement mechanism to signal other threads
This set implements a kfunc called bpf_send_signal_task() that is similar
to sigqueue() as it can send a signal along with a cookie to a thread or
thread group.
The send_signal selftest has been updated to also test this new kfunc under
all contexts.
Changes in v5:
v4: https://lore.kernel.org/all/20241008114940.44305-1-puranjay@kernel.org/
- Call copy_siginfo() only if work->has_siginfo is true in
bpf_send_signal_common()
- Add Acked-by: Andrii Nakryiko <andrii@kernel.org>
Changes in v4:
v3: https://lore.kernel.org/all/20241007103426.128923-1-puranjay@kernel.org/
- Fix the selftest to make it work for big-endian archs.
- Fix a build warning on 32-bit archs.
- Some style changes and code refactors suggested by Andrii
Changes in v3:
v2: https://lore.kernel.org/all/20240926115328.105634-1-puranjay@kernel.org/
- make the cookie u64 instead of int.
- re use code from bpf_send_signal_common
Changes in v2:
v1: https://lore.kernel.org/bpf/20240724113944.75977-1-puranjay@kernel.org/
- Convert to a kfunc
- Add mechanism to send a cookie with the signal.
====================
Puranjay Mohan [Wed, 16 Oct 2024 08:41:36 +0000 (08:41 +0000)]
selftests/bpf: Augment send_signal test with remote signaling
Add testcases to test bpf_send_signal_task(). In these new test cases,
the main process triggers the BPF program and the forked process
receives the signals. The target process's signal handler receives a
cookie from the bpf program.
Puranjay Mohan [Wed, 16 Oct 2024 08:41:35 +0000 (08:41 +0000)]
bpf: Implement bpf_send_signal_task() kfunc
Implement bpf_send_signal_task kfunc that is similar to
bpf_send_signal_thread and bpf_send_signal helpers but can be used to
send signals to other threads and processes. It also supports sending a
cookie with the signal similar to sigqueue().
If the receiving process establishes a handler for the signal using the
SA_SIGINFO flag to sigaction(), then it can obtain this cookie via the
si_value field of the siginfo_t structure passed as the second argument
to the handler.
====================
bpf: Fix tailcall infinite loop caused by freplace
Previously, I addressed a tailcall infinite loop issue related to
trampolines[0].
In this patchset, I resolve a similar issue where a tailcall infinite loop
can occur due to the combination of tailcalls and freplace programs. The
fix prevents adding extended programs to the prog_array map and blocks the
extension of a tail callee program with freplace.
Key changes:
1. If a program or its subprogram has been extended by an freplace program,
it can no longer be updated to a prog_array map.
2. If a program has been added to a prog_array map, neither it nor its
subprograms can be extended by an freplace program.
Additionally, an extension program should not be tailcalled. As a result,
return -EINVAL if the program has a type of BPF_PROG_TYPE_EXT when adding
it to a prog_array map.
Changes:
v7 -> v8:
* Address comment from Alexei:
* guard(mutex) should not hold range all the way through
bpf_arch_text_poke().
* Address suggestion from Xu Kuohai:
* Extension prog should not be tailcalled independently.
v6 -> v7:
* Address comments from Alexei:
* Rewrite commit message more imperative and consice with AI.
* Extend bpf_trampoline_link_prog() and bpf_trampoline_unlink_prog()
to link and unlink target prog for freplace prog.
* Use guard(mutex)(&tgt_prog->aux->ext_mutex) instead of
mutex_lock()&mutex_unlock() pair.
* Address comment from Eduard:
* Remove misplaced "Reported-by" and "Closes" tags.
v5 -> v6:
* Fix a build warning reported by kernel test robot.
v4 -> v5:
* Move code of linking/unlinking target prog of freplace to trampoline.c.
* Address comments from Alexei:
* Change type of prog_array_member_cnt to u64.
* Combine two patches to one.
v3 -> v4:
* Address comments from Eduard:
* Rename 'tail_callee_cnt' to 'prog_array_member_cnt'.
* Add comment to 'prog_array_member_cnt'.
* Use a mutex to protect 'is_extended' and 'prog_array_member_cnt'.
v2 -> v3:
* Address comments from Alexei:
* Stop hacking JIT.
* Prevent the specific use case at attach/update time.
v1 -> v2:
* Address comment from Eduard:
* Explain why nop5 and xor/nop3 are swapped at prologue.
* Address comment from Alexei:
* Disallow attaching tail_call_reachable freplace prog to
not-tail_call_reachable target in verifier.
* Update "bpf, arm64: Fix tailcall infinite loop caused by freplace" with
latest arm64 JIT code.
Leon Hwang [Tue, 15 Oct 2024 15:02:07 +0000 (23:02 +0800)]
selftests/bpf: Add test to verify tailcall and freplace restrictions
Add a test case to ensure that attaching a tail callee program with an
freplace program fails, and that updating an extended program to a
prog_array map is also prohibited.
This test is designed to prevent the potential infinite loop issue caused
by the combination of tail calls and freplace, ensuring the correct
behavior and stability of the system.
Additionally, fix the broken tailcalls/tailcall_freplace selftest
because an extension prog should not be tailcalled.
Leon Hwang [Tue, 15 Oct 2024 15:02:06 +0000 (23:02 +0800)]
bpf: Prevent tailcall infinite loop caused by freplace
There is a potential infinite loop issue that can occur when using a
combination of tail calls and freplace.
In an upcoming selftest, the attach target for entry_freplace of
tailcall_freplace.c is subprog_tc of tc_bpf2bpf.c, while the tail call in
entry_freplace leads to entry_tc. This results in an infinite loop:
The problem arises because the tail_call_cnt in entry_freplace resets to
zero each time entry_freplace is executed, causing the tail call mechanism
to never terminate, eventually leading to a kernel panic.
To fix this issue, the solution is twofold:
1. Prevent updating a program extended by an freplace program to a
prog_array map.
2. Prevent extending a program that is already part of a prog_array map
with an freplace program.
This ensures that:
* If a program or its subprogram has been extended by an freplace program,
it can no longer be updated to a prog_array map.
* If a program has been added to a prog_array map, neither it nor its
subprograms can be extended by an freplace program.
Moreover, an extension program should not be tailcalled. As such, return
-EINVAL if the program has a type of BPF_PROG_TYPE_EXT when adding it to a
prog_array map.
Additionally, fix a minor code style issue by replacing eight spaces with a
tab for proper formatting.
====================
bpf: Add kmem_cache iterator and kfunc
Hello,
I'm proposing a new iterator and a kfunc for the slab memory allocator
to get information of each kmem_cache like in /proc/slabinfo or
/sys/kernel/slab in more flexible way.
v5 changes
* set PTR_UNTRUSTED for return value of bpf_get_kmem_cache() (Alexei)
* add KF_RCU_PROTECTED to bpf_get_kmem_cache(). See below. (Song)
* add WARN_ON_ONCE and comment in kmem_cache_iter_seq_next() (Song)
* change kmem_cache_iter_seq functions not to call BPF on intermediate stop
* add a subtest to compare the kmem cache info with /proc/slabinfo (Alexei)
* rework kmem_cache_iter not to hold slab_mutex when running BPF (Alexei)
* add virt_addr_valid() check (Alexei)
* fix random test failure by running test with the current task (Hyeonggon)
My use case is `perf lock contention` tool which shows contended locks
but many of them are not global locks and don't have symbols. If it
can tranlate the address of the lock in a slab object to the name of
the slab, it'd be much more useful.
I'm not aware of type information in slab yet, but I was told there's
a work to associate BTF ID with it. It'd be definitely helpful to my
use case. Probably we need another kfunc to get the start address of
the object or the offset in the object from an address if the type
info is available. But I want to start with a simple thing first.
The kmem_cache_iter iterates kmem_cache objects under slab_mutex and
will be useful for userspace to prepare some work for specific slabs
like setting up filters in advance. And the bpf_get_kmem_cache()
kfunc will return a pointer to a slab from the address of a lock.
And the test code is to read from the iterator and make sure it finds
a slab cache of the task_struct for the current task.
The code is available at 'bpf/slab-iter-v5' branch in
https://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
Namhyung Kim [Thu, 10 Oct 2024 23:25:05 +0000 (16:25 -0700)]
selftests/bpf: Add a test for kmem_cache_iter
The test traverses all slab caches using the kmem_cache_iter and save
the data into slab_result array map. And check if current task's
pointer is from "task_struct" slab cache using bpf_get_kmem_cache().
Also compare the result array with /proc/slabinfo if available (when
CONFIG_SLUB_DEBUG is on). Note that many of the fields in the slabinfo
are transient, so it only compares the name and objsize fields.
Namhyung Kim [Thu, 10 Oct 2024 23:25:04 +0000 (16:25 -0700)]
mm/bpf: Add bpf_get_kmem_cache() kfunc
The bpf_get_kmem_cache() is to get a slab cache information from a
virtual address like virt_to_cache(). If the address is a pointer
to a slab object, it'd return a valid kmem_cache pointer, otherwise
NULL is returned.
It doesn't grab a reference count of the kmem_cache so the caller is
responsible to manage the access. The returned point is marked as
PTR_UNTRUSTED.
The intended use case for now is to symbolize locks in slab objects
from the lock contention tracepoints.
Namhyung Kim [Thu, 10 Oct 2024 23:25:03 +0000 (16:25 -0700)]
bpf: Add kmem_cache iterator
The new "kmem_cache" iterator will traverse the list of slab caches
and call attached BPF programs for each entry. It should check the
argument (ctx.s) if it's NULL before using it.
Now the iteration grabs the slab_mutex only if it traverse the list and
releases the mutex when it runs the BPF program. The kmem_cache entry
is protected by a refcount during the execution.
Namhyung Kim [Fri, 11 Oct 2024 17:00:21 +0000 (10:00 -0700)]
libbpf: Fix possible compiler warnings in hashmap
The hashmap__for_each_entry[_safe] is accessing 'map' as a pointer.
But it does without parentheses so passing a static hash map with an
ampersand (like '&slab_hash') will cause compiler warnings due
to unmatched types as '->' operator has a higher precedence.
Ihor Solodrai [Fri, 11 Oct 2024 15:31:07 +0000 (15:31 +0000)]
selftests/bpf: Check for timeout in perf_link test
Recently perf_link test started unreliably failing on libbpf CI:
* https://github.com/libbpf/libbpf/actions/runs/11260672407/job/31312405473
* https://github.com/libbpf/libbpf/actions/runs/11260992334/job/31315514626
* https://github.com/libbpf/libbpf/actions/runs/11263162459/job/31320458251
Part of the test is running a dummy loop for a while and then checking
for a counter incremented by the test program.
Instead of waiting for an arbitrary number of loop iterations once,
check for the test counter in a loop and use get_time_ns() helper to
enforce a 100ms timeout.
Andrii Nakryiko [Thu, 10 Oct 2024 21:17:30 +0000 (14:17 -0700)]
libbpf: never interpret subprogs in .text as entry programs
Libbpf pre-1.0 had a legacy logic of allowing singular non-annotated
(i.e., not having explicit SEC() annotation) function to be treated as
sole entry BPF program (unless there were other explicit entry
programs).
This behavior was dropped during libbpf 1.0 transition period (unless
LIBBPF_STRICT_SEC_NAME flag was unset in libbpf_mode). When 1.0 was
released and all the legacy behavior was removed, the bug slipped
through leaving this legacy behavior around.
Fix this for good, as it actually causes very confusing behavior if BPF
object file only has subprograms, but no entry programs.
====================
selftests/bpf: migrate and remove cgroup/tracing related tests
The BPF testing framework has evolved significantly over time. However,
some legacy tests in the samples/bpf directory have not kept up with
these changes. These outdated tests can cause confusion and increase
maintenance efforts.
This patchset focuses on migrating outdated cgroup and tracing-related
tests from samples/bpf to selftests/bpf, ensuring the BPF test suite
remains current and efficient. Tests that are already covered by
selftests/bpf are removed, while those not yet covered are migrated.
This includes cgroup sock create tests for setting socket attributes
and blocking socket creation, as well as the removal of redundant
cgroup and tracing tests that have been replaced by newer tests.
This patchset covers the following cgroup/tracing tests:
- test_overhead: tests the overhead of BPF programs with task_rename,
now covered by selftests and benchmark tests (rename-*). [1]
- test_override_return: tests the return override functionality, now
handled by kprobe_multi_override in selftests.
- test_probe_write_user: tests the probe_write_user functionality,
now replaced by the probe_user test in selftests.
- test_cgrp2_sock: tests cgroup BPF's ability to set sk_bound_dev_if,
mark, and priority during socket creation. Migrated to selftests as
'sock_create' since no existing tests fully cover this.
- test_cgrp2_sock2: tests blocking socket creation for specific types
(AF_INET{6}, SOCK_DGRAM, IPPROTO_ICMP{V6}). Migrated to selftests
in 'sock_create' test for coverage.
- test_current_task_under_cgroup: tests bpf_current_task_under_cgroup()
to check if a task belongs to a cgroup. Already covered by
task_under_cgroup at selftest and other cgroup ID tests.
- test_cgrp2_tc: tests bpf_skb_under_cgroup() to filter packets based
on cgroup. This behavior is now validated by cgroup_skb_sk_lookup,
which uses bpf_skb_cgroup_id, making this test redundant.
[1]: https://patchwork.kernel.org/cover/13759916
---
Changes in v2:
- commit message fix
Changes in v3:
- Makefile fix
====================
Daniel T. Lee [Fri, 11 Oct 2024 04:48:47 +0000 (04:48 +0000)]
samples/bpf: remove obsolete tracing related tests
The samples/bpf has become outdated and often does not follow up with
the latest. This commit removes obsolete tracing-related tests.
Specifically, 'test_overhead' is duplicate with selftests (and bench),
and 'test_override_return', 'test_probe_write_user' tests are obsolete
since they have been replaced by kprobe_multi_override and probe_user
from selftests respectively.
The following files are removed:
- test_overhead: tests the overhead of BPF programs with task_rename,
now covered by selftests and benchmark tests (rename-*). [1]
- test_override_return: tests the return override functionality, now
handled by kprobe_multi_override in selftests.
- test_probe_write_user: tests the probe_write_user functionality,
now replaced by the probe_user test in selftests.
This cleanup will help to streamline the testing framework by removing
redundant tests.
Daniel T. Lee [Fri, 11 Oct 2024 04:48:46 +0000 (04:48 +0000)]
samples/bpf: remove obsolete cgroup related tests
This patch removes the obsolete cgroup related tests. These tests are
now redundant because their functionality is already covered by more
modern and comprehensive tests under selftests/bpf.
The following files are removed:
- test_current_task_under_cgroup: tests bpf_current_task_under_cgroup()
to check if a task belongs to a cgroup. Already covered by
task_under_cgroup at selftest and other cgroup ID tests.
- test_cgrp2_tc: tests bpf_skb_under_cgroup() to filter packets based
on cgroup. This behavior is now validated by cgroup_skb_sk_lookup,
which uses bpf_skb_cgroup_id, making this test redundant.
By removing these outdated tests, this patch helps streamline and
modernize the test suite, avoiding duplication of test coverage.
Daniel T. Lee [Fri, 11 Oct 2024 04:48:45 +0000 (04:48 +0000)]
selftests/bpf: migrate cgroup sock create test for prohibiting sockets
This patch continues the migration and removal process for cgroup
sock_create tests to selftests.
The test being migrated verifies the ability of cgroup BPF to block the
creation of specific types of sockets using a verdict. Specifically, the
test denies socket creation when the socket is of type AF_INET{6},
SOCK_DGRAM, and IPPROTO_ICMP{V6}. If the requested socket type matches
these attributes, the cgroup BPF verdict blocks the socket creation.
As with the previous commit, this test currently lacks coverage in
selftests, so this patch migrates the functionality into the sock_create
tests under selftests. This migration ensures that the socket creation
blocking behavior with cgroup bpf program is properly tested within the
selftest framework.
Daniel T. Lee [Fri, 11 Oct 2024 04:48:44 +0000 (04:48 +0000)]
selftests/bpf: migrate cgroup sock create test for setting iface/mark/prio
This patch migrates the old test for cgroup BPF that sets
sk_bound_dev_if, mark, and priority when AF_INET{6} sockets are created.
The most closely related tests under selftests are 'test_sock' and
'sockopt'. However, these existing tests serve different purposes.
'test_sock' focuses mainly on verifying the socket binding process,
while 'sockopt' concentrates on testing the behavior of getsockopt and
setsockopt operations for various socket options.
Neither of these existing tests directly covers the ability of cgroup
BPF to set socket attributes such as sk_bound_dev_if, mark, and priority
during socket creation. To address this gap, this patch introduces a
migration of the old cgroup socket attribute test, now included as the
'sock_create' test in selftests/bpf. This ensures that the ability to
configure these attributes during socket creation is properly tested.
Zhu Jun [Thu, 10 Oct 2024 05:57:37 +0000 (22:57 -0700)]
selftests/bpf: Removed redundant fd after close in bpf_prog_load_log_buf
Removed unnecessary `fd = -1` assignments after closing file descriptors.
because it will be assigned by the function bpf_prog_load().This improves
code readability and removes redundant operations.
Martin Kelly [Thu, 10 Oct 2024 19:33:01 +0000 (12:33 -0700)]
bpf: Update bpf_override_return() comment
The documentation says CONFIG_FUNCTION_ERROR_INJECTION is supported only
on x86. This was presumably true at the time of writing, but it's now
supported on many other architectures too. Drop this statement, since
it's not correct anymore and it fits better in other documentation
anyway.
Matteo Croce [Thu, 10 Oct 2024 03:56:52 +0000 (04:56 +0100)]
bpf: fix argument type in bpf_loop documentation
The `index` argument to bpf_loop() is threaded as an u64.
This lead in a subtle verifier denial where clang cloned the argument
in another register[1].
Andrii Nakryiko [Wed, 9 Oct 2024 01:15:54 +0000 (18:15 -0700)]
libbpf: fix sym_is_subprog() logic for weak global subprogs
sym_is_subprog() is incorrectly rejecting relocations against *weak*
global subprogs. Fix that by realizing that STB_WEAK is also a global
function.
While it seems like verifier doesn't support taking an address of
non-static subprog right now, it's still best to fix support for it on
libbpf side, otherwise users will get a very confusing error during BPF
skeleton generation or static linking due to misinterpreted relocation:
libbpf: prog 'handle_tp': bad map relo against 'foo' in section '.text'
Error: failed to open BPF object file: Relocation failed
It's clearly not a map relocation, but is treated and reported as such
without this fix.
Eduard Zingerman [Thu, 3 Oct 2024 21:03:07 +0000 (14:03 -0700)]
selftests/bpf: Fix backtrace printing for selftests crashes
test_progs uses glibc specific functions backtrace() and
backtrace_symbols_fd() to print backtrace in case of SIGSEGV.
Recent commit (see fixes) updated test_progs.c to define stub versions
of the same functions with attriubte "weak" in order to allow linking
test_progs against musl libc. Unfortunately this broke the backtrace
handling for glibc builds.
As it turns out, glibc defines backtrace() and backtrace_symbols_fd()
as weak:
$ ./test_progs
[0]: Caught signal #11!
Stack trace:
<backtrace not supported>
Segmentation fault (core dumped)
Resolve this by hiding stub definitions behind __GLIBC__ macro check
instead of using "weak" attribute.
Fixes: c9a83e76b5a9 ("selftests/bpf: Fix compile if backtrace support missing in libc") Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Tested-by: Tony Ambardar <tony.ambardar@gmail.com> Reviewed-by: Tony Ambardar <tony.ambardar@gmail.com> Acked-by: Daniel Xu <dxu@dxuuu.xyz> Link: https://lore.kernel.org/bpf/20241003210307.3847907-1-eddyz87@gmail.com
Currently, if `bpftool gen object` tries to link two objects that
contains the same extern function prototype, libbpf will try to get
their (non-existent) size by calling bpf__resolve_size like extern
variables and fail with:
libbpf: global 'whatever': failed to resolve size of underlying type: -22
This should not be the case, and this series adds conditions to update
size only when the BTF kind is not function.
Fixes: a46349227cd8 ("libbpf: Add linker extern resolution support for functions and global variables") Signed-off-by: Eric Long <i@hack3r.moe>
---
Changes in v4:
- Remove redundant FUNC_PROTO check.
- Merge tests into linked_funcs.
- Link to v3: https://lore.kernel.org/r/20241001-libbpf-dup-extern-funcs-v3-0-42f7774efbf3@hack3r.moe
Changes in v3:
- Simplifiy changes and shorten subjects, according to reviews.
- Remove unused includes in selftests.
- Link to v2: https://lore.kernel.org/r/20240929-libbpf-dup-extern-funcs-v2-0-0cc81de3f79f@hack3r.moe
Changes in v2:
- Fix compile errors. Oops!
- Link to v1: https://lore.kernel.org/r/20240929-libbpf-dup-extern-funcs-v1-0-df15fbd6525b@hack3r.moe
Eric Long [Wed, 2 Oct 2024 06:25:07 +0000 (14:25 +0800)]
selftests/bpf: Test linking with duplicate extern functions
Previously when multiple BPF object files referencing the same extern
function (usually kfunc) are statically linked using `bpftool gen
object`, libbpf tries to get the nonexistent size of BTF_KIND_FUNC_PROTO
and fails. This test ensures it is fixed.
Eric Long [Wed, 2 Oct 2024 06:25:06 +0000 (14:25 +0800)]
libbpf: Do not resolve size on duplicate FUNCs
FUNCs do not have sizes, thus currently btf__resolve_size will fail
with -EINVAL. Add conditions so that we only update size when the BTF
object is not function or function prototype.
Jason Xing [Tue, 1 Oct 2024 23:32:42 +0000 (07:32 +0800)]
bpf: syscall_nrs: Disable no previous prototype warnning
In some environments (gcc treated as error in W=1, which is default), if we
make -C samples/bpf/, it will be stopped because of
"no previous prototype" error like this:
../samples/bpf/syscall_nrs.c:7:6:
error: no previous prototype for ‘syscall_defines’ [-Werror=missing-prototypes]
void syscall_defines(void)
^~~~~~~~~~~~~~~
Actually, this file meets our expectatations because it will be converted to
a .h file. In this way, it's correct. Considering the warnning stopping us
compiling, we can remove the warnning directly.
During the xdp_adjust_tail test, probabilistic failure occurs and SKB package
is discarded by the kernel. After checking the issues by tracking SKB package,
it is identified that they were caused by checksum errors. Refer to checksum
of the arch/arm64/include/asm/checksum.h for fixing.
v2: Based on Alexei Starovoitov's suggestions, it is necessary to keep the code
implementation consistent.
The prog_tests programs do not include the per-arch tools include
path, e.g. tools/arch/riscv/include. Some architectures depend those
files to build properly.
Include tools/arch/$(SUBARCH)/include in the selftests bpf build.
selftests/bpf: Emit top frequent code lines in veristat
Production BPF programs are increasing in number of instructions and states
to the point, where optimising verification process for them is necessary
to avoid running into instruction limit. Authors of those BPF programs
need to analyze verifier output, for example, collecting the most
frequent source code lines to understand which part of the program has
the biggest verification cost.
This patch introduces `--top-src-lines` flag in veristat.
`--top-src-lines=N` makes veristat output N the most popular sorce code
lines, parsed from verification log.
An example of output:
```
sudo ./veristat --top-src-lines=2 bpf_flow.bpf.o
Processing 'bpf_flow.bpf.o'...
Top source lines (_dissect):
4: (bpf_helpers.h:161) asm volatile("r1 = %[ctx]\n\t"
4: (bpf_flow.c:155) if (iph && iph->ihl == 5 &&
...
```
====================
'bpf_fastcall' attribute in vmlinux.h and bpf_helper_defs.h
The goal of this patch-set is to reflect attribute bpf_fastcall
for supported helpers and kfuncs in generated header files.
For helpers this requires a tweak for scripts/bpf_doc.py and an update
to uapi/linux/bpf.h doc-comment.
For kfuncs this requires:
- introduction of a new KF_FASTCALL flag;
- modification to pahole to read kfunc flags and generate
DECL_TAG "bpf_fastcall" for marked kfuncs;
- modification to bpftool to scan for DECL_TAG "bpf_fastcall"
presence.
In both cases the following helper macro is defined in the generated
header:
And is used to mark appropriate function prototypes. More information
about bpf_fastcall attribute could be found in [1] and [2].
Modifications to pahole are submitted separately.
[1] LLVM source tree commit: 64e464349bfc ("[BPF] introduce __attribute__((bpf_fastcall))")
[2] Linux kernel tree commit (note: feature was renamed from
no_caller_saved_registers to bpf_fastcall after this commit): 52839f31cece ("Merge branch 'no_caller_saved_registers-attribute-for-helper-calls'")
====================
Eduard Zingerman [Mon, 16 Sep 2024 09:17:10 +0000 (02:17 -0700)]
bpf: __bpf_fastcall for bpf_get_smp_processor_id in uapi
Since [1] kernel supports __bpf_fastcall attribute for helper function
bpf_get_smp_processor_id(). Update uapi definition for this helper in
order to have this attribute in the generated bpf_helper_defs.h
[1] commit 91b7fbf3936f ("bpf, x86, riscv, arm: no_caller_saved_registers for bpf_get_smp_processor_id()")
The following rules apply:
- when present, section must follow 'Return' section;
- attribute names are specified on the line following 'Attribute'
keyword;
- attribute names are separated by spaces;
- section ends with an "empty" line (" *\n").
Valid attribute names are recorded in the ATTRS map.
ATTRS maps shortcut attribute name to correct C syntax.
====================
libbpf, selftests/bpf: Support cross-endian usage
Hello all,
This patch series targets a long-standing BPF usability issue - the lack
of general cross-compilation support - by enabling cross-endian usage of
libbpf and bpftool, as well as supporting cross-endian build targets for
selftests/bpf.
Benefits include improved BPF development and testing for embedded systems
based on e.g. big-endian MIPS, more build options e.g for s390x systems,
and better accessibility to the very latest test tools e.g. 'test_progs'.
The series touches many functional areas: BTF.ext handling; object access,
introspection, and linking; generation of normal and "light" skeletons.
Initial development and testing used mips64, since this arch makes
switching the build byte-order trivial and is thus very handy for A/B
testing. However, it lacks some key features (bpf2bpf call, kfuncs, etc)
making for poor selftests/bpf coverage.
Final testing takes the kernel and selftests/bpf cross-built from x86_64
to s390x, and runs the result under QEMU/s390x. That same configuration
could also be used on kernel-patches/bpf CI for regression testing endian
support or perhaps load-sharing s390x builds across x86_64 systems.
This thread includes some background regarding testing on QEMU/s390x and
the generally favourable results:
https://lore.kernel.org/bpf/ZsEcsaa3juxxQBUf@kodidev-ubuntu/
Earlier versions and related discussion of the series are here:
Changelog:
---------
v5 -> v6: (comments from Andrii, Alexei, Eduard)
- clarify info_blob_bswap() by making it explicitly conditional on
non-native target endianness, and merge a pair of related debug
statements
- reformat debug statement in bpf_object_bswap_progs() on single line
- update existing info setup functions to validate and parse info
section metadata prior to any byte-swapping, and drop earlier added
validation checks
- rework cross-endian BTF.ext handling by using callback functions to
byte-swap different types of info records, but after initial parsing
- fix a bug always outputting BTF.ext raw data in native endianness
- include v5 "Acked-by:" from Alexei, Yonghong
v4 -> v5: (feedback from Andrii and Eduard)
- add separate functions to byte-swap info metadata and records, and
ensure ordering so record bswaps occur when metadata is native endian
- use new and existing macros to iterate through info sections/records,
and check embedded record sizes match that of info structs used
- drop use of <cough> evil callbacks
- move setting swapped_endian flag to after byte-swapping functions are
called during initialization, allowing funcs to infer endianness and
drop a 'bool native' call parameter
- simplify byte-swapping macro used to generate light skeleton, and use
internal lib funcs to swap info records instead of assuming all __u32
- change info bswap library funcs to void return
- rework/consolidate new debug statements to reduce their number
- remove some unneeded handling of impossible errors, and drop a safety
check already handled elsewhere
- add and clarify some comments
v3 -> v4:
- fix a use-after-free ELF data-handling error causing rare CI failures
- move bswap functions for func/line/core-relo records to internal header
- use bswap functions also for info blobs in light skeleton
v2 -> v3: (feedback from Andrii)
- improve some log and commit message formatting
- restructure BTF.ext endianness safety checks and byte-swapping
- use BTF.ext info record definitions for swapping, require BTF v1
- follow BTF API implementation more closely for BTF.ext
- explicitly reject loading non-native endianness program into kernel
- simplify linker output byte-order setting
- drop redundant safety checks during linking
- simplify endianness macro and improve blob setup code for light skel
- no unexpected test failures after cross-compiling x86_64 -> s390x
v1 -> v2:
- fixed a light skeleton bug causing test_progs 'map_ptr' failure
- simplified some BTF.ext related endianness logic
- remove an 'inline' usage related to CI checkpatch failure
- improve some formatting noted by checkpatch warnings
- unexpected 'test_progs' failures drop 3 -> 2 (x86_64 to s390x cross)
====================
Alan Maguire [Thu, 26 Sep 2024 14:49:48 +0000 (15:49 +0100)]
selftests/bpf: Fix uprobe_multi compilation error
When building selftests, the following was seen:
uprobe_multi.c: In function ‘trigger_uprobe’:
uprobe_multi.c:108:40: error: ‘MADV_PAGEOUT’ undeclared (first use in this function)
108 | madvise(addr, page_sz, MADV_PAGEOUT);
| ^~~~~~~~~~~~
uprobe_multi.c:108:40: note: each undeclared identifier is reported only once for each function it appears in
make: *** [Makefile:850: bpf-next/tools/testing/selftests/bpf/uprobe_multi] Error 1
...even with updated UAPI headers. It seems the above value is
defined in UAPI <linux/mman.h> but including that file triggers
other redefinition errors. Simplest solution is to add a
guarded definition, as was done for MADV_POPULATE_READ.
Fixes: 3c217a182018 ("selftests/bpf: add build ID tests") Signed-off-by: Alan Maguire <alan.maguire@oracle.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20240926144948.172090-1-alan.maguire@oracle.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Tony Ambardar [Mon, 16 Sep 2024 08:37:47 +0000 (01:37 -0700)]
selftests/bpf: Support cross-endian building
Update Makefile build rules to compile BPF programs with target endianness
rather than host byte-order. With recent changes, this allows building the
full selftests/bpf suite hosted on x86_64 and targeting s390x or mips64eb
for example.
Tony Ambardar [Mon, 16 Sep 2024 08:37:46 +0000 (01:37 -0700)]
libbpf: Support creating light skeleton of either endianness
Track target endianness in 'struct bpf_gen' and process in-memory data in
native byte-order, but on finalization convert the embedded loader BPF
insns to target endianness.
The light skeleton also includes a target-accessed data blob which is
heterogeneous and thus difficult to convert to target byte-order on
finalization. Add support functions to convert data to target endianness
as it is added to the blob.
Also add additional debug logging for data blob structure details and
skeleton loading.
Tony Ambardar [Mon, 16 Sep 2024 08:37:45 +0000 (01:37 -0700)]
libbpf: Support linking bpf objects of either endianness
Allow static linking object files of either endianness, checking that input
files have consistent byte-order, and setting output endianness from input.
Linking requires in-memory processing of programs, relocations, sections,
etc. in native endianness, and output conversion to target byte-order. This
is enabled by built-in ELF translation and recent BTF/BTF.ext endianness
functions. Further add local functions for swapping byte-order of sections
containing BPF insns.
Tony Ambardar [Mon, 16 Sep 2024 08:37:44 +0000 (01:37 -0700)]
libbpf: Support opening bpf objects of either endianness
Allow bpf_object__open() to access files of either endianness, and convert
included BPF programs to native byte-order in-memory for introspection.
Loading BPF objects of non-native byte-order is still disallowed however.
Tony Ambardar [Mon, 16 Sep 2024 08:37:43 +0000 (01:37 -0700)]
libbpf: Support BTF.ext loading and output in either endianness
Support for handling BTF data of either endianness was added in [1], but
did not include BTF.ext data for lack of use cases. Later, support for
static linking [2] provided a use case, but this feature and later ones
were restricted to native-endian usage.
Add support for BTF.ext handling in either endianness. Convert BTF.ext data
to native endianness when read into memory for further processing, and
support raw data access that restores the original byte-order for output.
Add internal header functions for byte-swapping func, line, and core info
records.
Add new API functions btf_ext__endianness() and btf_ext__set_endianness()
for query and setting byte-order, as already exist for BTF data.
[1] 3289959b97ca ("libbpf: Support BTF loading and raw data output in both endianness")
[2] 8fd27bf69b86 ("libbpf: Add BPF static linker BTF and BTF.ext support")
Tony Ambardar [Mon, 16 Sep 2024 08:37:42 +0000 (01:37 -0700)]
libbpf: Fix output .symtab byte-order during linking
Object linking output data uses the default ELF_T_BYTE type for '.symtab'
section data, which disables any libelf-based translation. Explicitly set
the ELF_T_SYM type for output to restore libelf's byte-order conversion,
noting that input '.symtab' data is already correctly translated.
Markus Elfring [Thu, 26 Sep 2024 11:30:42 +0000 (13:30 +0200)]
bpf: Call kfree(obj) only once in free_one()
A kfree() call is always used at the end of this function implementation.
Thus specify such a function call only once instead of duplicating it
in a previous if branch.
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/08987123-668c-40f3-a8ee-c3038d94f069@web.de Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Manu Bretelle [Wed, 25 Sep 2024 00:22:10 +0000 (17:22 -0700)]
selftests/bpf: vm: Add support for VIRTIO_FS
danobi/vmtest is going to migrate from using 9p to using virtio_fs to
mount the local rootfs: https://github.com/danobi/vmtest/pull/88
BPF CI uses danobi/vmtest to run bpf selftests and will need to support
VIRTIO_FS.
This change enables new kconfigs to be able to support the upcoming
danobi/vmtest.
Tested by building a new kernel with those config and confirming it
would successfully run with 9p (currently what is used by vmtest), and
with virtio_fs (using a local build of vmtest).
Tao Chen [Wed, 25 Sep 2024 15:30:12 +0000 (23:30 +0800)]
libbpf: Fix expected_attach_type set handling in program load callback
Referenced commit broke the logic of resetting expected_attach_type to
zero for allowed program types if kernel doesn't yet support such field.
We do need to overwrite and preserve expected_attach_type for
multi-uprobe though, but that can be done explicitly in
libbpf_prepare_prog_load().
Fixes: 5902da6d8a52 ("libbpf: Add uprobe multi link support to bpf_program__attach_usdt") Suggested-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Tao Chen <chen.dylane@gmail.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20240925153012.212866-1-chen.dylane@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org>
libbpf: Change log level of BTF loading error message
Reduce log level of BTF loading error to INFO if BTF is not required.
Andrii says:
Nowadays the expectation is that the BPF program will have a valid
.BTF section, so even though .BTF is "optional", I think it's fine
to emit a warning for that case (any reasonably recent Clang will
produce valid BTF).
Ihor's patch is fixing the situation with an outdated host kernel
that doesn't understand BTF. libbpf will try to "upload" the
program's BTF, but if that fails and the BPF object doesn't use
any features that require having BTF uploaded, then it's just an
information message to the user, but otherwise can be ignored.
struct btf_kind_operations are not modified in BTF.
Constifying this structures moves some data to a read-only section,
so increase overall security, especially when the structure holds
some function pointers.
On a x86_64, with allmodconfig:
Before:
======
text data bss dec hex filename
184320 7091 548 191959 2edd7 kernel/bpf/btf.o
After:
=====
text data bss dec hex filename
184896 6515 548 191959 2edd7 kernel/bpf/btf.o
Jiri Olsa [Tue, 24 Sep 2024 11:07:30 +0000 (13:07 +0200)]
selftests/bpf: Fix uprobe consumer test
With newly merged code the uprobe behaviour is slightly different
and affects uprobe consumer test.
We no longer need to check if the uprobe object is still preserved
after removing last uretprobe, because it stays as long as there's
pending/installed uretprobe instance.
This allows to run uretprobe consumers registered 'after' uprobe was
hit even if previous uretprobe got unregistered before being hit.
The uprobe object will be now removed after the last uprobe ref is
released and in such case it's held by ri->uprobe (return instance)
which is released after the uretprobe is hit.
selftests/bpf: Set vpath in Makefile to search for skels
Auto-dependencies generated for %.test.o files refer to skels using
filenames as opposed to full paths. This requires make to be able to
link this name to an actual path, because not all generated skels are
put in the working directory.
In the original patch [1], this was mitigated by this target:
First, %.lskel.h and %.subskel.h were missed, because a typical
selftests/bpf build could find these files in the working directory.
This error was detected by an out-of-tree build [2].
Second, even with missing rules added, this target causes unnecessary
rebuilds in the out-of-tree case, as X.skel.h is searched for in the
working directory, and not in the $(OUTPUT).
Using vpath directive [3] is a better solution. Instead of introducing
a separate target (X.skel.h in addition to $(TRUNNER_OUTPUT)/X.skel.h),
make is instructed to search for skels in the output, which allows make
to correctly detect that skel has already been generated.
Linus Torvalds [Fri, 4 Oct 2024 00:03:18 +0000 (17:03 -0700)]
Merge tag 'pull-fixes.ufs' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Pull ufs fix from Al Viro:
"Fix ufs_rename() braino introduced this cycle.
The 'folio_release_kmap(dir_folio, new_dir)' in ufs_rename() part of
folio conversion should've been getting a pointer to ufs directory
entry within the page, rather than a pointer to directory struct
inode..."
* tag 'pull-fixes.ufs' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
ufs_rename(): fix bogus argument of folio_release_kmap()
Johannes Weiner [Thu, 3 Oct 2024 11:29:05 +0000 (07:29 -0400)]
sched: psi: fix bogus pressure spikes from aggregation race
Brandon reports sporadic, non-sensical spikes in cumulative pressure
time (total=) when reading cpu.pressure at a high rate. This is due to
a race condition between reader aggregation and tasks changing states.
While it affects all states and all resources captured by PSI, in
practice it most likely triggers with CPU pressure, since scheduling
events are so frequent compared to other resource events.
The race context is the live snooping of ongoing stalls during a
pressure read. The read aggregates per-cpu records for stalls that
have concluded, but will also incorporate ad-hoc the duration of any
active state that hasn't been recorded yet. This is important to get
timely measurements of ongoing stalls. Those ad-hoc samples are
calculated on-the-fly up to the current time on that CPU; since the
stall hasn't concluded, it's expected that this is the minimum amount
of stall time that will enter the per-cpu records once it does.
The problem is that the path that concludes the state uses a CPU clock
read that is not synchronized against aggregators; the clock is read
outside of the seqlock protection. This allows aggregators to race and
snoop a stall with a longer duration than will actually be recorded.
With the recorded stall time being less than the last snapshot
remembered by the aggregator, a subsequent sample will underflow and
observe a bogus delta value, resulting in an erratic jump in pressure.
Fix this by moving the clock read of the state change into the seqlock
protection. This ensures no aggregation can snoop live stalls past the
time that's recorded when the state concludes.
- sctp: set sk_state back to CLOSED if autobind fails in
sctp_listen_start
- mac802154: fix potential RCU dereference issue in
mac802154_scan_worker
- eth: fec: restart PPS after link state change"
* tag 'net-6.12-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (48 commits)
sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start
dt-bindings: net: xlnx,axi-ethernet: Add missing reg minItems
doc: net: napi: Update documentation for napi_schedule_irqoff
net/ncsi: Disable the ncsi work before freeing the associated structure
net: phy: qt2025: Fix warning: unused import DeviceId
gso: fix udp gso fraglist segmentation after pull from frag_list
bridge: mcast: Fail MDB get request on empty entry
vrf: revert "vrf: Remove unnecessary RCU-bh critical section"
net: ethernet: ti: am65-cpsw: Fix forever loop in cleanup code
net: phy: realtek: Check the index value in led_hw_control_get
ppp: do not assume bh is held in ppp_channel_bridge_input()
selftests: rds: move include.sh to TEST_FILES
net: test for not too small csum_start in virtio_net_hdr_to_skb()
net: gso: fix tcp fraglist segmentation after pull from frag_list
ipv4: ip_gre: Fix drops of small packets in ipgre_xmit
net: stmmac: dwmac4: extend timeout for VLAN Tag register busy bit check
net: add more sanity checks to qdisc_pkt_len_init()
net: avoid potential underflow in qdisc_pkt_len_init() with UFO
net: ethernet: ti: cpsw_ale: Fix warning on some platforms
net: microchip: Make FDMA config symbol invisible
...
Linus Torvalds [Thu, 3 Oct 2024 16:38:16 +0000 (09:38 -0700)]
Merge tag 'v6.12-rc1-ksmbd-fixes' of git://git.samba.org/ksmbd
Pull smb server fixes from Steve French:
- small cleanup patches leveraging struct size to improve access bounds checking
* tag 'v6.12-rc1-ksmbd-fixes' of git://git.samba.org/ksmbd:
ksmbd: Use struct_size() to improve smb_direct_rdma_xmit()
ksmbd: Annotate struct copychunk_ioctl_req with __counted_by_le()
ksmbd: Use struct_size() to improve get_file_alternate_info()
Linus Torvalds [Thu, 3 Oct 2024 16:22:50 +0000 (09:22 -0700)]
Merge tag 'vfs-6.12-rc2.fixes.2' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull vfs fixes from Christian Brauner:
"vfs:
- Ensure that iter_folioq_get_pages() advances to the next slot
otherwise it will end up using the same folio with an out-of-bound
offset.
iomap:
- Dont unshare delalloc extents which can't be reflinked, and thus
can't be shared.
- Constrain the file range passed to iomap_file_unshare() directly in
iomap instead of requiring the callers to do it.
netfs:
- Use folioq_count instead of folioq_nr_slot to prevent an
unitialized value warning in netfs_clear_buffer().
- Fix missing wakeup after issuing writes by scheduling the write
collector only if all the subrequest queues are empty and thus no
writes are pending.
- Fix two minor documentation bugs"
* tag 'vfs-6.12-rc2.fixes.2' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
iomap: constrain the file range passed to iomap_file_unshare
iomap: don't bother unsharing delalloc extents
netfs: Fix missing wakeup after issuing writes
Documentation: add missing folio_queue entry
folio_queue: fix documentation
netfs: Fix a KMSAN uninit-value error in netfs_clear_buffer
iov_iter: fix advancing slot in iter_folioq_get_pages()
Xin Long [Mon, 30 Sep 2024 20:49:51 +0000 (16:49 -0400)]
sctp: set sk_state back to CLOSED if autobind fails in sctp_listen_start
In sctp_listen_start() invoked by sctp_inet_listen(), it should set the
sk_state back to CLOSED if sctp_autobind() fails due to whatever reason.
Otherwise, next time when calling sctp_inet_listen(), if sctp_sk(sk)->reuse
is already set via setsockopt(SCTP_REUSE_PORT), sctp_sk(sk)->bind_hash will
be dereferenced as sk_state is LISTENING, which causes a crash as bind_hash
is NULL.
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
RIP: 0010:sctp_inet_listen+0x7f0/0xa20 net/sctp/socket.c:8617
Call Trace:
<TASK>
__sys_listen_socket net/socket.c:1883 [inline]
__sys_listen+0x1b7/0x230 net/socket.c:1894
__do_sys_listen net/socket.c:1902 [inline]
Add missing reg minItems as based on current binding document
only ethernet MAC IO space is a supported configuration.
There is a bug in schema, current examples contain 64-bit
addressing as well as 32-bit addressing. The schema validation
does pass incidentally considering one 64-bit reg address as
two 32-bit reg address entries. If we change axi_ethernet_eth1
example node reg addressing to 32-bit schema validation reports:
Documentation/devicetree/bindings/net/xlnx,axi-ethernet.example.dtb:
ethernet@40000000: reg: [[1073741824, 262144]] is too short
To fix it add missing reg minItems constraints and to make things clearer
stick to 32-bit addressing in examples.
Sean Anderson [Mon, 30 Sep 2024 15:39:54 +0000 (11:39 -0400)]
doc: net: napi: Update documentation for napi_schedule_irqoff
Since commit 8380c81d5c4f ("net: Treat __napi_schedule_irqoff() as
__napi_schedule() on PREEMPT_RT"), napi_schedule_irqoff will do the
right thing if IRQs are threaded. Therefore, there is no need to use
IRQF_NO_THREAD.
Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Reviewed-by: Bagas Sanjaya <bagasdotme@gmail.com> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Link: https://patch.msgid.link/20240930153955.971657-1-sean.anderson@linux.dev Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Darrick J. Wong [Wed, 2 Oct 2024 15:02:13 +0000 (08:02 -0700)]
iomap: constrain the file range passed to iomap_file_unshare
File contents can only be shared (i.e. reflinked) below EOF, so it makes
no sense to try to unshare ranges beyond EOF. Constrain the file range
parameters here so that we don't have to do that in the callers.
Fixes: 5f4e5752a8a3 ("fs: add iomap_file_dirty") Signed-off-by: Darrick J. Wong <djwong@kernel.org> Link: https://lore.kernel.org/r/20241002150213.GC21853@frogsfrogsfrogs Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
Darrick J. Wong [Wed, 2 Oct 2024 15:00:40 +0000 (08:00 -0700)]
iomap: don't bother unsharing delalloc extents
If unshare encounters a delalloc reservation in the srcmap, that means
that the file range isn't shared because delalloc reservations cannot be
reflinked. Therefore, don't try to unshare them.
Signed-off-by: Darrick J. Wong <djwong@kernel.org> Link: https://lore.kernel.org/r/20241002150040.GB21853@frogsfrogsfrogs Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Brian Foster <bfoster@redhat.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
Fix the following warning when the driver is compiled as built-in:
warning: unused import: `DeviceId`
--> drivers/net/phy/qt2025.rs:18:5
|
18 | DeviceId, Driver,
| ^^^^^^^^
|
= note: `#[warn(unused_imports)]` on by default
device_table in module_phy_driver macro is defined only when the
driver is built as a module. Use phy::DeviceId in the macro instead of
importing `DeviceId` since `phy` is always used.
Willem de Bruijn [Tue, 1 Oct 2024 17:17:46 +0000 (13:17 -0400)]
gso: fix udp gso fraglist segmentation after pull from frag_list
Detect gso fraglist skbs with corrupted geometry (see below) and
pass these to skb_segment instead of skb_segment_list, as the first
can segment them correctly.
Valid SKB_GSO_FRAGLIST skbs
- consist of two or more segments
- the head_skb holds the protocol headers plus first gso_size
- one or more frag_list skbs hold exactly one segment
- all but the last must be gso_size
Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can
modify these skbs, breaking these invariants.
In extreme cases they pull all data into skb linear. For UDP, this
causes a NULL ptr deref in __udpv4_gso_segment_list_csum at
udp_hdr(seg->next)->dest.
Detect invalid geometry due to pull, by checking head_skb size.
Don't just drop, as this may blackhole a destination. Convert to be
able to pass to regular skb_segment.
bridge: mcast: Fail MDB get request on empty entry
When user space deletes a port from an MDB entry, the port is removed
synchronously. If this was the last port in the entry and the entry is
not joined by the host itself, then the entry is scheduled for deletion
via a timer.
The above means that it is possible for the MDB get netlink request to
retrieve an empty entry which is scheduled for deletion. This is
problematic as after deleting the last port in an entry, user space
cannot rely on a non-zero return code from the MDB get request as an
indication that the port was successfully removed.
Fix by returning an error when the entry's port list is empty and the
entry is not joined by the host.
Hui Wang [Fri, 27 Sep 2024 11:46:10 +0000 (19:46 +0800)]
net: phy: realtek: Check the index value in led_hw_control_get
Just like rtl8211f_led_hw_is_supported() and
rtl8211f_led_hw_control_set(), the rtl8211f_led_hw_control_get() also
needs to check the index value, otherwise the caller is likely to get
an incorrect rules.
Fixes: 17784801d888 ("net: phy: realtek: Add support for PHY LEDs on RTL8211F") Signed-off-by: Hui Wang <hui.wang@canonical.com> Reviewed-by: Marek Vasut <marex@denx.de> Link: https://patch.msgid.link/20240927114610.1278935-1-hui.wang@canonical.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet [Fri, 27 Sep 2024 07:45:53 +0000 (07:45 +0000)]
ppp: do not assume bh is held in ppp_channel_bridge_input()
Networking receive path is usually handled from BH handler.
However, some protocols need to acquire the socket lock, and
packets might be stored in the socket backlog is the socket was
owned by a user process.
In this case, release_sock(), __release_sock(), and sk_backlog_rcv()
might call the sk->sk_backlog_rcv() handler in process context.
sybot caught ppp was not considering this case in
ppp_channel_bridge_input() :
WARNING: inconsistent lock state 6.11.0-rc7-syzkaller-g5f5673607153 #0 Not tainted
--------------------------------
inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage.
ksoftirqd/1/24 [HC0[0]:SC1[1]:HE1:SE0] takes: ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: spin_lock include/linux/spinlock.h:351 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline] ffff0000db7f11e0 (&pch->downl){+.?.}-{2:2}, at: ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304
{SOFTIRQ-ON-W} state was registered at:
lock_acquire+0x240/0x728 kernel/locking/lockdep.c:5759
__raw_spin_lock include/linux/spinlock_api_smp.h:133 [inline]
_raw_spin_lock+0x48/0x60 kernel/locking/spinlock.c:154
spin_lock include/linux/spinlock.h:351 [inline]
ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2272 [inline]
ppp_input+0x16c/0x854 drivers/net/ppp/ppp_generic.c:2304
pppoe_rcv_core+0xfc/0x314 drivers/net/ppp/pppoe.c:379
sk_backlog_rcv include/net/sock.h:1111 [inline]
__release_sock+0x1a8/0x3d8 net/core/sock.c:3004
release_sock+0x68/0x1b8 net/core/sock.c:3558
pppoe_sendmsg+0xc8/0x5d8 drivers/net/ppp/pppoe.c:903
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
__sys_sendto+0x374/0x4f4 net/socket.c:2204
__do_sys_sendto net/socket.c:2216 [inline]
__se_sys_sendto net/socket.c:2212 [inline]
__arm64_sys_sendto+0xd8/0xf8 net/socket.c:2212
__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151
el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
irq event stamp: 282914
hardirqs last enabled at (282914): [<ffff80008b42e30c>] __raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:151 [inline]
hardirqs last enabled at (282914): [<ffff80008b42e30c>] _raw_spin_unlock_irqrestore+0x38/0x98 kernel/locking/spinlock.c:194
hardirqs last disabled at (282913): [<ffff80008b42e13c>] __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]
hardirqs last disabled at (282913): [<ffff80008b42e13c>] _raw_spin_lock_irqsave+0x2c/0x7c kernel/locking/spinlock.c:162
softirqs last enabled at (282904): [<ffff8000801f8e88>] softirq_handle_end kernel/softirq.c:400 [inline]
softirqs last enabled at (282904): [<ffff8000801f8e88>] handle_softirqs+0xa3c/0xbfc kernel/softirq.c:582
softirqs last disabled at (282909): [<ffff8000801fbdf8>] run_ksoftirqd+0x70/0x158 kernel/softirq.c:928
other info that might help us debug this:
Possible unsafe locking scenario:
Hangbin Liu [Fri, 27 Sep 2024 04:13:49 +0000 (12:13 +0800)]
selftests: rds: move include.sh to TEST_FILES
The include.sh file is generated for inclusion and should not be executable.
Otherwise, it will be added to kselftest-list.txt. Additionally, add the
executable bit for test.py at the same time to ensure proper functionality.
Eric Dumazet [Thu, 26 Sep 2024 16:58:36 +0000 (16:58 +0000)]
net: test for not too small csum_start in virtio_net_hdr_to_skb()
syzbot was able to trigger this warning [1], after injecting a
malicious packet through af_packet, setting skb->csum_start and thus
the transport header to an incorrect value.
We can at least make sure the transport header is after
the end of the network header (with a estimated minimal size).
Fixes: 9181d6f8a2bb ("net: add more sanity check in virtio_net_hdr_to_skb()") Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20240926165836.3797406-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Felix Fietkau [Thu, 26 Sep 2024 08:53:14 +0000 (10:53 +0200)]
net: gso: fix tcp fraglist segmentation after pull from frag_list
Detect tcp gso fraglist skbs with corrupted geometry (see below) and
pass these to skb_segment instead of skb_segment_list, as the first
can segment them correctly.
Valid SKB_GSO_FRAGLIST skbs
- consist of two or more segments
- the head_skb holds the protocol headers plus first gso_size
- one or more frag_list skbs hold exactly one segment
- all but the last must be gso_size
Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can
modify these skbs, breaking these invariants.
In extreme cases they pull all data into skb linear. For TCP, this
causes a NULL ptr deref in __tcpv4_gso_segment_list_csum at
tcp_hdr(seg->next).
Detect invalid geometry due to pull, by checking head_skb size.
Don't just drop, as this may blackhole a destination. Convert to be
able to pass to regular skb_segment.
Approach and description based on a patch by Willem de Bruijn.
Jakub Kicinski [Thu, 3 Oct 2024 00:14:52 +0000 (17:14 -0700)]
Merge tag 'mlx5-fixes-2024-09-25' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux
Saeed Mahameed says:
====================
mlx5 fixes 2024-09-25
* tag 'mlx5-fixes-2024-09-25' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux:
net/mlx5e: Fix crash caused by calling __xfrm_state_delete() twice
net/mlx5e: SHAMPO, Fix overflow of hd_per_wq
net/mlx5: HWS, changed E2BIG error to a negative return code
net/mlx5: HWS, fixed double-free in error flow of creating SQ
net/mlx5: Fix wrong reserved field in hca_cap_2 in mlx5_ifc
net/mlx5e: Fix NULL deref in mlx5e_tir_builder_alloc()
net/mlx5: Added cond_resched() to crdump collection
net/mlx5: Fix error path in multi-packet WQE transmit
====================
Jakub Kicinski [Thu, 3 Oct 2024 00:09:52 +0000 (17:09 -0700)]
Merge tag 'for-net-2024-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth
Luiz Augusto von Dentz says:
====================
bluetooth pull request for net:
- btmrvl: Use IRQF_NO_AUTOEN flag in request_irq()
- MGMT: Fix possible crash on mgmt_index_removed
- L2CAP: Fix uaf in l2cap_connect
- Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE
* tag 'for-net-2024-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth:
Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE
Bluetooth: btmrvl: Use IRQF_NO_AUTOEN flag in request_irq()
Bluetooth: L2CAP: Fix uaf in l2cap_connect
Bluetooth: MGMT: Fix possible crash on mgmt_index_removed
====================
Jakub Kicinski [Thu, 3 Oct 2024 00:07:00 +0000 (17:07 -0700)]
Merge tag 'ieee802154-for-net-2024-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan
Stefan Schmidt says:
====================
pull-request: ieee802154 for net 2024-09-27
Jinjie Ruan added the use of IRQF_NO_AUTOEN in the mcr20a driver and fixed
and addiotinal build dependency problem while doing so.
Jiawei Ye, ensured a correct RCU handling in mac802154_scan_worker.
* tag 'ieee802154-for-net-2024-09-27' of git://git.kernel.org/pub/scm/linux/kernel/git/wpan/wpan:
net: ieee802154: mcr20a: Use IRQF_NO_AUTOEN flag in request_irq()
mac802154: Fix potential RCU dereference issue in mac802154_scan_worker
ieee802154: Fix build error
====================
Linus Torvalds [Wed, 2 Oct 2024 23:42:28 +0000 (16:42 -0700)]
Merge tag 'pull-work.unaligned' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
Pull generic unaligned.h cleanups from Al Viro:
"Get rid of architecture-specific <asm/unaligned.h> includes, replacing
them with a single generic <linux/unaligned.h> header file.
It's the second largest (after asm/io.h) class of asm/* includes, and
all but two architectures actually end up using exact same file.
Massage the remaining two (arc and parisc) to do the same and just
move the thing to from asm-generic/unaligned.h to linux/unaligned.h"
[ This is one of those things that we're better off doing outside the
merge window, and would only cause extra conflict noise if it was in
linux-next for the next release due to all the trivial #include line
updates. Rip off the band-aid. - Linus ]
* tag 'pull-work.unaligned' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
move asm/unaligned.h to linux/unaligned.h
arc: get rid of private asm/unaligned.h
parisc: get rid of private asm/unaligned.h
Al Viro [Tue, 1 Oct 2024 19:35:57 +0000 (15:35 -0400)]
move asm/unaligned.h to linux/unaligned.h
asm/unaligned.h is always an include of asm-generic/unaligned.h;
might as well move that thing to linux/unaligned.h and include
that - there's nothing arch-specific in that header.
auto-generated by the following:
for i in `git grep -l -w asm/unaligned.h`; do
sed -i -e "s/asm\/unaligned.h/linux\/unaligned.h/" $i
done
for i in `git grep -l -w asm-generic/unaligned.h`; do
sed -i -e "s/asm-generic\/unaligned.h/linux\/unaligned.h/" $i
done
git mv include/asm-generic/unaligned.h include/linux/unaligned.h
git mv tools/include/asm-generic/unaligned.h tools/include/linux/unaligned.h
sed -i -e "/unaligned.h/d" include/asm-generic/Kbuild
sed -i -e "s/__ASM_GENERIC/__LINUX/" include/linux/unaligned.h tools/include/linux/unaligned.h
Al Viro [Wed, 6 Dec 2023 02:53:22 +0000 (21:53 -0500)]
arc: get rid of private asm/unaligned.h
Declarations local to arch/*/kernel/*.c are better off *not* in a public
header - arch/arc/kernel/unaligned.h is just fine for those
bits.
Unlike the parisc case, here we have an extra twist - asm/mmu.h
has an implicit dependency on struct pt_regs, and in some users
that used to be satisfied by include of asm/ptrace.h from
asm/unaligned.h (note that asm/mmu.h itself did _not_ pull asm/unaligned.h
- it relied upon the users having pulled asm/unaligned.h before asm/mmu.h
got there).
Seeing that asm/mmu.h only wants struct pt_regs * arguments in
an extern, just pre-declare it there - less brittle that way.
With that done _all_ asm/unaligned.h instances are reduced to include
of asm-generic/unaligned.h and can be removed - unaligned.h is in
mandatory-y in include/asm-generic/Kbuild.
What's more, we can move asm-generic/unaligned.h to linux/unaligned.h
and switch includes of <asm/unaligned.h> to <linux/unaligned.h>; that's
better off as an auto-generated commit, though, to be done by Linus
at -rc1 time next cycle.
Acked-by: Vineet Gupta <vgupta@kernel.org> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Linus Torvalds [Wed, 2 Oct 2024 19:18:02 +0000 (12:18 -0700)]
Merge tag 'input-for-v6.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input fixes from Dmitry Torokhov:
- a couple fixups for adp5589-keys driver
- recently added driver for PixArt PS/2 touchpads is dropped
temporarily because its detection routine is too greedy and
mis-identifies devices from other vendors as PixArt devices
* tag 'input-for-v6.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: adp5589-keys - fix adp5589_gpio_get_value()
Input: adp5589-keys - fix NULL pointer dereference
Revert "Input: Add driver for PixArt PS/2 touchpad"
Linus Torvalds [Wed, 2 Oct 2024 19:05:13 +0000 (12:05 -0700)]
Merge tag 'for-6.12/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
Pull device mapper fixes from Mikulas Patocka:
"Revert the patch that made dm-verity restart or panic on I/O errors,
and instead add new explicit options for people who want that
behavior"
* tag 'for-6.12/dm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
dm-verity: introduce the options restart_on_error and panic_on_error
Revert: "dm-verity: restart or panic on an I/O error"
David Howells [Wed, 2 Oct 2024 14:45:50 +0000 (15:45 +0100)]
netfs: Fix missing wakeup after issuing writes
After dividing up a proposed write into subrequests, netfslib sets
NETFS_RREQ_ALL_QUEUED to indicate to the collector that it can move on to
the final cleanup once it has emptied the subrequest queues.
Now, whilst the collector will normally end up running at least once after
this bit is set just because it takes a while to process all the write
subrequests before the collector runs out of subrequests, there exists the
possibility that the issuing thread will be forced to sleep and the
collector thread will clean up all the subrequests before ALL_QUEUED gets
set.
In such a case, the collector thread will not get triggered again and will
never clear NETFS_RREQ_IN_PROGRESS thus leaving a request uncompleted and
causing a potential futute hang.
Fix this by scheduling the write collector if all the subrequest queues are
empty (and thus no writes pending issuance).
Note that we'd do this ideally before queuing the subrequest, but in the
case of buffered writeback, at least, we can't find out that we've run out
of folios until after we've called writeback_iter() and it has returned
NULL - at which point we might not actually have any subrequests still
under construction.
Fixes: 288ace2f57c9 ("netfs: New writeback implementation") Signed-off-by: David Howells <dhowells@redhat.com> Link: https://lore.kernel.org/r/3317784.1727880350@warthog.procyon.org.uk
cc: Jeff Layton <jlayton@kernel.org>
cc: netfs@lists.linux.dev
cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
The problem that the commit e6a3531dd542cb127c8de32ab1e54a48ae19962b
fixes was reported as a security bug, but Google engineers working on
Android and ChromeOS didn't want to change the default behavior, they
want to get -EIO rather than restarting the system, so I am reverting
that commit.
Note also that calling machine_restart from the I/O handling code is
potentially unsafe (the reboot notifiers may wait for the bio that
triggered the restart), but Android uses the reboot notifiers to store
the reboot reason into the PMU microcontroller, so machine_restart must
be used.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Fixes: e6a3531dd542 ("dm-verity: restart or panic on an I/O error") Suggested-by: Sami Tolvanen <samitolvanen@google.com> Suggested-by: Will Drewry <wad@chromium.org>