Thread (7 messages) 7 messages, 3 authors, 2021-02-01

Re: corrupted pvqspinlock in htab_map_update_elem

From: Waiman Long <longman@redhat.com>
Date: 2021-02-01 18:22:26
Also in: lkml, netdev

On 2/1/21 1:09 PM, Dmitry Vyukov wrote:
On Mon, Feb 1, 2021 at 6:54 PM Waiman Long [off-list ref] wrote:
quoted
On 2/1/21 6:23 AM, Peter Zijlstra wrote:
quoted
On Mon, Feb 01, 2021 at 10:50:58AM +0100, Peter Zijlstra wrote:
quoted
quoted
   queued_spin_unlock arch/x86/include/asm/qspinlock.h:56 [inline]
   lockdep_unlock+0x10e/0x290 kernel/locking/lockdep.c:124
   debug_locks_off_graph_unlock kernel/locking/lockdep.c:165 [inline]
   print_usage_bug kernel/locking/lockdep.c:3710 [inline]
Ha, I think you hit a bug in lockdep.
Something like so I suppose.

---
Subject: locking/lockdep: Avoid unmatched unlock
From: Peter Zijlstra <peterz@infradead.org>
Date: Mon Feb 1 11:55:38 CET 2021

Commit f6f48e180404 ("lockdep: Teach lockdep about "USED" <- "IN-NMI"
inversions") overlooked that print_usage_bug() releases the graph_lock
and called it without the graph lock held.

Fixes: f6f48e180404 ("lockdep: Teach lockdep about "USED" <- "IN-NMI" inversions")
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
   kernel/locking/lockdep.c |    3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -3773,7 +3773,7 @@ static void
   print_usage_bug(struct task_struct *curr, struct held_lock *this,
               enum lock_usage_bit prev_bit, enum lock_usage_bit new_bit)
   {
-     if (!debug_locks_off_graph_unlock() || debug_locks_silent)
+     if (!debug_locks_off() || debug_locks_silent)
               return;

       pr_warn("\n");
@@ -3814,6 +3814,7 @@ valid_state(struct task_struct *curr, st
           enum lock_usage_bit new_bit, enum lock_usage_bit bad_bit)
   {
       if (unlikely(hlock_class(this)->usage_mask & (1 << bad_bit))) {
+             graph_unlock()
               print_usage_bug(curr, this, bad_bit, new_bit);
               return 0;
       }
I have also suspected doing unlock without a corresponding lock. This
patch looks good to me.

Acked-by: Waiman Long <longman@redhat.com>
Just so that it's not lost: there is still a bug related to bpf map lock, right?
That is right. This patch just fixes the bug in lockdep.

Cheers,
Longman
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help