On Sun, May 4, 2025 at 11:40 PM Sergey Senozhatsky <senozhatsky@xxxxxxxxxxxx> wrote: > > bpf_msleep_interruptible() puts a calling context into an > interruptible sleep. This function is expected to be used > for testing only (perhaps in conjunction with fault-injection) > to simulate various execution delays or timeouts. I'm a bit worried that we'll be opening a bit too much of an opportunity to arbitrarily slow down kernel in a way that would be actually pretty hard to detect (CPU profilers won't see this, you'd need to rely on off-CPU profiling, which is not as developed as far as profilers go). I understand the appeal, don't get me wrong, but we have no way to enforce "is expected to be used for testing only". It's also all too easy to sleep for a really long time, and there isn't really any reasonable limit that would mitigate this, IMO. If I had to do this for my own testing/fuzzing needs, I'd probably try to go with a custom kfunc provided by my small and trivial kernel module (modules can extend BPF with custom kfuncs). And see if it's useful. One other alternative to enforce the "for testing only" aspect might be a custom kernel config, that would be expected to not make it into production. Though I'd start with the kernel module approach first, probably. P.S. BPF's "sleepable" is really "faultable", where a BPF program might wait (potentially for a long time) for kernel to fault memory in, but that's a bit more well-defined sleeping behavior. Here it's just a random amount of time to put whatever task the BPF program happened to run in the context of, which seems like a much bigger leap. So while we do have sleepable BPF programs, they can't just arbitrarily and voluntarily sleep (at least today). P.P.S. And when you think about this, we do rely on sleepable/trace RCU grace periods to be not controlled so directly and arbitrarily by any one BPF program, while here with bpf_msleep_interruptible() we'll be giving a lot of control to one BPF program to delay resource freeing of all other BPF programs (and not just sleepable ones, mind you: think sleepable hooks running non-sleepable BPF programs, like with sleepable tracepoints of uprobes). > > Signed-off-by: Sergey Senozhatsky <senozhatsky@xxxxxxxxxxxx> > --- > include/linux/bpf.h | 1 + > include/uapi/linux/bpf.h | 9 +++++++++ > kernel/bpf/helpers.c | 13 +++++++++++++ > kernel/trace/bpf_trace.c | 2 ++ > tools/include/uapi/linux/bpf.h | 9 +++++++++ > 5 files changed, 34 insertions(+) > [...]
