From: Frederic Weisbecker <frederic@kernel.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
"Paul E. McKenney" <paulmck@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Linux 6.3-rc2
Date: Tue, 14 Mar 2023 00:11:49 +0100 [thread overview]
Message-ID: <ZA+ttVOPBvNOYHoC@lothringen> (raw)
In-Reply-To: <CAHk-=wi8xQw6eTRncbJfWWYHHi0UBG2B_AfHrzZbPr=k0V_WYQ@mail.gmail.com>
On Mon, Mar 13, 2023 at 11:21:44AM -0700, Linus Torvalds wrote:
> On Mon, Mar 13, 2023 at 8:53 AM Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > Warning backtraces in calls from ct_nmi_enter(),
> > seen randomly.
>
> Hmm.
>
> I suspect this one is a bug in the warning, not in the kernel,
> although I have no idea why it would have started happening now.
>
> This happens from an irq event, but that check is not *supposed* to
> happen at all from interrupts:
>
> * We dont accurately track softirq state in e.g.
> * hardirq contexts (such as on 4KSTACKS), so only
> * check if not in hardirq contexts:
>
> but I think that the ct_nmi_enter() function was called before the
> hardirq count had even been incremented.
Indeed, ct_nmi_enter() is called very early on irq_enter(), before
HARDIRQ_OFFSET is added and the warning triggers at:
if (!hardirq_count()) {
if (softirq_count()) {
/* like the above, but with softirqs */
DEBUG_LOCKS_WARN_ON(current->softirqs_enabled); <---- HERE
}
So the hardirq interrupted some code that has softirqs disabled (or
servicing) from the preempt mask POV but not from lockdep POV.
It says softirqs were last enabled/disabled at some random point, but the
function looks ok:
[ 28.765386] softirqs last enabled at (6328): [<c0103814>] vfp_sync_hwstate+0x48/0x8c
[ 28.765575] softirqs last disabled at (6326): [<c01037cc>] vfp_sync_hwstate+0x0/0x8c
It would be interesting to see what the IRQ is interrupting. For example does it
happen while softirqs are serviced or just disabled? Or are we even outside any
of that? Any chance we can have a deeper stack trace? If not at least a print of
preempt_count() would be helpful.
Both would be awesome.
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 50d4863974e7..a7d1a65e5425 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -5523,6 +5523,7 @@ static noinstr void check_flags(unsigned long flags)
*/
if (!hardirq_count()) {
if (softirq_count()) {
+ printk("preempt_count(): %x", preempt_count());
/* like the above, but with softirqs */
DEBUG_LOCKS_WARN_ON(current->softirqs_enabled);
} else {
Thanks.
next prev parent reply other threads:[~2023-03-13 23:11 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-12 23:45 Linux 6.3-rc2 Linus Torvalds
2023-03-13 8:11 ` Build regressions/improvements in v6.3-rc2 Geert Uytterhoeven
2023-03-13 8:16 ` Geert Uytterhoeven
2023-03-13 9:08 ` HID: Stable backport request (all viable versions) Lee Jones
2023-03-13 10:51 ` Greg KH
2023-03-13 15:53 ` Linux 6.3-rc2 Guenter Roeck
2023-03-13 18:21 ` Linus Torvalds
2023-03-13 20:30 ` Guenter Roeck
2023-03-13 22:16 ` Linus Torvalds
2023-03-13 22:49 ` Guenter Roeck
2023-03-13 23:11 ` Frederic Weisbecker [this message]
2023-03-13 23:17 ` Linus Torvalds
2023-03-13 23:25 ` Frederic Weisbecker
2023-03-14 0:52 ` Guenter Roeck
2023-03-14 11:18 ` Frederic Weisbecker
2023-03-14 11:40 ` Peter Zijlstra
2023-03-14 12:01 ` Ard Biesheuvel
2023-03-14 12:27 ` Peter Zijlstra
2023-03-14 14:40 ` Guenter Roeck
2023-03-14 16:16 ` Guenter Roeck
2023-03-19 14:06 ` Linux regression tracking #adding (Thorsten Leemhuis)
2023-04-14 14:11 ` Linux regression tracking #update (Thorsten Leemhuis)
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=ZA+ttVOPBvNOYHoC@lothringen \
--to=frederic@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=torvalds@linux-foundation.org \
/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