From: Alexei Starovoitov Date: Fri, 30 Oct 2020 20:03:29 +0000 (-0700) Subject: Merge branch 'bpf: safeguard hashtab locking in NMI context' X-Git-Url: http://git.maquefel.me/?a=commitdiff_plain;h=cb5dc5b062a915bc92def951ea7f33bad6d2ff1f;p=linux.git Merge branch 'bpf: safeguard hashtab locking in NMI context' Song Liu says: ==================== LOCKDEP NMI warning highlighted potential deadlock of hashtab in NMI context: [ 74.828971] ================================ [ 74.828972] WARNING: inconsistent lock state [ 74.828973] 5.9.0-rc8+ #275 Not tainted [ 74.828974] -------------------------------- [ 74.828975] inconsistent {INITIAL USE} -> {IN-NMI} usage. [ 74.828976] taskset/1174 [HC2[2]:SC0[0]:HE0:SE1] takes: [...] [ 74.828999] Possible unsafe locking scenario: [ 74.828999] [ 74.829000] CPU0 [ 74.829001] ---- [ 74.829001] lock(&htab->buckets[i].raw_lock); [ 74.829003] [ 74.829004] lock(&htab->buckets[i].raw_lock); Please refer to patch 1/2 for full trace. This warning is a false alert, as "INITIAL USE" and "IN-NMI" in the tests are from different hashtab. On the other hand, in theory, it is possible to deadlock when a hashtab is access from both non-NMI and NMI context. Patch 1/2 fixes this false alert by assigning separate lockdep class to each hashtab. Patch 2/2 introduces map_locked counters, which is similar to bpf_prog_active counter, to avoid hashtab deadlock in NMI context. ==================== Signed-off-by: Alexei Starovoitov --- cb5dc5b062a915bc92def951ea7f33bad6d2ff1f