Re: [PATCH bpf-next v1 12/22] rqspinlock: Add basic support for CONFIG_PARAVIRT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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





[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux