BPF: what's good, what's coming, and what's needed [LWN.net]

BPF: what's good, what's coming, and what's needed

Posted May 10, 2019 14:29 UTC (Fri) by Paf (subscriber, #91811)
In reply to: BPF: what's good, what's coming, and what's needed by roc
Parent article: BPF: what's good, what's coming, and what's needed

“The inputs” Hmm, BPF programs measure in kernel state, that’s one of their main purposes. That state changes, obviously.

So this seems impossible? Recording the full execution might work, but I think nothing short of that would be sufficient, because “the inputs” are more than what the user provides.

to post comments

BPF: what's good, what's coming, and what's needed

Posted May 10, 2019 16:04 UTC (Fri) by excors (subscriber, #95769) [Link]

I assume roc is thinking of https://rr-project.org/ , so "the inputs" means all data the program receives from its environment through any channel. For BPF I guess that means the initial context structure, plus the return values and BPF-memory side-effects of functions like bpf_probe_read (which copies kernel memory into BPF memory), but nothing more than that. Once you record those inputs, you should be able to deterministically replay the BPF program in a debug environment with identical behaviour.

For any code that's even vaguely timing-sensitive (which I assume includes nearly everything running in a kernel that's full of timers and timeouts and hardware interfaces), that's much more useful than a debugger that pauses the program while it's running.

BPF: what's good, what's coming, and what's needed

Posted May 10, 2019 22:04 UTC (Fri) by roc (subscriber, #30627) [Link]

For BPF "inputs" includes loads from memory outside the BPF program.