Message ID | 20240424031315.2757363-1-memxor@gmail.com (mailing list archive) |
---|---|
Headers | show |
Series | Introduce bpf_preempt_{disable,enable} | expand |
On Wed, Apr 24, 2024 at 03:13:13AM +0000, Kumar Kartikeya Dwivedi wrote: > This set introduces two kfuncs, bpf_preempt_disable and > bpf_preempt_enable, which are wrappers around preempt_disable and > preempt_enable in the kernel. These functions allow a BPF program to > have code sections where preemption is disabled. There are multiple use > cases that are served by such a feature, a few are listed below: > > 1. Writing safe per-CPU alogrithms/data structures that work correctly > across different contexts. > 2. Writing safe per-CPU allocators similar to bpf_memalloc on top of > array/arena memory blobs. > 3. Writing locking algorithms in BPF programs natively. > > Note that local_irq_disable/enable equivalent is also needed for proper > IRQ context protection, but that is a more involved change and will be > sent later. > > While bpf_preempt_{disable,enable} is not sufficient for all of these > usage scenarios on its own, it is still necessary. > > The same effect as these kfuncs can in some sense be already achieved > using the bpf_spin_lock or rcu_read_lock APIs, therefore from the > standpoint of kernel functionality exposure in the verifier, this is > well understood territory. > > Note that these helpers do allow calling kernel helpers and kfuncs from > within the non-preemptible region (unless sleepable). Otherwise, any > locks built using the preemption helpers will be as limited as > existing bpf_spin_lock. > > Nesting is allowed by keeping a counter for tracking remaining enables > required to be performed. Similar approach can be applied to > rcu_read_locks in a follow up. > > Changelog > ========= > v1: https://lore.kernel.org/bpf/20240423061922.2295517-1-memxor@gmail.com > > * Move kfunc BTF ID declerations above css task kfunc for > !CONFIG_CGROUPS config (Alexei) > * Add test case for global function call in non-preemptible region > (Jiri) Acked-by: Jiri Olsa <jolsa@kernel.org> jirka > > Kumar Kartikeya Dwivedi (2): > bpf: Introduce bpf_preempt_[disable,enable] kfuncs > selftests/bpf: Add tests for preempt kfuncs > > include/linux/bpf_verifier.h | 1 + > kernel/bpf/helpers.c | 12 ++ > kernel/bpf/verifier.c | 71 ++++++++- > .../selftests/bpf/prog_tests/preempt_lock.c | 9 ++ > .../selftests/bpf/progs/preempt_lock.c | 135 ++++++++++++++++++ > 5 files changed, 226 insertions(+), 2 deletions(-) > create mode 100644 tools/testing/selftests/bpf/prog_tests/preempt_lock.c > create mode 100644 tools/testing/selftests/bpf/progs/preempt_lock.c > > > base-commit: 6e10b6350a67d398c795ac0b93a7bb7103633fe4 > -- > 2.43.0 > >
Hello: This series was applied to bpf/bpf-next.git (master) by Alexei Starovoitov <ast@kernel.org>: On Wed, 24 Apr 2024 03:13:13 +0000 you wrote: > This set introduces two kfuncs, bpf_preempt_disable and > bpf_preempt_enable, which are wrappers around preempt_disable and > preempt_enable in the kernel. These functions allow a BPF program to > have code sections where preemption is disabled. There are multiple use > cases that are served by such a feature, a few are listed below: > > 1. Writing safe per-CPU alogrithms/data structures that work correctly > across different contexts. > 2. Writing safe per-CPU allocators similar to bpf_memalloc on top of > array/arena memory blobs. > 3. Writing locking algorithms in BPF programs natively. > > [...] Here is the summary with links: - [bpf-next,v2,1/2] bpf: Introduce bpf_preempt_[disable,enable] kfuncs https://git.kernel.org/bpf/bpf-next/c/fc7566ad0a82 - [bpf-next,v2,2/2] selftests/bpf: Add tests for preempt kfuncs https://git.kernel.org/bpf/bpf-next/c/3134396f1cba You are awesome, thank you!