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:

quoted

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?

quoted

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).