AZL-69716

In the Linux kernel, the following vulnerability has been resolved:

bpf: Prevent bpf program recursion for raw tracepoint probes

We got report from sysbot [1] about warnings that were caused by bpf program attached to contentionbegin raw tracepoint triggering the same tracepoint by using bpftraceprintk helper that takes traceprintk_lock lock.

Call Trace: <TASK> ? traceeventraweventbpftraceprintk+0x5f/0x90 bpftraceprintk+0x2b/0xe0 bpfproga9aec6167c091eefprog+0x1f/0x24 bpftracerun2+0x26/0x90 nativequeuedspinlockslowpath+0x1c6/0x2b0 rawspinlockirqsave+0x44/0x50 bpftraceprintk+0x3f/0xe0 bpfproga9aec6167c091eefprog+0x1f/0x24 bpftracerun2+0x26/0x90 nativequeuedspinlockslowpath+0x1c6/0x2b0 rawspinlockirqsave+0x44/0x50 bpftraceprintk+0x3f/0xe0 bpfproga9aec6167c091eefprog+0x1f/0x24 bpftracerun2+0x26/0x90 nativequeuedspinlockslowpath+0x1c6/0x2b0 rawspinlockirqsave+0x44/0x50 bpftraceprintk+0x3f/0xe0 bpfproga9aec6167c091eefprog+0x1f/0x24 bpftracerun2+0x26/0x90 nativequeuedspinlockslowpath+0x1c6/0x2b0 rawspinlockirqsave+0x44/0x50 _unfreezepartials+0x5b/0x160 ...

The can be reproduced by attaching bpf program as raw tracepoint on contentionbegin tracepoint. The bpf prog calls bpftraceprintk helper. Then by running perf bench the spin lock code is forced to take slow path and call contentionbegin tracepoint.

Fixing this by skipping execution of the bpf program if it's already running, Using bpf prog 'active' field, which is being currently used by trampoline programs for the same reason.

Moving bpfprogincmissescounter to syscall.c because trampoline.c is compiled in just for CONFIGBPFJIT option.

[1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t