Re: [PATCH v2 10/15] tools/rv: Add BPF monitors

[Gabriele Monaco]

> Since commit ac5a72ea5c89 ("bpf: Use dedicated bpf_trace_printk event
> instead of trace_printk()"), bpf_trace_printk() does not use
> trace_printk(). Rather, it is recorded as a separate ftrace event that
> has to be enabled, in
> /sys/kernel/tracing/events/bpf_trace/bpf_trace_printk, for each
> instance that wants to trace it, and using it does not print any
> warnings into dmesg.
> 
> The BPF documentation says otherwise [1]:

Thanks Tomas! I noticed the banner was not displayed and I was puzzled. You
saved me an LLM iteration that would have probably be puzzled by the comment
too..

> One disadvantage of using bpf_trace_printk() for RV violation
> reporting is that the event will be caught by every instance that
> enables bpf_trace_printk() and does not explicitly filter rv out.

Yes, that should somewhat be mitigated by the glob filter, though events are
still generated.

> I can imagine an RV-specific trace event for that, however, it would
> require a separate kfunc to generate it, and ideally also distinct
> labeling of a BPF program eligible to call that kfunc. The "rv"
> userspace tool could then iterate over these labels so the user knows
> which violation events can be expected to occur on the system.

That'd work too. It's what I initially envisioned but I'm not sure a kfunc
producing a tracepoint is something BPF folks would really like (and technically
any other unrelated BPF program could call that, unless there's some access
control mechanism I'm not aware of).

Not sure how much it matters in practice against the glob filter, it probably
really depends on the other bpf_printk users (and a mildly better usability).

Gabriele