Re: [PATCH v2 bpf-next 1/3] bpf: Introduce bpf_timer

On Thu, Jun 10, 2021 at 9:27 PM Alexei Starovoitov
[off-list ref] wrote:

From: Alexei Starovoitov <ast@kernel.org>

Introduce 'struct bpf_timer { __u64 :64; __u64 :64; };' that can be embedded
in hash/array/lru maps as regular field and helpers to operate on it:

Can be or has to be? Huge difference here.

In the other thread, you said it is global data, which implies that it does
not have to be in a map.

In your test case or your example, all timers are still in a map. So what has
changed since then? Looks nothing to me.

The bpf_timer_init() helper is receiving hidden 'map' and 'prog' arguments
supplied by the verifier. The prog pointer is needed to do refcnting of bpf
program to make sure that program doesn't get freed while timer is armed.

Nice trick but...

[...]

+BPF_CALL_2(bpf_timer_start, struct bpf_timer_kern *, timer, u64, nsecs)
+{
+       struct bpf_hrtimer *t;
+       int ret = 0;
+
+       ____bpf_spin_lock(&timer->lock);
+       t = timer->timer;
+       if (!t) {
+               ret = -EINVAL;
+               goto out;
+       }
+       if (!hrtimer_active(&t->timer) || hrtimer_callback_running(&t->timer))
+               /* If the timer wasn't active or callback already executing
+                * bump the prog refcnt to keep it alive until
+                * callback is invoked (again).
+                */
+               bpf_prog_inc(t->prog);

Hmm, finally you begin refcounting it, which you were strongly against. ;)

Three questions:

1. Can t->prog be freed between bpf_timer_init() and bpf_timer_start()?
If the timer subprog is always in the same prog which installs it, then
this is fine. But then how do multiple programs share a timer? In the
case of conntrack, either ingress or egress could install the timer,
it only depends which one gets traffic first. Do they have to copy
the same subprog for the same timer?

2. Can t->prog be freed between a timer expiration and bpf_timer_start()
again? It gets a refcnt when starting a timer and puts it when cancelling
or expired, so t->prog can be freed right after cancelling or expired. What
if another program which shares this timer wants to restart this timer?

3. Since you offer no API to read the expiration time, why not just use
BPF_TEST_RUN with a user-space timer? This is preferred by Andrii.

Thanks.