Dmitrii.
On Sat, Nov 13 2021 at 18:22, Dmitrii Banshchikov wrote:
> Use of bpf_ktime_get_coarse_ns() and bpf_timer_* helpers in tracing
> progs may result in locking issues.
"may result in locking issues"? There is no 'may'. This is simply a matter
of fact that this can and will result in deadlocks. Please spell it out.
It's a bug, so what. Why do you need to whitewash it?
.
> @@ -4632,6 +4632,9 @@ union bpf_attr {
> * system boot, in nanoseconds. Does not include time the system
> * was suspended.
> *
> + * Tracing programs cannot use **bpf_ktime_get_coarse_ns**\() (but
> + * this may change in the future).
Sorry no. This is a bug fix and there is no place for 'may change in the
future' nonsense. It's simply not possible right now and unless you have
a plan to make this work backed up by actual patches this comment is
worse than wishful thinking.
> + *
> * See: **clock_gettime**\ (**CLOCK_MONOTONIC_COARSE**)
> * Return
> * Current *ktime*.
> @@ -4804,6 +4807,9 @@ union bpf_attr {
> * All other bits of *flags* are reserved.
> * The verifier will reject the program if *timer* is not from
> * the same *map*.
> + *
> + * Tracing programs cannot use **bpf_timer_init**\() (but this may
> + * change in the future).
This is even worse than the above because it cannot happen ever. Please
stop this nonsensical wishful thinking crap. It does not add any value,
it just adds confusion.
Timers will have to take spinlocks no matter what even if the kernel has
been reimplemented in BPF someday. Tracing happens at any arbitrary
place which includes places inisde locked sections. So what are you
hallucinating about?
I completely understand that you are all enthused about the "unlimited"
power of BPF, but please take a step back and understand that BPF has
very well defined limitations as any other instrumentation facility has.
That said, I agree with the code changes but I vehemently NAK comments
which are built on wishful thinking or worse.
Thanks,
tglx
