From: Igor Mammedov <imammedo@redhat.com>
To: linux-kernel@vger.kernel.org
Cc: tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com,
x86@kernel.org, imammedo@redhat.com, bp@suse.de,
paul.gortmaker@windriver.com, JBeulich@suse.com,
prarit@redhat.com, drjones@redhat.com, toshi.kani@hp.com,
riel@redhat.com, gong.chen@linux.intel.com, andi@firstfloor.org,
lenb@kernel.org, rjw@rjwysocki.net, linux-acpi@vger.kernel.org
Subject: [PATCH v3 0/5] x86: fix hang when AP bringup is too slow
Date: Thu, 10 Apr 2014 19:14:16 +0200 [thread overview]
Message-ID: <1397150061-29735-1-git-send-email-imammedo@redhat.com> (raw)
Hang is observed on virtual machines during CPU hotplug,
especially in big guests with many CPUs. (It happens more
often if host is over-committed).
Hang happens because master CPU timeouts on waiting till
AP boots and 'cancels' CPU online operation assuming AP
is not functional but AP may continue run wild later
causing various hangs or panics in running kernel that
is assuming that AP was offline.
This is an alternative approach, that instead of canceling
in-progress AP bringup (https://lkml.org/lkml/2014/3/6/257),
removes timeouts so that AP bringup won't be affected by
poor timing and syncs AP with master CPU at early startup
making sure that AP won't run wild if master CPU doesn't
expect AP to come online.
Series also fixes 3 bugs found during testing CPU bringup
failure case.
--
Below is the detailed description of a more often happening hang:
---
Master CPU may timeout before cpu_callin_mask is set and cancel
booting CPU, but being onlined CPU still continues to boot, sets
cpu_active_mask (CPU_STARTING notifiers) and spins in
check_tsc_sync_target() for master cpu to arrive. Following attempt
to online another cpu hangs in stop_machine, initiated from here:
smp_callin ->
smp_store_cpu_info ->
identify_secondary_cpu ->
mtrr_ap_init -> set_mtrr_from_inactive_cpu
stop_machine waits on completion of stop_work on all CPUs from
cpu_active_mask including a failed CPU that spins in check_tsc_sync_target().
Igor Mammedov (5):
x86: initialize secondary CPU only if master CPU will wait for it
x86: log error on secondary CPU wakeup failure at ERR level
x86: fix list corruption on CPU hotplug
x86: fix memory corruption in acpi_unmap_lsapic()
acpi_processor: do not mark present at boot but not onlined CPU as
onlined
arch/x86/kernel/cpu/common.c | 28 +++++++----
arch/x86/kernel/smpboot.c | 103 ++++++++++++----------------------------
drivers/acpi/acpi_processor.c | 3 -
3 files changed, 48 insertions(+), 86 deletions(-)
next reply other threads:[~2014-04-10 17:14 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-10 17:14 Igor Mammedov [this message]
2014-04-10 17:14 ` [PATCH v3 1/5] x86: initialize secondary CPU only if master CPU will wait for it Igor Mammedov
2014-04-14 9:16 ` Ingo Molnar
2014-04-14 9:52 ` Igor Mammedov
2014-04-14 10:03 ` Ingo Molnar
2014-04-14 10:21 ` Igor Mammedov
2014-04-14 12:50 ` Igor Mammedov
2014-04-14 14:51 ` Ingo Molnar
2014-04-14 15:03 ` Igor Mammedov
2014-04-10 17:14 ` [PATCH v3 2/5] x86: log error on secondary CPU wakeup failure at ERR level Igor Mammedov
2014-04-10 17:14 ` [PATCH v3 3/5] x86: fix list corruption on CPU hotplug Igor Mammedov
2014-04-14 9:19 ` Ingo Molnar
2014-04-14 9:56 ` Igor Mammedov
2014-04-14 10:04 ` Ingo Molnar
2014-04-14 10:23 ` Igor Mammedov
2014-04-14 10:34 ` Ingo Molnar
2014-04-14 10:48 ` Igor Mammedov
2014-04-14 10:56 ` Ingo Molnar
2014-04-10 17:14 ` [PATCH v3 4/5] x86: fix memory corruption in acpi_unmap_lsapic() Igor Mammedov
2014-04-14 9:20 ` Ingo Molnar
2014-04-10 17:14 ` [PATCH v3 5/5] acpi_processor: do not mark present at boot but not onlined CPU as onlined Igor Mammedov
2014-04-14 9:21 ` Ingo Molnar
2014-04-15 5:36 ` Rafael J. Wysocki
2014-04-15 5:43 ` Rafael J. Wysocki
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=1397150061-29735-1-git-send-email-imammedo@redhat.com \
--to=imammedo@redhat.com \
--cc=JBeulich@suse.com \
--cc=andi@firstfloor.org \
--cc=bp@suse.de \
--cc=drjones@redhat.com \
--cc=gong.chen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paul.gortmaker@windriver.com \
--cc=prarit@redhat.com \
--cc=riel@redhat.com \
--cc=rjw@rjwysocki.net \
--cc=tglx@linutronix.de \
--cc=toshi.kani@hp.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).