ebpf: dispatch only to interrupt-context runtimes - #766
Merged
Merged
Conversation
lneto
force-pushed
the
claude_ebpf_irqonly
branch
from
September 3, 2026 12:46
b63b7ca to
7bdb355
Compare
lneto
force-pushed
the
claude_closeprivate
branch
2 times, most recently
from
September 3, 2026 14:23
d12e0d2 to
86dbd16
Compare
lneto
force-pushed
the
claude_ebpf_irqonly
branch
from
September 3, 2026 14:23
7bdb355 to
6baf3d9
Compare
lneto
force-pushed
the
claude_closeprivate
branch
from
September 3, 2026 18:49
86dbd16 to
e2c98e2
Compare
lneto
force-pushed
the
claude_ebpf_irqonly
branch
2 times, most recently
from
September 3, 2026 22:52
117fe8c to
837de41
Compare
lneto
force-pushed
the
claude_closeprivate
branch
from
September 3, 2026 22:52
e2c98e2 to
067e9ae
Compare
lneto
force-pushed
the
claude_ebpf_irqonly
branch
from
September 3, 2026 23:01
837de41 to
f8089b8
Compare
lneto
force-pushed
the
claude_closeprivate
branch
from
September 3, 2026 23:01
067e9ae to
eb4a49a
Compare
lneto
force-pushed
the
claude_ebpf_irqonly
branch
from
September 3, 2026 23:08
f8089b8 to
0e37660
Compare
The kfunc looked the key up and ran whatever it found, so a process-context runtime registered under an eBPF program's key had its mutex taken from softirq on every packet; contended, by a stop closing the state while traffic flows, that schedules while atomic. Refuse the runtime in the lookup, with a ratelimited log, and leave the verdict to the program. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
lneto
force-pushed
the
claude_ebpf_irqonly
branch
from
September 3, 2026 23:19
ae4c1a3 to
38a25c3
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Split out of #762, on top of #765.
The kfunc looked the key up and ran whatever it found, so a process-context runtime registered under an eBPF program's key had its mutex taken from softirq on every packet; contended, by a stop closing the state while traffic flows, that schedules while atomic. The lookup now refuses the runtime, with a ratelimited log, and leaves the verdict to the program. With the percpu object (#762) the refusal keeps the kfunc off process-context instances; the object's release path, which the refusal's own put can trigger from softirq, drops the instances without taking their locks.
Test: a
tests/xdpcase runs a process-context runtime under the program's key and checks the kfunc refuses it; validated by disabling the check and watching the runtime get dispatched.Tested on 6.8.0-136 (aarch64): xdp 7/7, clean dmesg.
🤖 Generated with Claude Code