a4d1d9fe03
bnc#828623 - bnc#839596 - VUL-0: CVE-2013-1442: XSA-62: xen: Information leak on AVX and/or LWP capable CPUs 5242a1b5-x86-xsave-initialize-extended-register-state-when-guests-enable-it.patch - bnc#840592 - VUL-0: CVE-2013-4355: XSA-63: xen: Information leaks through I/O instruction emulation CVE-2013-4355-xsa63.patch - bnc#840593 - VUL-0: CVE-2013-4356: XSA-64: xen: Memory accessible by 64-bit PV guests under live migration CVE-2013-4356-xsa64.patch - bnc#841766 - VUL-1: CVE-2013-4361: XSA-66: xen: Information leak through fbld instruction emulation CVE-2013-4361-xsa66.patch - bnc#833796 - L3: Xen: migration broken from xsave-capable to xsave-incapable host 52205e27-x86-xsave-initialization-improvements.patch 522dc0e6-x86-xsave-fix-migration-from-xsave-capable-to-xsave-incapable-host.patch - bnc#839600 - [HP BCS SLES11 Bug]: In HP’s UEFI x86_64 platform and sles11sp3 with xen environment, xen hypervisor will panic on multiple blades nPar. 523172d5-x86-fix-memory-cut-off-when-using-PFN-compression.patch - bnc#833251 - [HP BCS SLES11 Bug]: In HP’s UEFI x86_64 platform and with xen environment, in booting stage ,xen hypervisor will panic. 522d896b-x86-EFI-properly-handle-run-time-memory-regions-outside-the-1-1-map.patch - bnc#834751 - [HP BCS SLES11 Bug]: In xen, “shutdown –y 0 –h” cannot power off system 522d896b-x86-EFI-properly-handle-run-time-memory-regions-outside-the-1-1-map.patch OBS-URL: https://build.opensuse.org/package/show/Virtualization/xen?expand=0&rev=274
50 lines
1.8 KiB
Diff
50 lines
1.8 KiB
Diff
# Commit 7b9fa702ca323164d6b49e8b639a57f880454a8c
|
|
# Date 2013-08-13 14:31:01 +0200
|
|
# Author Andrew Cooper <andrew.cooper3@citrix.com>
|
|
# Committer Jan Beulich <jbeulich@suse.com>
|
|
watchdog/crash: Always disable watchdog in console_force_unlock()
|
|
|
|
Depending on the state of the conring and serial_tx_buffer,
|
|
console_force_unlock() can be a long running operation, usually because of
|
|
serial_start_sync()
|
|
|
|
XenServer testing has found a reliable case where console_force_unlock() on
|
|
one PCPU takes long enough for another PCPU to timeout due to the watchdog
|
|
(such as waiting for a tlb flush callin).
|
|
|
|
The watchdog timeout causes the second PCPU to repeat the
|
|
console_force_unlock(), at which point the first PCPU typically fails an
|
|
assertion in spin_unlock_irqrestore(&port->tx_lock) (because the tx_lock has
|
|
been unlocked behind itself).
|
|
|
|
console_force_unlock() is only on emergency paths, so one way or another the
|
|
host is going down. Disable the watchdog before forcing the console lock to
|
|
help prevent having pcpus completing with each other to bring the host down.
|
|
|
|
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
|
|
Acked-by: Keir Fraser <keir@xen.org>
|
|
|
|
--- a/xen/arch/x86/x86_64/traps.c
|
|
+++ b/xen/arch/x86/x86_64/traps.c
|
|
@@ -226,8 +226,6 @@ void do_double_fault(struct cpu_user_reg
|
|
unsigned int cpu;
|
|
unsigned long crs[8];
|
|
|
|
- watchdog_disable();
|
|
-
|
|
console_force_unlock();
|
|
|
|
asm ( "lsll %1, %0" : "=r" (cpu) : "rm" (PER_CPU_GDT_ENTRY << 3) );
|
|
--- a/xen/drivers/char/console.c
|
|
+++ b/xen/drivers/char/console.c
|
|
@@ -736,6 +736,9 @@ void console_end_log_everything(void)
|
|
|
|
void console_force_unlock(void)
|
|
{
|
|
+#ifdef CONFIG_X86
|
|
+ watchdog_disable();
|
|
+#endif
|
|
spin_lock_init(&console_lock);
|
|
serial_force_unlock(sercon_handle);
|
|
console_locks_busted = 1;
|