mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2026-11-13 07:31:07 +00:00
1,481,701 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Andrii Nakryiko
|
df3153758d |
libbpf: fix -Wformat warnings from format/argument type mismatches
Building libbpf with -Wall (as happens via bpftool's bootstrap build)
surfaces ~120 -Wformat warnings where pr_warn/pr_debug format specifiers
don't match their argument types: %d for __u32/Elf64_Word, %u for signed
ints, %zd for size_t, %ld for unsigned long, and %x/%lx/%llx applied to
signed values.
Match each specifier to its argument's type where a correctly-signed
specifier exists (%d<->%u, %ld->%lu, %zd->%zu). For hex conversions,
which have no signed form, cast the argument instead (%x->(unsigned),
%lx->(unsigned long), %llx->(unsigned long long)). No functional change.
Note, the fdinfo map_flags sscanf used %i into a __u32 *, which warns.
The kernel prints map_flags as hex ("map_flags:\t%#x\n" in
bpf_map_show_fdinfo(), unchanged since the field was added to fdinfo), so
switch the conversion to %x: it parses the 0x-prefixed value and expects
unsigned int *, matching the destination, so the warning is gone with no
cast.
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/r/20260624204946.2901178-1-andrii@kernel.org
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
||
Alexei Starovoitov
|
26b29f868b |
Merge branch 'bpf-preserve-scalar-zero-spills-for-stack-reads'
Woojin Ji says: ==================== bpf: Preserve scalar zero spills for stack reads Changes in v3: - Apply scalar-zero spill preservation to fixed-offset mixed stack reads as well. - Remove the var-offset-only flag from mark_reg_stack_read(). - Keep pure register-fill behavior unchanged. - Add fixed-offset mixed zero/spill-zero selftest coverage. - Address selftest nits: drop extra unpriv checks, align asm formatting, and remove the pruning-sensitive test. - Link to v2: https://patch.msgid.link/20260613-bpf-stack-var-off-zero-v1-v2-0-a324af0f00ea@gmail.com Stack reads currently lose the known-zero fact when loaded bytes come from a spilled scalar constant zero rather than from STACK_ZERO bytes in some paths. This series teaches the stack read zero reconstruction path to preserve that fact while marking the contributing spill slots precise. The original reproducer used a variable-offset stack byte read emitted by clang 22.1.6 at -O2/-O3 from a small helper-based BPF C program. Review of v2 pointed out that fixed-offset reads can benefit as well: pure scalar zero spill reads were already handled, but a fixed read spanning both STACK_ZERO and scalar const-zero STACK_SPILL bytes, e.g. 0000ssss, still fell back to an unknown scalar. v3 handles that mixed fixed-offset case without changing the existing pure register-fill behavior. I still do not have a confirmed deployed-program regression, so this stays targeted at bpf-next. Tested with: - make O=../../out/kernel olddefconfig - make O=../../out/kernel -j$(nproc) kernel/bpf/verifier.o - make O=../../out/kernel LLVM=1 -j$(nproc) bzImage - make -C tools/testing/selftests/bpf O=../../../../../out/kernel VMLINUX_BTF=../../../../../out/kernel/vmlinux TEST_KMOD_TARGETS= LLVM=1 -j$(nproc) test_progs - QEMU guest: ./test_progs -t verifier_var_off -v Summary: 1/24 PASSED, 0 SKIPPED, 0 FAILED - QEMU guest: ./test_progs -t verifier_spill_fill -t verifier_live_stack -t verifier_search_pruning -v Summary: 3/128 PASSED, 0 SKIPPED, 0 FAILED - QEMU guest: ./veristat -o csv verifier_var_off.bpf.o verifier_spill_fill.bpf.o Assisted-by: opencode:gpt-5.5 Signed-off-by: Woojin Ji <random6.xyz@gmail.com> --- ==================== Link: https://patch.msgid.link/20260625-bpf-stack-var-off-zero-v1-v3-0-a068210a761b@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> |
||
Woojin Ji
|
e693da913d |
selftests/bpf: Cover stack reads from zero spills
Add verifier_var_off coverage for variable-offset stack reads from spilled scalar constant zero values. Cover single-slot and cross-slot spilled zero reads, a sub-8-byte spill with neighbouring STACK_ZERO bytes, and a sub-8-byte spill with neighbouring STACK_MISC bytes that must not be treated as zero. Add verifier_spill_fill coverage for a fixed-offset stack read spanning both STACK_ZERO bytes and scalar const-zero STACK_SPILL bytes. Use verifier log assertions to check both the zero result and the precision backtracking trail. Assisted-by: opencode:gpt-5.5 Signed-off-by: Woojin Ji <random6.xyz@gmail.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260625-bpf-stack-var-off-zero-v1-v3-2-a068210a761b@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> |
||
|
Woojin Ji
|
69fdbe63e1 |
bpf: Preserve scalar zero spills for stack reads
Stack reads can read back bytes that belong to a previously spilled scalar constant zero. Today mark_reg_stack_read() only treats STACK_ZERO bytes as known zero bytes, so the destination register can become unknown even though every byte in the read range is known to be zero. This can lead to rejecting otherwise valid programs once the loaded byte is used as a pointer offset. The original reproducer uses a variable-offset stack byte read emitted by clang 22.1.6 at -O2/-O3 from a small helper-based BPF C program. Fixed offset reads have a related mixed case as well: pure scalar-zero spill reads are already handled, but a fixed read spanning both STACK_ZERO and scalar const-zero STACK_SPILL bytes still falls back to unknown. Teach mark_reg_stack_read() to also consider STACK_SPILL bytes backed by a spilled scalar constant zero as zero bytes, and use that path for both variable-offset stack reads and fixed-offset mixed reads. Keep the existing pure register-fill behavior unchanged. When a zero result depends on such a spill, mark the contributing stack slots precise before accepting the const-zero result so pruning cannot reuse a zero-spill state for a later non-zero spill state. No deployed-program regression is currently known, so target bpf-next. Assisted-by: opencode:gpt-5.5 Signed-off-by: Woojin Ji <random6.xyz@gmail.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/r/20260625-bpf-stack-var-off-zero-v1-v3-1-a068210a761b@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> |
||
|
Alexei Starovoitov
|
fbc10dff78 |
Merge branch 'bpf-reject-offset-refcount-acquire-arguments'
Yiyang Chen says:
====================
bpf: Reject offset refcount acquire arguments
bpf_refcount_acquire() is modeled as returning a refcounted allocation
base, but it currently accepts PTR_TO_BTF_ID | MEM_ALLOC arguments whose
offset already points at an embedded graph node returned from a list or
rbtree operation.
At runtime the kfunc starts from the supplied pointer and adds the type's
refcount offset. With a graph-node pointer, that starts from base +
node_off, while the verifier treats the returned pointer as the allocation
base. Reject non-zero fixed-offset arguments to keep the runtime operation
and the verifier model aligned.
Programs that pop graph nodes can still acquire a reference after
normalizing the node pointer with container_of().
Patch 1 handles the zero fixed-offset requirement in the existing
check_func_arg_reg_off() / __check_ptr_off_reg() path without consuming a
bpf_type_flag bit.
Patch 2 adds a rejected direct list-node case.
Changes from v3:
- Add Eduard's Acked-by to patch 1.
- Drop the redundant rbtree selftest case; the list case exercises the same
refcount-acquire fixed-offset rejection path.
- Trim the selftest commit message and remove the selftest Fixes tag.
Changes from v2:
- Avoid adding a new bpf_type_flag bit.
- Carry the refcount-acquire zero fixed-offset requirement with an
internal check_func_arg_reg_off() parameter.
Changes from v1:
- Move zero fixed-offset enforcement into check_func_arg_reg_off() /
__check_ptr_off_reg(), as suggested by Eduard.
- Drop the positive container_of() selftest case.
- Remove the stale bpf_obj_drop() after bpf_list_push_front(), since the
pushed reference is consumed even when the verifier explores the error
branch.
- Rebase to bpf-next master
|
||
Yiyang Chen
|
0371fb57a0 |
selftests/bpf: Cover refcount acquire node offsets
Add regression coverage for bpf_refcount_acquire() on graph-node-derived pointers. The rejected case passes a popped list node pointer directly to bpf_refcount_acquire(), which must fail because the pointer carries a non-zero fixed offset. Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/bf2a2033ced272106292de4465b8ef3fb991c912.1782192383.git.chenyy23@mails.tsinghua.edu.cn Signed-off-by: Alexei Starovoitov <ast@kernel.org> |
||
|
Yiyang Chen
|
931a577fc7 |
bpf: Reject offset refcount acquire arguments
bpf_refcount_acquire() increments the refcount at the caller-supplied
pointer plus the refcount field offset, then returns the caller-supplied
pointer unchanged.
The verifier records the return value as a base pointer to the refcounted
object.
bpf_list_pop_front() and bpf_rbtree_remove() can return embedded
graph-node pointers as PTR_TO_BTF_ID | MEM_ALLOC with a fixed offset equal
to the node field offset. Passing such a pointer directly to
bpf_refcount_acquire() currently passes the refcounted-kptr type check.
That makes the runtime operation start from base + node_off while the
verifier models the returned pointer as the object base.
Require refcount-acquire arguments to have zero fixed offset by carrying
the requirement through check_func_arg_reg_off() to __check_ptr_off_reg().
Programs can still acquire a refcount from a graph-node-derived pointer
after normalizing it with container_of().
Fixes:
|
||
Bryam Vargas
|
d577e46785 |
Input: synaptics-rmi4 - bound the F30 keymap to the GPIO/LED count
rmi_f30_map_gpios() allocates gpioled_key_map with
min(gpioled_count, TRACKSTICK_RANGE_END) == at most 6 entries, but
rmi_f30_attention() iterates the full f30->gpioled_count (device query
register, range 0..31) and dereferences gpioled_key_map[i], and
input->keycodemax is set to the full gpioled_count while input->keycode
points at the 6-entry allocation.
A device that reports gpioled_count > 6 with GPIO support enabled
therefore causes an out-of-bounds read on the attention interrupt and
out-of-bounds read/write through the EVIOCGKEYCODE/EVIOCSKEYCODE ioctls,
which bound the index only against keycodemax. This is the same defect
as the F3A handler, which was copied from F30.
Size the keymap for the full gpioled_count; the mapping loop still
assigns only the first min(gpioled_count, TRACKSTICK_RANGE_END) entries.
Fixes:
|
||
|
Bryam Vargas
|
57c10915f2 |
Input: synaptics-rmi4 - bound the F3A keymap to the GPIO count
rmi_f3a_initialize() takes the GPIO count from the device query register
(f3a->gpio_count = buf & RMI_F3A_GPIO_COUNT, range 0..127).
rmi_f3a_map_gpios() then allocates gpio_key_map with
min(gpio_count, TRACKSTICK_RANGE_END) == at most 6 entries, but
rmi_f3a_attention() iterates the full gpio_count and dereferences
gpio_key_map[i], and input->keycodemax is set to the full gpio_count
while input->keycode points at the 6-entry allocation.
A device that reports gpio_count > 6 therefore causes an out-of-bounds
read of gpio_key_map[] on every attention interrupt, and out-of-bounds
accesses through the input core's default keymap ioctls: EVIOCGKEYCODE
reads past the buffer (leaking adjacent slab memory to user space) and
EVIOCSKEYCODE writes a caller-controlled value past it, for any process
able to open the evdev node, since input_default_getkeycode() and
input_default_setkeycode() only bound the index against keycodemax.
Size the keymap for the full gpio_count. The mapping loop is unchanged:
it still assigns only the first min(gpio_count, TRACKSTICK_RANGE_END)
entries; the remaining slots stay KEY_RESERVED (devm_kcalloc zero-fills)
and are skipped when reporting.
Fixes:
|
||
|
Alexei Starovoitov
|
66bb952b44 |
Merge branch 'bpf-sockmap-reject-a-packet-modifying-sk_skb-stream-parser'
Sechang Lim says: ==================== bpf, sockmap: reject a packet-modifying SK_SKB stream parser A BPF_PROG_TYPE_SK_SKB stream parser runs on strparser's message head, which can chain skbs through frag_list. A parser that resizes the skb frees the frag_list segments that strparser still tracks through skb_nextp, leading to a use-after-free. A stream parser is only meant to measure the next message, not to modify the packet, so reject a packet-modifying parser at attach time. v5: - target bpf-next instead of bpf - add Reviewed-by tag (Jiayuan Chen) v4: - https://lore.kernel.org/all/20260619062959.3277612-1-rhkrqnwk98@gmail.com/ v3: - https://lore.kernel.org/all/20260618102718.2331468-1-rhkrqnwk98@gmail.com/ v2: - https://lore.kernel.org/all/20260612123553.2724240-1-rhkrqnwk98@gmail.com/ v1: - https://lore.kernel.org/all/20260609112316.3685738-1-rhkrqnwk98@gmail.com/ ==================== Link: https://patch.msgid.link/20260620024423.4141004-1-rhkrqnwk98@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> |
||
Sechang Lim
|
05fb34384d |
selftests/bpf: test rejection of a packet-modifying SK_SKB stream parser
Verify that attaching an SK_SKB stream parser that can modify the packet is rejected, while a read-only parser still attaches. Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com> Link: https://lore.kernel.org/r/20260620024423.4141004-4-rhkrqnwk98@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> |
||
|
Sechang Lim
|
31e2f36d38 |
bpf, sockmap: reject a packet-modifying SK_SKB stream parser
sk_psock_strp_parse() runs the BPF_PROG_TYPE_SK_SKB stream-parser program
to find the length of the next message. strparser assembles a message out
of several received skbs by chaining them onto the head's frag_list and
recording where to append the next one in strp->skb_nextp:
*strp->skb_nextp = skb;
strp->skb_nextp = &skb->next;
and then calls the parser on the head:
len = (*strp->cb.parse_msg)(strp, head);
The parser is only meant to inspect the skb, but the program may call
bpf_skb_change_tail() -- or the sibling bpf_skb_pull_data(),
bpf_skb_change_head(), bpf_skb_adjust_room(), all allowed for SK_SKB.
Once the head carries a frag_list these go
... -> skb_ensure_writable -> pskb_may_pull -> __pskb_pull_tail
and __pskb_pull_tail() frees the frag_list skbs that strparser still
tracks through skb_nextp:
while ((list = skb_shinfo(skb)->frag_list) != insp) {
skb_shinfo(skb)->frag_list = list->next;
consume_skb(list);
}
strp->skb_nextp now points into a freed sk_buff. The next segment of
the same message arrives in __strp_recv(), which links it with
*strp->skb_nextp = skb, an 8-byte write into the freed skb. The free
and the write happen in different __strp_recv() calls, so the message
has to span at least three segments before it triggers.
BUG: KASAN: slab-use-after-free in __strp_recv+0x447/0xda0
Write of size 8 at addr ffff88810db86140 by task repro/349
Call Trace:
<IRQ>
__strp_recv+0x447/0xda0
__tcp_read_sock+0x13d/0x590
tcp_bpf_strp_read_sock+0x195/0x320
strp_data_ready+0x267/0x340
sk_psock_strp_data_ready+0x1ce/0x350
tcp_data_queue+0x1364/0x2fd0
tcp_rcv_established+0xe07/0x1640
[...]
Allocated by task 349:
skb_clone+0x17b/0x210
__strp_recv+0x2c3/0xda0
__tcp_read_sock+0x13d/0x590
[...]
Freed by task 349:
kmem_cache_free+0x150/0x570
__pskb_pull_tail+0x57b/0xc20
skb_ensure_writable+0x236/0x260
__bpf_skb_change_tail+0x1d4/0x590
sk_skb_change_tail+0x2a/0x40
bpf_prog_1b285dcd6c41373e+0x27/0x30
bpf_prog_run_pin_on_cpu+0xf3/0x260
sk_psock_strp_parse+0x118/0x1e0
__strp_recv+0x4f6/0xda0
[...]
The same resize also leaves the head's length inconsistent with its
frags, so a later __pskb_pull_tail() can instead hit the
BUG_ON(skb_copy_bits(...)) in net/core/skbuff.c.
A stream parser is only meant to measure the next message, not to modify
the packet. Reject a parser whose program can change packet data
(prog->aux->changes_pkt_data) at attach time. The check is shared by
sock_map_prog_update() and sock_map_link_update_prog(), which between them
cover prog attach, link create and link update. Verdict programs are
unaffected and may still modify the skb.
Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com>
Link: https://lore.kernel.org/r/20260620024423.4141004-3-rhkrqnwk98@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
|
||
|
Sechang Lim
|
22a0cc10da |
selftests/bpf: don't modify the skb in the strparser parser prog
sockmap_parse_prog.c is attached as an SK_SKB stream parser and modifies the skb: it calls bpf_skb_pull_data() and writes a byte into the packet. A stream parser runs on strparser's message head and must not modify it. A resize frees the frag_list segments strparser still tracks, leading to a use-after-free. Make the parser read-only. It only needs to return the message length, which keeps it attaching once packet-modifying parsers are rejected. Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Signed-off-by: Sechang Lim <rhkrqnwk98@gmail.com> Link: https://lore.kernel.org/r/20260620024423.4141004-2-rhkrqnwk98@gmail.com Signed-off-by: Alexei Starovoitov <ast@kernel.org> |
||
|
Alexei Starovoitov
|
a91fafbb6d |
Merge branch 'bpf-bpf_redirect_peer-egress-redirection'
Jordan Rife says: ==================== bpf: bpf_redirect_peer egress redirection We have several use cases where a pod injects traffic into the datapath of another so that the traffic appears to have originated from that pod. One such use case is a synthetic flow generator which injects synthetic traffic into a pod's datapath to enable dynamic probing and debugging. Another is a transparent proxy where connections originating from one pod are redirected towards another which proxies that connection. The new connection is bound to the IP of the original pod using IP_TRANSPARENT and its traffic is injected into that pod's datapath and handled as if it had originated there. This can be used for mTLS, etc. We use bpf_redirect(BPF_F_INGRESS) to direct traffic leaving the proxy, flow generator, etc. towards the target pod, ensuring that eBPF programs that are meant to intercept traffic leaving that pod are executed. However, this doesn't work with netkit. With netkit, an ingress redirection from proxy to workload skips eBPF programs that are meant to intercept traffic leaving the pod, since they reside on the netkit peer device. One workaround is to attach the same program to both the netkit peer device and the TCX ingress hook for the netkit pair's primary interface, but a) This seems hacky and we need to be careful not to run the same program twice for the same skb in cases where we want to pass that traffic to the host stack. b) We're trying to keep the proxy redirection / traffic injection systems as modular and separated from Cilium as possible, the system that manages netkit setup and core eBPF programming. It would be handy if instead we could redirect traffic directly from one netkit peer device to another. This patch proposes an extension to bpf_redirect_peer to allow us to do just that. With this patch, the BPF_F_EGRESS flag tells bpf_redirect_peer to emit the skb in the egress direction of the target interface's peer device While the main use case is netkit, I suppose you could also use this mode with veth as well if, e.g., there were some eBPF programs attached to that side of the veth pair that needed to intercept traffic. +---------------------------------------------------------------------+ | +-------------------------+ 6. bpf_redirect_neigh(eth0) | | | pod (10.244.0.10) | ------------------------ | | | | | | | | | +--------+ | | +---------+ | | | | 1. packet -->| | | | | | | | | | leaves ^ | netkit |<===========|======| netkit | | | | | | | peer |=======(eBPF)=====>| primary | | | | | | | | | | | | | | | | | +--------+ | | +---------+ | | | | | | | 2. bpf_redirect v | | +-----------|-------------+ |___________________ +-------| | | | | eth0 | | | 5. bpf_redirect_peer(BPF_F_EGRESS) | +-------| | |________________________ | | | +-------------------------+ | | | | | proxy (10.244.0.11) | | | | | | IP_TRANSPARENT | | | | | | +--------+ | | +---------+ | | | | 3. packet <--| | | | | |<-- | | | enters | netkit |<===========|======| netkit | | | | [proxy] | peer |=======(eBPF)=====>| primary | | | | 4. packet -->| | | | | | | | leaves +--------+ | +---------+ | | | sip=10.244.0.10 | | | +-------------------------+ | +---------------------------------------------------------------------+ Using the proxy use case as an example, in step 5 we would redirect traffic leaving the proxy towards the pod's peer device using bpf_redirect_peer(BPF_F_EGRESS). As a bonus, since the skb doesn't have to go through the backlog queue it can take full advantage of netkit's performance benefits. I set up a test where outgoing iperf3 traffic is injected into the datapath of another pod using either bpf_redirect_peer(BPF_F_EGRESS) or bpf_redirect(BPF_F_INGRESS). I used Cilium's eBPF host routing mode which skips the host stack and uses BPF redirect helpers to do all the routing. (net.ipv4.tcp_congestion_control=cubic,mtu=1500,100GiB link,Cilium eBPF host routing mode) BASELINE [bpf_redirect(BPF_F_INGRESS)] 1. [iperf pod] ==bpf_redirect([pod b], BPF_F_INGRESS)==> [pod b] 2. [pod b] ==bpf_redirect_neigh([eth0])==> eth0 3. eth0 ==over network==> [host b] [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 231 GBytes 33.0 Gbits/sec 12060 sender [ 5] 0.00-60.00 sec 230 GBytes 33.0 Gbits/sec receiver TEST [bpf_redirect_peer(BPF_F_EGRESS)] 1. [iperf pod] ==bpf_redirect_peer([pod b], BPF_F_EGRESS)==> [pod b] 2. [pod b] ==bpf_redirect_neigh([eth0])==> eth0 3. eth0 ==over network==> [host b] [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 272 GBytes 38.9 Gbits/sec 0 sender [ 5] 0.00-60.00 sec 272 GBytes 38.9 Gbits/sec receiver In this test, using bpf_redirect_peer(BPF_F_EGRESS) for the hop from [iperf pod] to [pod b] led to ~18% more throughput compared to bpf_redirect(BPF_F_INGRESS). CHANGES ======= v1->v2: https://lore.kernel.org/bpf/20260613183424.1198073-1-jordan@jrife.io/ * Introduce and use BPF_F_EGRESS instead of BPF_F_INGRESS (Paul, Jiayuan). Overall opinion was that BPF_F_EGRESS was clearer, but it was acknowledged that this creates some inconsistencies with bpf_redirect where 0 means egress implicitly. * Invert `skb->dev = dev;` and `dev_sw_netstats_rx_add` to make the diff cleaner. ==================== Link: https://patch.msgid.link/20260618182035.43811-1-jordan@jrife.io Signed-off-by: Alexei Starovoitov <ast@kernel.org> |
||
Jordan Rife
|
006b9456e9 |
selftests/bpf: Add tests for bpf_redirect_peer with BPF_F_EGRESS
Extend redirect tests to cover bpf_redirect_peer(BPF_F_EGRESS). SRC redirects to DST using bpf_redirect_peer(BPF_F_EGRESS) then traffic is hairpinned into DST using bpf_redirect. Signed-off-by: Jordan Rife <jordan@jrife.io> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Paul Chaignon <paul.chaignon@gmail.com> Link: https://lore.kernel.org/r/20260618182035.43811-3-jordan@jrife.io Signed-off-by: Alexei Starovoitov <ast@kernel.org> |
||
|
Jordan Rife
|
509ca545d4 |
bpf: Support BPF_F_EGRESS with bpf_redirect_peer
We have several use cases where a pod injects traffic into the datapath of another so that the traffic appears to have originated from that pod. One such use case is a synthetic flow generator which injects synthetic traffic into a pod's datapath to enable dynamic probing and debugging. Another is a transparent proxy where connections originating from one pod are redirected towards another which proxies that connection. The new connection is bound to the IP of the original pod using IP_TRANSPARENT and its traffic is injected into that pod's datapath and handled as if it had originated there. This can be used for mTLS, etc. We use bpf_redirect(BPF_F_INGRESS) to direct traffic leaving the proxy, flow generator, etc. towards the target pod, ensuring that eBPF programs that are meant to intercept traffic leaving that pod are executed. However, this doesn't work with netkit. With netkit, an ingress redirection from proxy to workload skips eBPF programs that are meant to intercept traffic leaving the pod, since they reside on the netkit peer device. One workaround is to attach the same program to both the netkit peer device and the TCX ingress hook for the netkit pair's primary interface, but a) This seems hacky and we need to be careful not to run the same program twice for the same skb in cases where we want to pass that traffic to the host stack. b) We're trying to keep the proxy redirection / traffic injection systems as modular and separated from Cilium as possible, the system that manages netkit setup and core eBPF programming. It would be handy if instead we could redirect traffic directly from one netkit peer device to another. This patch proposes an extension to bpf_redirect_peer to allow us to do just that. With this patch, the BPF_F_EGRESS flag tells bpf_redirect_peer to emit the skb in the egress direction of the target interface's peer device While the main use case is netkit, I suppose you could also use this mode with veth as well if, e.g., there were some eBPF programs attached to that side of the veth pair that needed to intercept traffic. +---------------------------------------------------------------------+ | +-------------------------+ 6. bpf_redirect_neigh(eth0) | | | pod (10.244.0.10) | ------------------------ | | | | | | | | | +--------+ | | +---------+ | | | | 1. packet -->| | | | | | | | | | leaves ^ | netkit |<===========|======| netkit | | | | | | | peer |=======(eBPF)=====>| primary | | | | | | | | | | | | | | | | | +--------+ | | +---------+ | | | | | | | 2. bpf_redirect v | | +-----------|-------------+ |___________________ +-------| | | | | eth0 | | | 5. bpf_redirect_peer(BPF_F_EGRESS) | +-------| | |________________________ | | | +-------------------------+ | | | | | proxy (10.244.0.11) | | | | | | IP_TRANSPARENT | | | | | | +--------+ | | +---------+ | | | | 3. packet <--| | | | | |<-- | | | enters | netkit |<===========|======| netkit | | | | [proxy] | peer |=======(eBPF)=====>| primary | | | | 4. packet -->| | | | | | | | leaves +--------+ | +---------+ | | | sip=10.244.0.10 | | | +-------------------------+ | +---------------------------------------------------------------------+ Using the proxy use case as an example, in step 5 we would redirect traffic leaving the proxy towards the pod's peer device using bpf_redirect_peer(BPF_F_EGRESS). As a bonus, since the skb doesn't have to go through the backlog queue it can take full advantage of netkit's performance benefits. I set up a test where outgoing iperf3 traffic is injected into the datapath of another pod using either bpf_redirect_peer(BPF_F_EGRESS) or bpf_redirect(BPF_F_INGRESS). I used Cilium's eBPF host routing mode which skips the host stack and uses BPF redirect helpers to do all the routing. (net.ipv4.tcp_congestion_control=cubic,mtu=1500,100GiB link,Cilium eBPF host routing mode) BASELINE [bpf_redirect(BPF_F_INGRESS)] 1. [iperf pod] ==bpf_redirect([pod b], BPF_F_INGRESS)==> [pod b] 2. [pod b] ==bpf_redirect_neigh([eth0])==> eth0 3. eth0 ==over network==> [host b] [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 231 GBytes 33.0 Gbits/sec 12060 sender [ 5] 0.00-60.00 sec 230 GBytes 33.0 Gbits/sec receiver TEST [bpf_redirect_peer(BPF_F_EGRESS)] 1. [iperf pod] ==bpf_redirect_peer([pod b], BPF_F_EGRESS)==> [pod b] 2. [pod b] ==bpf_redirect_neigh([eth0])==> eth0 3. eth0 ==over network==> [host b] [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-60.00 sec 272 GBytes 38.9 Gbits/sec 0 sender [ 5] 0.00-60.00 sec 272 GBytes 38.9 Gbits/sec receiver In this test, using bpf_redirect_peer(BPF_F_EGRESS) for the hop from [iperf pod] to [pod b] led to ~18% more throughput compared to bpf_redirect(BPF_F_INGRESS). Signed-off-by: Jordan Rife <jordan@jrife.io> Acked-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Paul Chaignon <paul.chaignon@gmail.com> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Link: https://lore.kernel.org/r/20260618182035.43811-2-jordan@jrife.io Signed-off-by: Alexei Starovoitov <ast@kernel.org> |
||
Linus Torvalds
|
ad054be811 |
17 smb3 client fixes
-----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEE6fsu8pdIjtWE/DpLiiy9cAdyT1EFAmo9mPQACgkQiiy9cAdy T1HWIQv+IV73XayJX9VoeEqulKAksrH4oW2/IjPw93JqlwGSXkzTwdkl8lE+wkKf vxmjRNpJmqMLoyPxLq07/MvuiDowqnlz/Vb5qOrsDLjjpSCegECKyejnmAOU+yVU W1+6RKOpMgWqcADzJcvKpWQJsMwpVXOquLragsWQL3bOG6RSqYAnFYhufmsGFJly +Xsbm7CazFd+T3LSG3A74mN+ip18uTnmOijLwMZ1wdIkwOV/eFkCtyAbwQzxM424 dF7dScw+jV6jtKFiHe4QPSfQRBwEUNdSMUlvOGlzLDm7JmzXLeqM4rY6p3zK7syD lXJ0ZCBRo9Jy2ibJleFuJCoTyeb+whlx2A+T78o8t/Grw0gMPsFyk5m7DOCeFEIM PdtG4VYgf6byB5vRYMXwJt+FVp4cj/pLF9+Hoi3E5lUHe2ZFnFf7BdRVW9Xk+Nzj z8xknYMl8GlNpIQFEPTRQ355zTNSceco+tWydjOCiav4gkKwNrj4L8/SVF61IsQ6 GxrnaiI6 =vIzG -----END PGP SIGNATURE----- Merge tag 'v7.2-rc-part2-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6 Pull smb client fixes from Steve French: - fix potential double frees - fix potential memory leak in receiving compound response - querydir improvement - fix chown with smb311 posix extensions - ACL setting fixes - minor debug improvement and cleanup - add some missing protocol defines - sparse file fixes * tag 'v7.2-rc-part2-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6: cifs: define variable sized buffer for querydir responses smb/client: do not account EOF extension as allocation smb/client: preserve errors from smb2_set_sparse() smb: client: Fix next buffer leak in receive_encrypted_standard() smb/client: use %pe to print error pointer smb/client: name the default fallocate mode smb common: add missing AAPL defines smb/client: fix chown/chgrp with SMB3 POSIX Extensions smb/client: fix security flag calculation when setting security descriptors smb: client: refactor ACL setting control flow in id_mode_to_cifs_acl() smb: client: fix query directory replay double-free smb: client: fix change notify replay double-free smb: client: fix query_info() replay double-free smb: client: fix double-free in SMB2_close() replay smb: client: fix double-free in SMB2_ioctl() replay smb: client: fix double-free in SMB2_open() replay smb: client: fix double-free in SMB2_flush() replay |
||
Dave Airlie
|
f24ba334af |
drm-misc-fixes for v7.2:
- drm/sysfb truncation and alignment fixes. - fix edid OOB read. - fix error handling paths in nouveau - amdxdna get_bo_info fix. - increase displayid topology id to correct size. - fix leak when error handling in ivpu. -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAmo85ykACgkQ/lWMcqZw E8PkLRAAkGV32MLBhUH8Pcim59wwUr9CgTh8s49m4a/bckBOAWLfc/v1S3lclmAg ov9kS4MptrBkg+7HDK6+3EWWaugQ5e18fS1xMtCpgL0Or8BKG+EaSNjLycJc4Xj8 XDnc9VxRfTBwImN398HWtQhhfXE3cUxgR8pxCnDN2/q+p8C+wG6FxB8d4cSAEzZx mAZasLd8sAyTTIRhYJL5Knxhr0Qgylb8zidCTF5TRWz5YSxC0eqgWpwlWrLiwQ+m Zr+zCmo3nEWVxGdh+saWjjxcCHxjvaoQaeeYBWc4xc88C30kKYqf1ApTloi59A1O D8iHXwU7qTwrUJbKDZv4W3lKd5u+h35qzHIJJldPK79M4LLfEcTMj/tZqYGLz4tP 4buzdlvFgDP48sc989Uku8IDnQHEEeene0oslNaDuSfTJLqOKf/J7Ru0Jggctwdp EGDwWCGrnGS7EPxhThRSEh3DwmAQKlstJ8tfhgLa5jaM0g73sKiM7Ho0oeNwJFnr HkDkweIeFD1/CqJiFyvlHA37Wqa5pZoiptRsqrCdFNalTIMN4UGBat2x2zrAlqFI 88YImrqNKZKHqbJIiAWWcTRc2/8dLh6GU/u4Y0mUl26vj8cD2tkBu9exN3fUraCq kQMhVvEBFVDW3fcv3zl7TaeOy28dL54Obgh37p/xcdFYoEVASrg= =zErp -----END PGP SIGNATURE----- Merge tag 'drm-misc-fixes-2026-06-25' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes drm-misc-fixes for v7.2: - drm/sysfb truncation and alignment fixes. - fix edid OOB read. - fix error handling paths in nouveau - amdxdna get_bo_info fix. - increase displayid topology id to correct size. - fix leak when error handling in ivpu. Signed-off-by: Dave Airlie <airlied@redhat.com> From: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patch.msgid.link/2d17f718-43f5-4772-9c04-a975c9ad4bc3@linux.intel.com |
||
|
Dave Airlie
|
b41df707b6 |
Merge tag 'drm-intel-next-fixes-2026-06-25-1' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-next
- Fix corrupted display output on GLK, #16209 (Ville) - Add missing Spectre mitigation for parallel submit IOCTL (Joonas) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patch.msgid.link/ajzIhInnHnGCwMlu@jlahtine-mobl |
||
Lyude Paul
|
fa8cc4e306 |
rust: faux: Allow retrieving a bound Device
When writing up some rust code that used faux devices for unit testing, I noticed that we never actually added the Bound device context to faux::Registration's AsRef<device::Device> implementation. This being said: the Registration object itself is proof that a driver is bound to the device - so this should be safe. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260612194436.585385-4-lyude@redhat.com Signed-off-by: Danilo Krummrich <dakr@kernel.org> |
||
Guopeng Zhang
|
da43ea2139 |
cgroup: Use data_race() for task->flags in task_css_set_check()
task_css_set_check() uses rcu_dereference_check() to verify that task->cgroups can be dereferenced. One accepted condition is that the task is already exiting, tested by checking PF_EXITING in task->flags. This check is only part of the CONFIG_PROVE_RCU lockdep predicate. This was found by KCSAN during fuzz testing. KCSAN can report a data race when another task flag bit is updated concurrently. One report shows pids_release() reading task->flags through task_css_set_check() while do_task_dead() sets PF_NOFREEZE: KCSAN: data-race in task_css() [inline] KCSAN: data-race in pids_release() task_css() pids_release() cgroup_release() release_task() wait_task_zombie() value changed: 0x0040004c -> 0x0040804c The changed bit is PF_NOFREEZE, not PF_EXITING. PF_EXITING remains set before and after the update, so the task_css_set_check() condition does not change. This is not a race on task->cgroups and does not indicate incorrect pids charging or uncharging. tools/memory-model/Documentation/access-marking.txt recommends data_race() for data-racy loads used only for diagnostic purposes. Use data_race() here to mark the intended diagnostic-only access. No functional change intended. Suggested-by: Tejun Heo <tj@kernel.org> Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn> Signed-off-by: Tejun Heo <tj@kernel.org> |
||
|
Linus Torvalds
|
4edcdefd40 |
bpf-fixes
-----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE+soXsSLHKoYyzcli6rmadz2vbToFAmo9if4ACgkQ6rmadz2v bTqujQ/+IUqsYYfnOzxHoaWOy5aLFDjjFBwbbBqU3qBrgkAVNa1xLtuM2Dt/zro9 eNBHa1OitQG4ZZ3ZjFqw7W+ErsUlUagYXa3ldmlpNs1euDqAtLgg6lW8sYj5zIfn KV9coUxArcos8hdX3YQqV3ZWFxFvTuEduniW502swYGTjUXLjBrbPhHhyXVtf3i4 v6MMYkraWSo3ez8Wh+TiyfkOFVNP5JoDRP66vmN5k90B4VuZgVHIQsXp/kFPTmxL XpbGRF4/SevWgE5TEY7tBjwWV5aOcsPL55H6lStMt2ViOdQyWCGF6CY8UISXMC3L WlWu8e4ICpg9YWOXb98pfp8f2mZW7J8ppa3fed0IRcnHh40ywG69ubNJSddPLfFf LtzR3wCQd4DIg0CqWcGnAuOTgioLh3GEwQJ1JzjFmKHw7wlsD4PzoJ6jFdwop6zw 2/3tKv/9jhcM9yeLWW7qFiySMxsENbkhkje/hqWd24PL6HKj2d5mXzoX8Msq1ccE VQ3HGjXHLawTSQ4YDUp4NoZh7E7KkKZkH8UHS8YgrlQsshdTpuiVpmtX08cJHNWP 0SpSVMYxvZtOBbrbCk7qyu/H6ubUod6gscdB2L6t06QjEYl4GyurpP1Uygs9hGy8 9vlUSBRxSa7u7VAAEolgxkiutWfD4CnulYX02f4H1h+jfBKEMQA= =wnIr -----END PGP SIGNATURE----- Merge tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf Pull bpf fixes from Alexei Starovoitov: - Fix effective prog array index with BPF_F_PREORDER (Amery Hung) - Zero-initialize the fib lookup flow struct (Avinash Duduskar) - Disable xfrm_decode_session hook attachment (Bradley Morgan) - Allow type tag BTF records to succeed other modifier records (Emil Tsalapatis) - Fix build_id caching in stack_map_get_build_id_offset() (Ihor Solodrai) - Add missing access_ok call to copy_user_syms (Jiri Olsa) - Fix stack slot index in nospec checks (Nuoqi Gui) - Preserve pointer spill metadata during half-slot cleanup (Nuoqi Gui) - Fix partial copy of non-linear test_run output (Sun Jian) - Fix BPF_PROG_ASSOC_STRUCT_OPS last field check (Thiébaud Weksteen) - Reset register bounds before narrowing retval range (Tristan Madani) - Fix vmlinux BTF leak in bpftool cgroup commands (Yichong Chen) - Guard error writes in conntrack kfuncs (Yiyang Chen) * tag 'bpf-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: bpf: Disable xfrm_decode_session hook attachment selftests/bpf: Add test for stale bounds on LSM retval context load bpf: Reset register bounds before narrowing retval range in check_mem_access() selftests/bpf: Cover small conntrack opts error writes bpf: Guard conntrack opts error writes selftests/bpf: Cover half-slot cleanup of pointer spills bpf: Preserve pointer spill metadata during half-slot cleanup selftests/bpf: Test cgroup link replace with BPF_F_PREORDER bpf: Fix effective prog array index with BPF_F_PREORDER bpf: Fix BPF_PROG_ASSOC_STRUCT_OPS last field check bpf: zero-initialize the fib lookup flow struct bpftool: Fix vmlinux BTF leak in cgroup commands bpf: Add missing access_ok call to copy_user_syms bpf: Allow type tag BTF records to succeed other modifier records bpf: Emit verbose message when prog-specific btf_struct_access rejects a write bpf: Fix build_id caching in stack_map_get_build_id_offset() bpf: Fix partial copy of non-linear test_run output selftests/bpf: Cover stack nospec slot indexing bpf: Fix stack slot index in nospec checks |
||
Cheng-Yang Chou
|
e2c60e15d0 |
sched_ext: Convert scx_arena_grow() to use scx_arena_to_kaddr()
scx_arena_grow() was left open-coded when
|
||
|
Linus Torvalds
|
8c04c1292d |
This is all clk driver updates. Mostly new SoC support for
various Qualcomm chips and Canaan K230. Otherwise there's non-critical fixes and updates to clk data such as adding missing clks to existing drivers or marking clks critical. Nothing looks especially exciting. -----BEGIN PGP SIGNATURE----- iQJIBAABCAAyFiEE9L57QeeUxqYDyoaDrQKIl8bklSUFAmo9Q6oUHHN3Ym95ZEBj aHJvbWl1bS5vcmcACgkQrQKIl8bklSXXFA/9GpTMt3p0Mi/sT/AszYTU+RsVXGpW q7XQ3MnO6rzd/NvzVGTptmQdbOj54jl1yXosEmTs+Won9OtSuOPjxVamtDRTJMpl YOT5ixy4JNVBxwdxgyrSIoEQ6+MhTj91uBXA74MiO6Kk2CFTEHafTQC2P0HQyPv9 aaHx53ViKM6UwI6IgWajfmRS8CMzWlEjPFF6v9zG8vWAls22J1SkrW5h7ovFJM2F osl6OkNc6prRc0gOrhzmtekX2e1e3Eg9HKlXwNV58LRtysXMpmqTm2zYvxv0iltb GV2V5fX9fcJI45dWOGStxJ2mO6NswDWjNYF9kFefvpqVrRRluhX+Af9/bbqTwVXt +PEHsdJYRTzlaIbMuGfASTqmo6Sp5MkHG1PV5tAQglX16yVNMqk11gjoPHVA4zEF CRkC494s4nX2XMM85MBeqTyh8bue0LQqz9QAsUBaU0XRvJJhDMw81P34QOFTfq9n UEBmnv+dRqsHvXQsJzB+8q+F+kx12M3GIkGqX/O1eZT+9sGjTVY3XFIbvH01vN4W OGUB9q6ZixD25d8MA6mussel2O6An4S7NU+zRsSz1xZd2W7IGNtk908dr7mJOh13 8rG9DW73XRpKNYhX/IszDFjyPHUuZPYU8RyYTwf63ADGJHVVFcHZ78V4ORuPh2AY TnZt1wOsq1a/xd8= =hEhO -----END PGP SIGNATURE----- Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux Pull clk updates from Stephen Boyd: "This is all clk driver updates. Mostly new SoC support for various Qualcomm chips and Canaan K230. Otherwise there's non-critical fixes and updates to clk data such as adding missing clks to existing drivers or marking clks critical. Nothing looks especially exciting" * tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (106 commits) clk: qcom: regmap-phy-mux: Rework the implementation clk: qcom: a53: Corrected frequency multiplier for 1152MHz clk: qcom: camcc-milos: Declare icc path dependency for CAMSS_TOP_GDSC clk: qcom: gdsc: Support enabling interconnect path for power domain dt-bindings: clock: qcom,milos-camcc: Document interconnect path interconnect: Add devm_of_icc_get_by_index() as exported API for users clk: qcom: camcc-x1p42100: Add support for camera clock controller clk: qcom: camcc-x1e80100: Add support for camera QDSS debug clocks clk: qcom: videocc-x1p42100: Add support for video clock controller dt-bindings: clock: qcom: Add X1P42100 camera clock controller dt-bindings: clock: qcom: Add X1P42100 video clock controller clk: keystone: sci-clk: fix application of sizeof to pointer clk: keystone: don't cache clock rate clk: spacemit: k3: Add PCIe DBI clock dt-bindings: soc: spacemit: k3: Add PCIe DBI clock IDs clk: spacemit: k3: Fix PCIe clock register offset clk: spacemit: k3: Switch to pll2_d6 as parent for PCIe clock clk: at91: keep securam node alive while mapping it clk: samsung: exynos990: Fix PERIC0/1 USI clock types clk: renesas: r9a08g045: Drop unused pm_domain header file ... |
||
Samuel Holland
|
c4c7756a81 |
riscv: Fix 32-bit call_on_irq_stack() frame pointer ABI
call_on_irq_stack() uses struct member offsets to set up its link in the
frame record list. On riscv32, struct stackframe is the wrong size to
maintain stack pointer alignment, so STACKFRAME_SIZE_ON_STACK includes
padding. However, the ABI requires the frame record to be placed
immediately below the address stored in s0, so the padding must come
before the struct members.
Fix the layout by making STACKFRAME_FP and STACKFRAME_RA the negative
offsets from s0, instead of the positive offsets from sp.
Fixes:
|
||
|
Linus Torvalds
|
ca3e303061 |
Support for Qualcomm PMIC arbiter v8.5 and Hawi along with a
kernel doc cleanup and a kzalloc flex usage. -----BEGIN PGP SIGNATURE----- iQJIBAABCAAyFiEE9L57QeeUxqYDyoaDrQKIl8bklSUFAmo9RuQUHHN3Ym95ZEBj aHJvbWl1bS5vcmcACgkQrQKIl8bklSWCyRAA0FGsUKaLRGB7NLY/UfuW0mUVCJul ATYOFizoIwWRuCzp/3pZDW4efinpHcmm27n62FkEXCp32R0Cga7TVTXi7Q0gCymh sgQ0eg6pnMobpf7OYb2vMf2eybcQKzg4OHyp+6+XSO9fysmdsWxsZu6+O986gJGU zu/c+7uTfIAAMHsuA3IQvEzimvG+dEPruOCIujF9QdyM7E668TuBUyG/cydyjofG drze/rrf/yiM9HBsUlXeVJYnmvu+qN2Nh9NLWVk48rpz6cs+bLlQDrp5g+gUBgSH ZB0K23UgM7biuPKUdMok7yUc0rMvD0fvlMCrgMTc5KLem0Rem01WfVgDLjMRUYay gepkv5aAi9Rf9CWXwu8NaXBi4henhuBc6UuCzTclw0HjuT8J7NwAqUW52hZDW19v 1n2w22hgJHma7ObOTTkmk45IENq55GwGI2KTGc8uOa3azh4uwxjMBA0TiLdyfjvR okd6ze1/7HX+LF5BIclElabMWd6aln5kZzMyEWA/nMoSsPEHMVz5vkA5qvi2674i ZpCN3Vje2CgOSJb5tGOjO7b0MB7TIyVf4h1/oFhIKh8QJhHY/yz21l90sr/IS80Y 5VONAJ4aoBhv8OE/EDAJWHeWx9mfHL6ASmjMU6Isn8+QRL9gUK2PKURnTjed+IYB +Hv89rnt7WUxPYo= =W+GR -----END PGP SIGNATURE----- Merge tag 'spmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi Pull SPMI updates from Stephen Boyd: "Support for Qualcomm PMIC arbiter v8.5 and Hawi along with a kernel doc cleanup and a kzalloc flex usage" * tag 'spmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sboyd/spmi: spmi: use kzalloc_flex in main allocation spmi: clean up kernel-doc in spmi.h spmi: spmi-pmic-arb: add support for PMIC arbiter v8.5 dt-bindings: spmi: glymur-spmi-pmic-arb: Add compatible for Qualcomm Hawi SoC |
||
|
Linus Torvalds
|
75218b7ace |
rtla fixes for 7.2:
- Fix and cleanup .gitignore - Fix pgrep filter in get_workload_pids.sh Fix parsing of kernel thread names in get_workload_pids() helper function. On some systems pgrep matches kernel thread names including the brackets (e.g. "[osnoise/0]") and other systems brackets are not included. Fix the tests to handle both. -----BEGIN PGP SIGNATURE----- iIoEABYKADIWIQRRSw7ePDh/lE+zeZMp5XQQmuv6qgUCaj0udBQccm9zdGVkdEBn b29kbWlzLm9yZwAKCRAp5XQQmuv6qgS1AQD8bo/T+tyBeumqV/gmObk+dRd1SVI/ H0aVZ+f7mmns1gEAiFLn0vWm0zslNjOAhn9exC7FVTScRXdTB6ehN6zBbQQ= =fhMS -----END PGP SIGNATURE----- Merge tag 'trace-tools-7.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace Pull rtla fixes from Steven Rostedt: - Fix and cleanup .gitignore - Fix pgrep filter in get_workload_pids.sh Fix parsing of kernel thread names in get_workload_pids() helper function. On some systems pgrep matches kernel thread names including the brackets (e.g. "[osnoise/0]") and other systems brackets are not included. Fix the tests to handle both. * tag 'trace-tools-7.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace: rtla/tests: Fix pgrep filter in get_workload_pids.sh rtla: Fix and clean up .gitignore |
||
|
Linus Torvalds
|
805185b7c7 |
Including fixes from netfilter and IPsec.
Current release - regressions:
- net: do not acquire dev->tx_global_lock in netdev_watchdog_up()
- net: ethtool: keep rtnl_lock for ops using ethtool_op_get_link()
- net: fix deadlock in nested UP notifier events
Current release - new code bugs:
- eth: cn20k: fix subbank free list indexing for search order
- eth: airoha: fix BQL underflow in shared QDMA TX ring
Previous releases - regressions:
- netfilter:
- flowtable: fix offloaded ct timeout never being extended
- nf_conncount: prevent connlimit drops for early confirmed ct
Previous releases - always broken:
- require CAP_NET_ADMIN in the originating netns when modifying
cross-netns devices
- report NAPI thread PID in the caller's pid namespace
- mac802154: fix dirty frag in in-place crypto for IOT radios
- sctp: hold socket lock when dumping endpoints in sctp_diag,
avoid an overflow
- eth: gve: fix header buffer corruption with header-split and HW-GRO
- af_key: initialize alg_key_len for IPComp states, prevent OOB read
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE6jPA+I1ugmIBA4hXMUZtbf5SIrsFAmo9ZaUACgkQMUZtbf5S
IrtO5w/+JgRT+RjKiCCLsEUM1R9hCA2Hxhos99YFpmMZitU2v3IZIdD/sZL6Ppxa
fq7hlsfMicF/isez+sharJ8H8NrX5MZ9YtvcbbRG2+aUPlAJDVSfxbqCcsjEMqdP
s4wtAhUoPwIVpw/rwcSSubQrGFTJlshVi1Yp48xxNHzNAk1wNoitSeKS+lAToaJf
6ZUl9uamxrbMG8j9FBOSWeOcQ2ywmrQiSGbRy74X0qolRfS+1r0pNchwGsv8s2RP
Sa3an4qfD3vBV0YNh8KglycBuvU6LMAt90/XIZ6zY8TBzISyM9PgrQbcNqKMlxQ0
LNPy5qosWvIEFVBjrUlw1IyyfSWOBnybwXViIE83/x/sUTyhRX4vnn20hdNlMyB2
FkWfU1C/X+D/idSoynCXGY4VXq7ikkfvTOXlTGcd9Q8sse98sQV+TpeVdu5gkqX8
KvjhIM896Kt4eVHkmVQ0DCu+GN8srbzmMCoPqBv04zfQX4rk9tWH4iyMIaNgniZe
8SrgFg3IA/WoaIU+Ac3oc2LNCf0XbeNQXMSfTu5t3H1bXgteDzdar/ncNXaPx/S2
72kP35DooMpgApP4TbpxiPZ1bVSfFK7mtoxxdHQVZVGwo9NY1Fz2eqpG28y/pk18
RXn2GSfeEmzsPGRYte+09QkwoaDnRj5GZ2ETbVxibPmJ71t6Iz0=
=dIVQ
-----END PGP SIGNATURE-----
Merge tag 'net-7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Jakub Kicinski:
"Including fixes from netfilter and IPsec.
Current release - regressions:
- do not acquire dev->tx_global_lock in netdev_watchdog_up()
- ethtool: keep rtnl_lock for ops using ethtool_op_get_link()
- fix deadlock in nested UP notifier events
Current release - new code bugs:
- eth:
- cn20k: fix subbank free list indexing for search order
- airoha: fix BQL underflow in shared QDMA TX ring
Previous releases - regressions:
- netfilter:
- flowtable: fix offloaded ct timeout never being extended
- nf_conncount: prevent connlimit drops for early confirmed ct
Previous releases - always broken:
- require CAP_NET_ADMIN in the originating netns when modifying
cross-netns devices
- report NAPI thread PID in the caller's pid namespace
- mac802154: fix dirty frag in in-place crypto for IOT radios
- sctp: hold socket lock when dumping endpoints in sctp_diag, avoid
an overflow
- eth: gve: fix header buffer corruption with header-split and HW-GRO
- af_key: initialize alg_key_len for IPComp states, prevent OOB read"
* tag 'net-7.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (213 commits)
selftests: bonding: add a test for VLAN propagation over a bonded real device
vlan: defer real device state propagation to netdev_work
net: add the driver-facing netdev_work scheduling API
net: turn the rx_mode work into a generic netdev_work facility
net: ethtool: keep rtnl_lock for ops using ethtool_op_get_link()
rxrpc: Fix rxrpc_rotate_tx_rotate() to check there's something to rotate
rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)
rxrpc: Fix socket notification race
rxrpc: Fix potential infinite loop in rxrpc_recvmsg()
rxrpc: Fix oob challenge leak in cleanup after notification failure
rxrpc: Fix the reception of a reply packet before data transmission
afs: Fix uncancelled rxrpc OOB message handler
afs: Fix further netns teardown to cancel the preallocation charger
rxrpc: Fix double unlock in rxrpc_recvmsg()
rxrpc: Fix leak of connection from OOB challenge
rxrpc: Fix ACKALL packet handling
net: hns3: differentiate autoneg default values between copper and fiber
net: hns3: fix permanent link down deadlock after reset
net: hns3: refactor MAC autoneg and speed configuration
net: hns3: unify copper port ksettings configuration path
...
|
||
Wang Han
|
57ad674d03 |
scripts/sorttable: Handle RISC-V patchable ftrace entries
RISC-V uses -fpatchable-function-entry=8,4 when the compressed ISA is
enabled and -fpatchable-function-entry=4,2 otherwise. In both cases, the
patchable NOP area starts 8 bytes before the function symbol address.
The __mcount_loc entries therefore point at the patchable NOP area
associated with a function, while nm reports the function symbol at the
entry address used for the function range check.
After RISC-V selected HAVE_BUILDTIME_MCOUNT_SORT, sorttable started
applying that range check at build time. Without allowing entries just
before the reported function address, the mcount sorter treats valid
RISC-V ftrace callsites as invalid weak-function entries and writes
them back as zero. The resulting kernel boots with no ftrace entries,
breaking dynamic ftrace and users such as livepatch.
The failure is silent during the final link because zeroing weak-function
entries is an expected sorttable operation. At boot, those zero entries
are skipped by ftrace_process_locs(), so the only obvious symptom is that
the vmlinux ftrace table has lost valid callsites and ftrace users cannot
attach to them.
CONFIG_FTRACE_SORT_STARTUP_TEST also reports the table as sorted in this
state: it only checks that the __mcount_loc entries are in ascending
order, which a fully zeroed table trivially satisfies. The original
commit relied on this check and did not see the regression.
On an affected RISC-V QEMU boot with both CONFIG_FTRACE_SORT_STARTUP_TEST
and CONFIG_FTRACE_STARTUP_TEST enabled, the sort check still passes
while ftrace reports zero usable entries and the early selftests fail:
[ 0.000000] ftrace section at ffffffff8101da98 sorted properly
[ 0.000000] ftrace: allocating 0 entries in 128 pages
[ 0.054999] Testing tracer function: .. no entries found ..FAILED!
[ 0.172407] tracer: function failed selftest, disabling
[ 0.178186] Failed to init function_graph tracer, init returned -19
Handle RISC-V like arm64 for the function-range check and allow
patchable entries up to 8 bytes before the function address.
With this fix, a RISC-V QEMU smoke boot with ftrace startup tests shows
the vmlinux ftrace table is populated and dynamic ftrace still works:
[ 0.000000] ftrace: allocating 46749 entries in 184 pages
[ 0.051115] Testing tracer function: PASSED
[ 1.283782] Testing dynamic ftrace: PASSED
[ 6.275456] Testing tracer function_graph: PASSED
Fixes: 0ca1724b56af ("riscv: ftrace: select HAVE_BUILDTIME_MCOUNT_SORT")
Suggested-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Reviewed-by: Shuai Xue <xueshuai@linux.alibaba.com>
Reviewed-by: Chen Pei <cp0613@linux.alibaba.com>
Link: https://lore.kernel.org/all/20260527113028.4b21a5de@fedora/
Signed-off-by: Wang Han <wanghan@linux.alibaba.com>
Reviewed-by: Martin Kaiser <martin@kaiser.cx>
Link: https://patch.msgid.link/20260609063002.3943001-1-wanghan@linux.alibaba.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
|
||
|
Lyude Paul
|
616c229ab0 |
rust: drm: gem: Introduce shmem::Object::sg_table()
In order to do this, we need to be careful to ensure that any interface we expose for scatterlists ensures that any mappings created from one are destroyed on driver-unbind. To do this, we introduce a Devres resource into shmem::Object that we use in order to ensure that we release any SGTable mappings on driver-unbind. There's some other slightly unfortunate caveats of this: * Drivers don't have explicit control at the moment over when unmapping happens (which is exactly the same as the C side atm, so it might not be a problem). * We can't just return `SGTableMap` to the user through an Arc to attempt to fix the last caveat - because that implies the gem object would need to hold a reference count to the scatterlist mapping, which just leaves us with the same problem. Signed-off-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260612194436.585385-5-lyude@redhat.com |
||
Thorsten Blum
|
68fb3c026b |
riscv: smp: use secs_to_jiffies in __cpu_up
Use secs_to_jiffies() to simplify the code. Drop the redundant zero initialization while at it. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260611232537.467398-3-thorsten.blum@linux.dev Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
Yicong Yang
|
b8f62414fa |
ACPI: RIMT: Only defer the IOMMU configuration in init stage
The IOMMU configuration will be deferred if the IOMMU driver
isn't probed by the time. Make this deferral only in the
initialization stage with driver_deferred_probe_check_state().
Otherwise the devices depends on IOMMU will be deferred forever
in case the IOMMU device probe failed or it doesn't appear in
the ACPI namespace.
Fixes:
|
||
Bastian Blank
|
c8c5a7835f |
riscv: Add build salt to the vDSO
The vDSO needs to have a unique build id in a similar manner to the kernel and modules. Use the build salt macro. Signed-off-by: Bastian Blank <waldi@debian.org> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/ajQY7n0an0YwQ--j@steamhammer.waldi.eu.org Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
Ben Dooks
|
5c5dea43f6 |
raid6: fix raid6_recov_rvv symbol undeclared warning
The riscv recov_rvv.c should have included pq_arch.h for the definition of raid6_recov_rvv. Add the include to fix the following sparse warning: lib/raid/raid6/riscv/recov_rvv.c:218:32: warning: symbol 'raid6_recov_rvv' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260622135535.481534-1-ben.dooks@codethink.co.uk Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Ben Dooks
|
625ee71c32 |
raid6: fix riscv symbol undeclared warnigns
The riscv rvv.c file is missing the include of pq_arch.h which defines all the exported functions. Include this to remove the following sparse warnings: lib/raid/raid6/riscv/rvv.c:1225:1: warning: symbol 'raid6_rvvx1' was not declared. Should it be static? lib/raid/raid6/riscv/rvv.c:1226:1: warning: symbol 'raid6_rvvx2' was not declared. Should it be static? lib/raid/raid6/riscv/rvv.c:1227:1: warning: symbol 'raid6_rvvx4' was not declared. Should it be static? lib/raid/raid6/riscv/rvv.c:1228:1: warning: symbol 'raid6_rvvx8' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Reviewed-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260622135207.480540-1-ben.dooks@codethink.co.uk Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
Vivian Wang
|
0fa7497719 |
riscv: Raise default NR_CPUS for 64BIT to 256
SpacemiT has already produced a 80-core RVA23 RISC-V server [1], and going further back, the dual-socket SG2042-based Sophgo Pisces has 128 cores (although that had some issues achieving mainline support). Therefore, an NR_CPUS of 64 is not enough. Raise default NR_CPUS to 256 for 64BIT (when !RISCV_SBI_V01, since very old firmware can't support more than 64 cores). The number was picked as a power of two that is at least double the known max. I believe this should be the right balance between not wasting too much memory and not having to touch this too often. Ubuntu has already been shipping NR_CPUS=512 for riscv64. We have also been testing NR_CPUS=256 internally at ISCAS and found negligible performance impact and no ill effects. Reported-by: Lufei Zheng <lufei.zheng@spacemit.com> Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1140651 # [1] Suggested-by: Han Gao <gaohan@iscas.ac.cn> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Link: https://patch.msgid.link/20260625-riscv-more-nr-cpus-v1-1-5da8c72b9269@iscas.ac.cn Signed-off-by: Paul Walmsley <pjw@kernel.org> |
||
|
Linus Torvalds
|
c75597caad |
s390:
* Fix S390_USER_OPEREXEC so it can now be enabled regardless of other
unrelated capabilities
* Fix handling of the _PAGE_UNUSED pte bit that could lead to guest
memory corruption in some scenarios
* A bunch of misc gmap fixes (locking, behaviour under memory pressure)
* Fix CMMA dirty tracking
x86:
* Tidy up some WARN_ON() and BUG_ON(), replacing them with WARN_ON_ONCE()
or KVM_BUG_ON(). All of these have obviously never triggered, or
somebody would have been annoyed earlier, but still.
* Fix missing interrupt due to stale CR8 intercept
* Add a statistic that can come in handy to debug leaks as well as the
vulnerability to a class of recently-discovered issues.
* Do not ask arch/x86/kernel to export default_cpu_present_to_apicid()
just for KVM.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmo7xaAUHHBib256aW5p
QHJlZGhhdC5jb20ACgkQv/vSX3jHroN7bwf/Ua6PrRrgdzfUGiIruBDnFGtXnaKf
UPGpgl35Kl4ntPlmH6wRG6N0jP9sloa17Qj/Y33O1Um3Mi/eDV0UESW8o8tfFE2J
CWUPc3/adw2urhnkXsoleSFy21a89TgLd0p4tot832p+IHi3iNJ45fx7XxftBeGt
fa/liscncEX5tGwie0ZVkIEE/ob3+eX4ZYsTLXMi6FxAlyGPYNrp4jwJeYH9AFSd
ZYGqVbDjDq14vhnppKXM8DMfHTXN4OVYw2RJZ9Y7u2h7ku3sN0XakzVTAUz5gtoM
h+iu8dn5yslODBZiNGlls8UYm2bweOBCumH1ZITe/eTNuEdUOJGILorKRw==
=QzfV
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
"s390:
- Fix S390_USER_OPEREXEC so it can now be enabled regardless of other
unrelated capabilities
- Fix handling of the _PAGE_UNUSED pte bit that could lead to guest
memory corruption in some scenarios
- A bunch of misc gmap fixes (locking, behaviour under memory
pressure)
- Fix CMMA dirty tracking
x86:
- Tidy up some WARN_ON() and BUG_ON(), replacing them with
WARN_ON_ONCE() or KVM_BUG_ON(). All of these have obviously never
triggered, or somebody would have been annoyed earlier, but still...
- Fix missing interrupt due to stale CR8 intercept
- Add a statistic that can come in handy to debug leaks as well as
the vulnerability to a class of recently-discovered issues
- Do not ask arch/x86/kernel to export
default_cpu_present_to_apicid() just for KVM"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (22 commits)
x86/apic: KVM: Use cpu_physical_id() to get APIC ID of running vCPU for AVIC
KVM: x86/mmu: Expose number of shadow MMU shadow pages as a stat
KVM: x86: Unconditionally recompute CR8 intercept on PPR update
KVM: VMX: Grab vmcs12 on CR8 interception update iff vCPU is in guest mode
KVM: x86: WARN (once) if RTC pending EOI tracking goes off the rails
KVM: x86: WARN and fail kvm_set_irq() if a PIC or I/O APIC vector is invalid
KVM: x86: Bug the VM, not the kernel, if the ISR count {under,over}flows
KVM: x86/mmu: Bug the VM, not the host kernel, if KVM write-protects upper SPTEs
KVM: x86: Replace BUG_ON() with WARN_ON_ONCE() on "bad" nested GPA translation
KVM: Replace guest-triggerable BUG_ON() in ioeventfd datamatch with get_unaligned()
KVM: s390: Return failure in case of failure in kvm_s390_set_cmma_bits()
KVM: s390: selftests: Fix cmma selftest
KVM: s390: Fix cmma dirty tracking
KVM: s390: Fix locking in kvm_s390_set_mem_control()
KVM: s390: Fix handle_{sske,pfmf} under memory pressure
KVM: s390: Fix code typo in gmap_protect_asce_top_level()
KVM: s390: Do not set special large pages dirty
KVM: s390: Fix dat_peek_cmma() overflow
s390/mm: Fix handling of _PAGE_UNUSED pte bit
KVM: s390: Fix typo in UCONTROL documentation
...
|
||
Jakub Kicinski
|
fe9f4ee6c6 |
Merge branch 'net-avoid-nested-up-notifier-events'
Jakub Kicinski says:
====================
net: avoid nested UP notifier events
syzbot reported that recent ethtool rework leads to deadlock
on stacked devices. VLANs create nested notifications, confusing
execution context. Bringing up dummy causes vlan to bring itself
up as well. Which in turn causes bond to ask for link state -
a call chain traveling in the opposite direction.
bond (3) bond_update_speed_duplex(vlan)
| ^ v
vlan (2) UP(vlan) (4) vlan_ethtool_get_link_ksettings()
| ^ v
dummy (1) UP(dummy) (5) __ethtool_get_link_ksettings()
We locked the instance lock of dummy at (1) and will will
try to lock it again at (5) - which of course deadlocks.
For non-nested notifications this is avoided because NETDEV_UP
is always run ops-locked (so that bond asks for link using the
netif_ API which assumes instance lock already held). The nesting,
however, makes this problematic, we cannot carry the state of
the whole chain back in the opposite direction.
AFAICT vlan is the only driver which causes such issues.
So let's try a localized fix of deferring vlan auto-open
to a workqueue.
====================
Link: https://patch.msgid.link/20260624182018.2445732-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
||
|
Jakub Kicinski
|
e83d0a2472 |
selftests: bonding: add a test for VLAN propagation over a bonded real device
Add a regression test for the VLAN notifier handling that the netdev_work deferral fixed. A VLAN's real device propagates its UP/DOWN, MTU and feature changes onto the VLANs stacked on top of it. This used to be done synchronously from the real device's notifier and deadlocked when the real device was brought up while enslaved to a bond (instance lock held across NETDEV_UP) and the VLAN on top was itself a bond member: the synchronous propagation re-entered the stack and took the same instance lock again. The test covers both halves: - that the deferred UP/DOWN, MTU and feature propagation actually lands on the VLAN (link state and MTU use an ops-locked dummy, i.e. the deferral path; features use veth, which exports vlan_features to inherit), and - that the deadlock-prone topology - a VLAN on a dummy, with the VLAN and the dummy each enslaved to a different bond - can be built without hanging. Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20260624182018.2445732-5-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Jakub Kicinski
|
cd1c188db1 |
vlan: defer real device state propagation to netdev_work
vlan_device_event() generates nested UP/DOWN, MTU and feature
change events. It executes an event for the VLAN device directly
from the notifier - while the locks of the lower device are held.
This causes deadlocks, for example:
bond (3) bond_update_speed_duplex(vlan)
| ^ v
vlan (2) UP(vlan) (4) vlan_ethtool_get_link_ksettings()
| ^ v
dummy (1) UP(dummy) (5) __ethtool_get_link_ksettings()
The dummy device is ops locked, vlan creates a nested event (2),
then bond wants to ask vlan for link state (3). bond uses the
"I'm already holding the instance lock" flavor of API. But in
this case the lock held refers to vlan itself. We hit vlan's
link settings trampoline (4) and call __ethtool_get_link_ksettings()
which tries to lock dummy. Deadlock. There's no clean way for us
to tell the vlan_ethtool_get_link_ksettings() that the caller
is already in lower device's critical section.
Defer the propagation to the per-netdev work facility instead:
the notifier only schedules netdev_work_sched(vlandev, VLAN_WORK_*),
and ndo_work (vlan_dev_work) applies the change later. Hopefully
nobody expects the VLAN state changes to be instantaneous.
If someone does expect the changes to be instantaneous we will
have to do the same thing Stan did for rx_mode and "strategically"
place sync calls, to make sure such delayed works are executed
after we drop the ops lock but before we drop rtnl_lock.
Stan suggests that if we need that down the line we may
consider reshaping the mechanism into "async notifications".
AFAICT only vlan does this sort of netdev open chaining,
so as a first try I think that sticking the complexity into
the vlan code makes sense.
One corner case is that we need to cancel the event if user
explicitly changes the state before work could run. Consider
the following operations with vlan0 on top of dummy0:
ip link set dev dummy0 up # queues work to up vlan0
ip link set dev vlan0 down # user explicitly downs the vlan
ndo_work # acts on the stale event
Reported-by: syzbot+09da62a8b78959ceb8bb@syzkaller.appspotmail.com
Reported-by: syzbot+cb67c392b0b8f0fd0fc1@syzkaller.appspotmail.com
Reported-by: syzbot+9bb8bd77f3966641f298@syzkaller.appspotmail.com
Fixes:
|
||
|
Jakub Kicinski
|
129cdce9da |
net: add the driver-facing netdev_work scheduling API
With an extra event mask we can easily extend the netdev work to also service driver-defined events. For advanced drivers this is probably not a perfect match, but it makes running deferred work easier in simple cases. Expose the netdev_work facility to drivers. Add helpers to schedule work and a dedicated ndo to perform the driver- -scheduled actions. Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20260624182018.2445732-3-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Jakub Kicinski
|
12c765be84 |
net: turn the rx_mode work into a generic netdev_work facility
The rx_mode update runs from a workqueue: drivers have their ndo_set_rx_mode_async() callback executed by a single global work item under RTNL and ops lock. This is a useful pattern. Support multiple "events" that need to be serviced and make RX_MODE sync the first one. Call the events "core" because later on we will let drivers define and schedule their own. Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com> Acked-by: Stanislav Fomichev <sdf@fomichev.me> Link: https://patch.msgid.link/20260624182018.2445732-2-kuba@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org> |
||
|
Jakub Kicinski
|
1105ef941c |
net: ethtool: keep rtnl_lock for ops using ethtool_op_get_link()
Breno reports following splats on mlx5:
RTNL: assertion failed at net/core/dev.c (2241)
WARNING: net/core/dev.c:2241 at netif_state_change+0xed/0x130, CPU#5: ethtool/1335
RIP: 0010:netif_state_change+0xf9/0x130
Call Trace:
<TASK>
__linkwatch_sync_dev+0xea/0x120
ethtool_op_get_link+0xe/0x20
__ethtool_get_link+0x26/0x40
linkstate_prepare_data+0x51/0x200
ethnl_default_doit+0x213/0x470
genl_family_rcv_msg_doit+0xdd/0x110
Looks like I missed ethtool_op_get_link() trying to sync linkwatch,
which needs rtnl_lock. Not all drivers do this - bnxt doesn't,
it just returns the link state, so add an opt-in bit.
Reported-by: Breno Leitao <leitao@debian.org>
Fixes:
|
||
|
Jakub Kicinski
|
2c0f1b651d |
Merge branch 'rxrpc-miscellaneous-fixes'
David Howells says:
====================
rxrpc: Miscellaneous fixes
Here are some miscellaneous AF_RXRPC fixes for more stuff found by Sashiko[1][2]:
(1) Fix ACKALL handling by adding two more call states to simplify when
ACKs are valid.
(2) Fix connection leak from AF_RXRPC recvmsg userspace OOB handling.
(3) Fix double unlock in AF_RXRPC recvmsg userspace OOB handling.
(4) Fix AFS preallocate charge to flush the waitqueue after unlistening
the socket so that any charging thread that does manage to get started
will be waited for before socket destruction.
(5) Fix AFS OOB notify handling to cancel in-progress OOB notification
handling and then to flush the workqueue it's on.
(6) Fix handling of apparent reply reception before initial transmission
starts in client call.
(7) Fix OOB challenge leak in cleanup on notification failure.
(8) Fix infinite loop in recvmsg if OOB packet available, but no calls.
(9) Fix notify vs recvmsg race where notify thinks the call is already
queued.
(10) Fix MSG_PEEK call leak for calls with no content.
(11) Fix rxrpc_rotate_tx_window() to check that there's something in the Tx
buffer before attempting to rotate it.
====================
Link: https://patch.msgid.link/20260624163819.3017002-1-dhowells@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
||
David Howells
|
a5462da5a3 |
rxrpc: Fix rxrpc_rotate_tx_rotate() to check there's something to rotate
Fix rxrpc_rotate_tx_rotate() to check that there's something in the
transmission buffer to be rotated before it attempts to rotate anything.
Fixes:
|
||
|
David Howells
|
4bdb9e471f |
rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)
Fix rxrpc_recvmsg() to also drop the ref it holds on an already-released
call if MSG_PEEK is in force (the function holds a ref on the call
irrespective of whether MSG_PEEK is specified or not).
Fixes:
|
||
|
David Howells
|
e66f8f32f5 |
rxrpc: Fix socket notification race
There's a race between rxrpc_recvmsg() and rxrpc_notify_socket(), whereby
the latter's attempt to avoid disabling interrupts and taking the socket's
recvmsg_lock if the call is already queued may happen simultaneously with
the former's discarding of a call that has nothing queued.
Fix this by removing the shortcut. Note that this only affects userspace's
use of AF_RXRPC; the AFS filesystem driver doesn't use the socket queue.
Fixes:
|
||
|
David Howells
|
67a0332f44 |
rxrpc: Fix potential infinite loop in rxrpc_recvmsg()
Fix the wait in rxrpc_recvmsg() also take check the oob queue.
Fixes:
|
||
|
David Howells
|
092275882a |
rxrpc: Fix oob challenge leak in cleanup after notification failure
Fix rxrpc_notify_socket_oob() to return an indication of failure in the
event that it failed to queue a packet and fix rxrpc_post_challenge() to
clean up the connection ref in such an event.
Fixes:
|
||
|
David Howells
|
a58e33405a |
rxrpc: Fix the reception of a reply packet before data transmission
Fix rxrpc_receiving_reply() to handle the reception of an apparent reply
DATA packet before rxrpc has had a chance to send any request DATA packets
on a client call by checking to see if the call has been exposed yet by
sending the first packet.
Without this, rxrpc_rotate_tx_window() might oops.
Also fix rxrpc_rotate_tx_window() to handle the Tx queue being empty by
changing the do...while loop into a while loop, just in case a call is
abnormally terminated by an early reply before the last request packet is
transmitted.
Fixes:
|