From: Peter Zijlstra <peterz@infradead.org>
To: kernel test robot <lkp@intel.com>
Cc: LKP <lkp@lists.01.org>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
philip.li@intel.com
Subject: Re: 4d004099a6 ("lockdep: Fix lockdep recursion"): BUG: using __this_cpu_read() in preemptible [00000000] code: trinity-c6/526
Date: Mon, 19 Oct 2020 20:33:55 +0200 [thread overview]
Message-ID: <20201019183355.GS2611@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <5f8dc512.pzfR1ahTGDOChwCh%lkp@intel.com>
On Tue, Oct 20, 2020 at 12:55:46AM +0800, kernel test robot wrote:
> [ 92.898145] BUG: using __this_cpu_read() in preemptible [00000000] code: trinity-c6/526
> [ 92.903305] Call Trace:
> [ 92.905182] __this_cpu_preempt_check+0xf/0x11
> [ 92.905968] lockdep_hardirqs_on_prepare+0x2c/0x18f
> [ 92.906853] trace_hardirqs_on+0x49/0x53
> [ 92.907578] __bad_area_nosemaphore+0x3a/0x134
Hurph, that's a spurious local_irq_enable(). I suppose this'll fix it.
---
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 3e99dfef8408..9f818145ef7d 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -4057,9 +4057,6 @@ void lockdep_hardirqs_on_prepare(unsigned long ip)
if (unlikely(in_nmi()))
return;
- if (unlikely(__this_cpu_read(lockdep_recursion)))
- return;
-
if (unlikely(lockdep_hardirqs_enabled())) {
/*
* Neither irq nor preemption are disabled here
@@ -4070,6 +4067,9 @@ void lockdep_hardirqs_on_prepare(unsigned long ip)
return;
}
+ if (unlikely(__this_cpu_read(lockdep_recursion)))
+ return;
+
/*
* We're enabling irqs and according to our state above irqs weren't
* already enabled, yet we find the hardware thinks they are in fact
@@ -4126,9 +4126,6 @@ void noinstr lockdep_hardirqs_on(unsigned long ip)
goto skip_checks;
}
- if (unlikely(__this_cpu_read(lockdep_recursion)))
- return;
-
if (lockdep_hardirqs_enabled()) {
/*
* Neither irq nor preemption are disabled here
@@ -4139,6 +4136,9 @@ void noinstr lockdep_hardirqs_on(unsigned long ip)
return;
}
+ if (unlikely(__this_cpu_read(lockdep_recursion)))
+ return;
+
/*
* We're enabling irqs and according to our state above irqs weren't
* already enabled, yet we find the hardware thinks they are in fact
prev parent reply other threads:[~2020-10-19 18:34 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-19 16:55 kernel test robot
2020-10-19 18:33 ` Peter Zijlstra [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20201019183355.GS2611@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@intel.com \
--cc=lkp@lists.01.org \
--cc=mingo@kernel.org \
--cc=philip.li@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome