Re: [PATCH bpf-next v1 12/22] rqspinlock: Add basic support for CONFIG_PARAVIRT
From: Waiman Long
Date: Wed Jan 08 2025 - 22:58:47 EST
On 1/8/25 10:53 PM, Alexei Starovoitov wrote:
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.
OK, it is just a suggestion. If you don't think that is necessary, I am
not going to insist. Anyway, users should thoroughly test their BPF
program before deplolying on production systems.
Cheers,
Longman