On Wed, May 29, 2024 at 2:20 PM 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/ > ? I applied the similar fixing approach to trie->lock, and then I found the two other locks mentioned earlier. My feeling is that there might not be a use case to justify doing trylocks in memcg and rcu. If you think the approach below is okay. I can send a fixing patch. trie_update_elem() { + if (in_nmi()) + return -EBUSY; } Thanks, Amery
