On Thu, Oct 08, 2026 at 11:54 AM Gabriele Monaco <[email protected]> wrote: > Reactors in this patch use bpf_printk(), which is in fact a trace_printk() > instead of a real printk, is there a technical limitation forbidding us to > create a kfunc using some flavour of printk_deferred()? Or am I missing an > existing one? (this need was brought up by John, Cc'd here)
No technical limitation, and there is no such kfunc today. printk_deferred() is a lockless store into the ring buffer plus irq_work. It's ok in any context where tracing progs run. The closest we have is bpf_stream_vprintk(). That's stdout/stderr of the prog. User space has to read it. rv tool is around for as long as the monitor is loaded, so it can read the stream and log it anywhere like /dev/kmsg. If the message has to reach the console when user space cannot run then the kfunc makes sense, but using bpf_stream is imo much cleaner. > Not needed in this patch but potentially required for more complex monitors. > In > kernel, when timers are required, we allow monitors to use hrtimers (precise > but > heavy), or the timer_wheel (lightweight but less precise). > I'm not aware of any wrapper of the wheel in BPF, but I think a few kfuncs for > these could be useful, in general, also for other programs needing a lot of > timer instances or simply light timeouts. > What do you think? I don't think it's needed. bpf_timer is hrtimer only, but hrtimer vs wheel is not where the cost is. bpf_timer_start() cannot call hrtimer_start() directly. bpf_async_schedule_op() does kmalloc_nolock() and irq_work_queue() instead. I don't think timer wheel will help.
