On Mon, Jan 23, 2023 at 11:21 AM +02, Yaniv Agman wrote: > Hello! > > Several places state that eBPF programs cannot be preempted by the > kernel (e.g. https://docs.cilium.io/en/latest/bpf/toolchain), however, > I did see a strange behavior where an eBPF percpu map gets overridden, > and I'm trying to figure out if it's due to a bug in my program or > some misunderstanding I have about eBPF. What caught my eye was a > sentence in a LWN article (https://lwn.net/Articles/812503/) that > says: "Alexei thankfully enlightened me recently over a beer that the > real intent here is to guarantee that the program runs to completion > on the same CPU where it started". > > So my question is - are BPF programs guaranteed to run from start to > end without being interrupted at all or the only guarantee I get is > that they run on the same CPU but IRQs (NMIs, soft irqs, whatever) can > interrupt their run? > > If the only guarantee is no migration, it means that a percpu map > cannot be safely used by two different BPF programs that can preempt > each other (e.g. some kprobe and a network cgroup program). Since v5.7 BPF program runners use migrate_disable() instead of preempt_disable(). See commit 2a916f2f546c ("bpf: Use migrate_disable/enable in array macros and cgroup/lirc code.") [1]. But at that time migrate_disable() was merely an alias for preempt_disable() on !CONFIG_PREEMPT_RT kernels. Since v5.11 migrate_disable() does no longer disable preemption on !CONFIG_PREEMPT_RT kernels. See commit 74d862b682f5 ("sched: Make migrate_disable/enable() independent of RT") [2]. So, yes, you are right, but it depends on the kernel version. PS. The migrate_disable vs per-CPU data problem is also covered in [3]. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2a916f2f546ca1c1e3323e2a4269307f6d9890eb [2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=74d862b682f51e45d25b95b1ecf212428a4967b0 [3]: https://lwn.net/Articles/836503/
