From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Borislav Petkov <bp@alien8.de>
Cc: linux-kernel@vger.kernel.org, x86@kernel.org, hpa@zytor.com,
mingo@redhat.com, fenghua.yu@intel.com, tglx@linutronix.de,
xen-devel@lists.xensource.com, stable@vger.kernel.org
Subject: Re: [PATCH] x86, microcode: Add local mutex to not hit a deadlock.
Date: Wed, 8 May 2013 14:41:17 -0400 [thread overview]
Message-ID: <20130508184117.GC11906@phenom.dumpdata.com> (raw)
In-Reply-To: <20130508182235.GE30955@pd.tnic>
On Wed, May 08, 2013 at 08:22:35PM +0200, Borislav Petkov wrote:
> On Wed, May 08, 2013 at 12:13:03PM -0400, Konrad Rzeszutek Wilk wrote:
> > This can easily be triggered if a new CPU is added (via
> > ACPI hotplug mechanism) and from user-space do:
> >
> > echo 1 > /sys/devices/system/cpu/cpu3/online
> >
> > (or wait for UDEV to do it) on a newly appeared CPU.
> >
> > The deadlock is that the "store_online" in drivers/base/cpu.c
> > takes the cpu_hotplug_driver_lock() lock, then calls "cpu_up".
> > "cpu_up" eventually ends up calling "save_mc_for_early"
> > which also takes the cpu_hotplug_driver_lock() lock.
> >
> > And here is that kernel thinks of it:
> >
> > smpboot: Stack at about ffff880075c39f44
> > smpboot: CPU3: has booted.
> > microcode: CPU3 sig=0x206a7, pf=0x2, revision=0x25
> >
> > =============================================
> > [ INFO: possible recursive locking detected ]
> > 3.9.0upstream-10129-g167af0e #1 Not tainted
> > ---------------------------------------------
> > sh/2487 is trying to acquire lock:
> > (x86_cpu_hotplug_driver_mutex){+.+.+.}, at: [<ffffffff81075512>] cpu_hotplug_driver_lock+0x12/0x20
> >
> > but task is already holding lock:
> > (x86_cpu_hotplug_driver_mutex){+.+.+.}, at: [<ffffffff81075512>] cpu_hotplug_driver_lock+0x12/0x20
> >
> > other info that might help us debug this:
> > Possible unsafe locking scenario:
> >
> > CPU0
> > ----
> > lock(x86_cpu_hotplug_driver_mutex);
> > lock(x86_cpu_hotplug_driver_mutex);
> >
> > *** DEADLOCK ***
>
> Ok, just for my own understanding: is this something which can actually
> happen now?
Yes. Since v3.9 I've been getting this.
>
> Judging by the presence of traces, it can be triggered in a guest,
> correct?
Correct. I don't have the hardware to test this on baremetal but looking
at how processor-driver.c works I would think this would be hit there as well.
>
> Thanks.
>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
next prev parent reply other threads:[~2013-05-08 18:41 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-08 16:13 [PATCH] x86, microcode: Add local mutex to not hit a deadlock Konrad Rzeszutek Wilk
2013-05-08 18:22 ` Borislav Petkov
2013-05-08 18:41 ` Konrad Rzeszutek Wilk [this message]
2013-05-15 18:25 ` Yu, Fenghua
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=20130508184117.GC11906@phenom.dumpdata.com \
--to=konrad.wilk@oracle.com \
--cc=bp@alien8.de \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=xen-devel@lists.xensource.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