On Wed, Jan 8, 2025 at 7:46 PM Waiman Long <llong@xxxxxxxxxx> wrote: > > >>>> As for the locking semantics allowed by the BPF verifier, is it possible > >>>> to enforce the strict locking rules for PREEMPT_RT kernel and use the > >>>> relaxed semantics for non-PREEMPT_RT kernel. We don't want the loading > >>>> of an arbitrary BPF program to break the latency guarantee of a > >>>> PREEMPT_RT kernel. > >>> Not really. > >>> root can load silly bpf progs that take significant > >>> amount time without abusing spinlocks. > >>> Like 100k integer divides or a sequence of thousands of calls to map_update. > >>> Long runtime of broken progs is a known issue. > >>> We're working on a runtime termination check/watchdog that > >>> will detect long running progs and will terminate them. > >>> Safe termination is tricky, as you can imagine. > >> Right. > >> > >> In that case, we just have to warn users that they can load BPF prog at > >> their own risk and PREEMPT_RT kernel may break its latency guarantee. > > Let's not open this can of worms. > > There will be a proper watchdog eventually. > > If we start to warn, when do we warn? On any bpf program loaded? > > How about classic BPF ? tcpdump and seccomp ? They are limited > > to 4k instructions, but folks can abuse that too. > > My intention is to document this somewhere, not to print out a warning > in the kernel dmesg log. Document what exactly? "Loading arbitrary BPF program may break the latency guarantee of PREEMPT_RT" ? That's not helpful to anyone. Especially it undermines the giant effort we did together with RT folks to make bpf behave well on RT. For a long time bpf was the only user of migrate_disable(). Some of XDP bits got friendly to RT only in the last release. Etc.
