On Thu, Jan 24, 2019 at 03:58:59PM -0800, Alexei Starovoitov wrote: > On Thu, Jan 24, 2019 at 07:01:09PM +0100, Peter Zijlstra wrote:
> > So clearly this map stuff is shared between bpf proglets, otherwise > > there would not be a need for locking. But what happens if one is from > > task context and another from IRQ context? > > > > I don't see a local_irq_save()/restore() anywhere. What avoids the > > trivial lock inversion? > > > and from NMI ... > > progs are not preemptable and map syscall accessors have bpf_prog_active > counters. > So nmi/kprobe progs will not be running when syscall is running. > Hence dead lock is not possible and irq_save is not needed. What about the progs that run from SoftIRQ ? Since that bpf_prog_active thing isn't inside BPF_PROG_RUN() what is to stop say: reuseport_select_sock() ... BPF_PROG_RUN() bpf_spin_lock() <IRQ> ... BPF_PROG_RUN() bpf_spin_lock() // forever more </IRQ> Unless you stick that bpf_prog_active stuff inside BPF_PROG_RUN itself, I don't see how you can fundamentally avoid this happening (now or in the future).