Conversation
Toke Høiland-Jørgensen
toke
New blog post: "Using eBPF to add arbitrary delay to kernel functions"
Decided to try out writing a utility to add arbitrary delay to kernel functions, as a debugging aid.
And yes, I did manage to stall my laptop while implementing this; thank you for asking! :)
https://blog.tohojo.dk/2025/09/using-ebpf-to-add-arbitrary-delay-to-kernel-functions.html
Decided to try out writing a utility to add arbitrary delay to kernel functions, as a debugging aid.
And yes, I did manage to stall my laptop while implementing this; thank you for asking! :)
https://blog.tohojo.dk/2025/09/using-ebpf-to-add-arbitrary-delay-to-kernel-functions.html
2
6
11
Joe Lawrence
joe-lawrence
@toke perfectly cromulent use case! One of my favorite bugs at Red Hat was a race condition in livepatching that I could reproduce with a livepatch that introduced just the right amount of mdelay in the module loader.
1
0
2
Toke Høiland-Jørgensen
toke
@joe-lawrence ugh, yeah, sounds like something that involved a lot of hair tearing 😅
0
0
0
erthalion
erthalion@fosstodon.org
@toke Yeah, spinning in a tight loop is very unfortunate for any practical application. There was a suggestion some time ago about adding bpf_msleep_interruptible helper [1] for testing purposes, but the excitement about the proposal is low.
[1]: https://lore.kernel.org/bpf/20250515064800.2201498-1-senozhatsky@chromium.org/
1
0
0
Toke Høiland-Jørgensen
toke
@erthalion hmm, interesting. Given the RCU issues mentioned in that thread, though, I'm not sure how big of a difference the msleep variant would make in practice compared to the spinning version (other than lowering the CPU usage, of course)?
1
0
0
erthalion
erthalion@fosstodon.org@toke Right, probably not much difference aside the CPU usage, but it's already something.
0
0
0