On Wed, May 29, 2024 at 2:46 PM Siddharth Chintamaneni <sidchintamaneni@xxxxxxxxx> wrote: > > On Wed, 29 May 2024 at 16:20, Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > On Wed, May 29, 2024 at 8:53 AM Amery Hung <ameryhung@xxxxxxxxx> wrote: > > > > > > Hello, > > > > > > We are developing a tool to perform static analysis on the bpf > > > subsystem to detect locking violations. Our tool reported the > > > spin_lock_irqsave() in trie_delete_elem() and trie_update_elem() that > > > could be called from an NMI. If a bpf program holding the lock is > > > interrupted by the same program in NMI, a deadlock can happen. The > > > report was generated for kernel version 6.6-rc4, however, we believe > > > this should still exist in the latest kernel. > > > > Fix it similar to > > https://lore.kernel.org/all/20230911132815.717240-1-toke@xxxxxxxxxx/ > > ? > > > > Hi, > > This will still not resolve the deadlock caused due to nested bpf > programs, wouldn't it be nice to resolve using per_cpu variable like > in hashmap. Yes. That's orthogonal and still necessary.
