diff options
| author | Emil Tsalapatis <emil@etsalapatis.com> | 2026-08-17 15:16:13 -0400 |
|---|---|---|
| committer | Kumar Kartikeya Dwivedi <memxor@gmail.com> | 2026-08-20 21:01:42 +0200 |
| commit | 620e1e2b4377f03834894f86ac85ec865983ad0a (patch) | |
| tree | 74cbc93363e75e4d16f092accd667c39459ec160 /scripts/Makefile.thinlto | |
| parent | db00d61fa433d40fe444d8887d143b895372b274 (diff) | |
| download | linux-next-620e1e2b4377f03834894f86ac85ec865983ad0a.tar.gz linux-next-620e1e2b4377f03834894f86ac85ec865983ad0a.zip | |
selftests/bpf: libarena: Disable IRQs during allocation
The libarena buddy allocator currently uses arena_spin_lock/unlock
to protect its internal data structures in its critical section.
These locks disable preemption, but not IRQs. This in turns can cause
ABBA deadlocks when an allocation/free operation gets an IRQ while
in the critical section, and can only resume after another operation
that in turn blocks on the buddy lock. We have concretely seen this
with sched_ext schedulers:
a) Task 1 on CPU A attempts an allocation during initialization,
which is done without holding an rq lock. The task takes an IRQ
in the middle of the allocation.
b) Task 2 on CPU B exits. It attempts to take the buddy allocator
lock during its sched-ext state teardown, and blocks on the spinlock.
It does so while holding CPU B's rq lock.
c) The scheduler run on CPU A and attempts to move tasks from CPU
B's rq to CPU A's rq before resuming running Task 1. This requires
B's rq lock, which requires Task 2 to take the buddy allocator lock
first.
Fix this by disabling IRQs when taking the buddy lock. We use the
already existing arena_spin_[lock_irqsave, unlock_irqrestore] calls
for this.
Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
Link: https://lore.kernel.org/bpf/20260817191616.11071-4-emil@etsalapatis.com
Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
Diffstat (limited to 'scripts/Makefile.thinlto')
0 files changed, 0 insertions, 0 deletions
