On Thu, Jan 24, 2019 at 06:57:00PM -0800, Alexei Starovoitov wrote: > On Thu, Jan 24, 2019 at 06:44:20PM -0800, Eric Dumazet wrote: > > Let see if we understood this well. > > > > 1. create perf event PERF_TYPE_HARDWARE:PERF_COUNT_HW_CPU_CYCLES > > 2. attach bpf probram to this event > > 3. since that's a hw event, the bpf program is executed in NMI context > > 4. the bpf program calls bpf_get_stackid to record the trace in a bpf map > > 5. bpf_get_stackid calls pcpu_freelist_pop and pcpu_freelist_push from NMI
How is this not a straight up bug? NMI code should not ever call code that uses spinlocks. > > 6. userspace calls sys_bpf(bpf_map_lookup_elem) which calls > > bpf_stackmap_copy which can call pcpu_freelist_push > > argh. lookup cmd is missing __this_cpu_inc(bpf_prog_active); like > update/delete do. > Will fix. > > > It seems pcpu_freelist_pop and pcpu_freelist_push are not NMI safe, > > so what prevents bad things to happen ? > > nmi checks for bpf_prog_active==0. See bpf_overflow_handler. yuck yuck yuck.. That's horrific :-( That means the whole BPF crud is unreliable and events can go randomly missing.
