From: Ingo Molnar <mingo@kernel.org>
To: Leon Romanovsky <leon@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H. Peter Anvin" <hpa@zytor.com>, x86 <x86@kernel.org>,
Suresh Siddha <suresh.b.siddha@intel.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] x86/apic: Fix circular locking dependency between console and hrtimer locks
Date: Tue, 14 Apr 2020 08:24:54 +0200 [thread overview]
Message-ID: <20200414062454.GA84326@gmail.com> (raw)
In-Reply-To: <20200414054836.GA956407@unreal>
* Leon Romanovsky <leon@kernel.org> wrote:
> Hi,
>
> Any feedback?
> https://lore.kernel.org/lkml/20200407170925.1775019-1-leon@kernel.org/
The fix definitely looks legit, lockdep is right that we shouldn't take
the console_sem.lock even under trylock.
It's only a printk_once(), yet I'm wondering why in the last ~8 years
this never triggered. Nobody ever ran lockdep and debug console level
enabled on such hardware, or did something else change?
One possibility would be that apic_check_deadline_errata() marked almost
all Intel systems as broken and the TSC-deadline hardware never actually
got activated. In that case you have triggered rarely tested code and
might see other weirdnesses. Just saying. :-)
Or a bootup with "debug" specified is much more rare in production
systems, hence the 8 years old bug.
> > It is far away from my main expertise and I'm not sure that the solution
> > is correct, but it definitely fixed our regression.
> > ---
> > arch/x86/kernel/apic/apic.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
> > index d254cebdd3c3..6706b2cd9aec 100644
> > --- a/arch/x86/kernel/apic/apic.c
> > +++ b/arch/x86/kernel/apic/apic.c
> > @@ -353,7 +353,7 @@ static void __setup_APIC_LVTT(unsigned int clocks, int oneshot, int irqen)
> > */
> > asm volatile("mfence" : : : "memory");
> >
> > - printk_once(KERN_DEBUG "TSC deadline timer enabled\n");
> > + printk_deferred_once(KERN_DEBUG "TSC deadline timer enabled\n");
I think we should move this essentially initialization-time message much
earlier during bootup, when we are not holding any hrtimer locks.
One good place would be apic_check_deadline_errata(). This place:
if (boot_cpu_data.microcode >= rev)
return;
setup_clear_cpu_cap(X86_FEATURE_TSC_DEADLINE_TIMER);
pr_err(FW_BUG "TSC_DEADLINE disabled due to Errata; "
"please update microcode to version: 0x%x (or later)\n", rev);
Could be something like:
if (boot_cpu_data.microcode >= rev) {
pr_debug("x86/apic: TSC deadline timer enabled.\n");
return;
}
setup_clear_cpu_cap(X86_FEATURE_TSC_DEADLINE_TIMER);
pr_err(FW_BUG "TSC_DEADLINE disabled due to CPU errata, please update microcode to version: 0x%x (or later)\n", rev);
(Note the small fixes I did to the errata message - we should do that and
also move all user-facing messages into a single line while at it.)
Thanks,
Ingo
next prev parent reply other threads:[~2020-04-14 6:25 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-07 17:09 [PATCH] x86/apic: Fix circular locking dependency between console and hrtimer locks Leon Romanovsky
2020-04-14 5:48 ` Leon Romanovsky
2020-04-14 6:24 ` Ingo Molnar [this message]
2020-04-14 7:05 ` Leon Romanovsky
2020-04-23 7:13 ` Leon Romanovsky
2020-04-27 15:35 ` Thomas Gleixner
2020-04-27 15:49 ` Leon Romanovsky
2020-04-27 11:09 ` Thomas Gleixner
2020-04-27 11:32 ` Leon Romanovsky
2020-04-27 12:59 ` Thomas Gleixner
2020-04-27 13:41 ` Leon Romanovsky
2020-04-27 15:31 ` Thomas Gleixner
2020-04-27 15:54 ` Leon Romanovsky
2020-05-01 18:22 ` [tip: x86/urgent] x86/apic: Move TSC deadline timer debug printk tip-bot2 for Thomas Gleixner
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=20200414062454.GA84326@gmail.com \
--to=mingo@kernel.org \
--cc=bp@alien8.de \
--cc=hpa@zytor.com \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=suresh.b.siddha@intel.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.