From: Greg Kroah-Hartman Date: Tue, 31 Dec 2013 05:20:23 +0000 (-0800) Subject: 3.10-stable patches X-Git-Tag: v3.4.76~76 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=4f66e6d08e278a5ececead9d2972915f5a9b12aa;p=thirdparty%2Fkernel%2Fstable-queue.git 3.10-stable patches added patches: powerpc-kvm-fix-rare-but-potential-deadlock-scene.patch tty-pmac_zilog-check-existence-of-ports-in-pmz_console_init.patch --- diff --git a/queue-3.10/powerpc-kvm-fix-rare-but-potential-deadlock-scene.patch b/queue-3.10/powerpc-kvm-fix-rare-but-potential-deadlock-scene.patch new file mode 100644 index 00000000000..62d9dce93dd --- /dev/null +++ b/queue-3.10/powerpc-kvm-fix-rare-but-potential-deadlock-scene.patch @@ -0,0 +1,77 @@ +From 91648ec09c1ef69c4d840ab6dab391bfb452d554 Mon Sep 17 00:00:00 2001 +From: pingfan liu +Date: Fri, 15 Nov 2013 16:35:00 +0800 +Subject: powerpc: kvm: fix rare but potential deadlock scene + +From: pingfan liu + +commit 91648ec09c1ef69c4d840ab6dab391bfb452d554 upstream. + +Since kvmppc_hv_find_lock_hpte() is called from both virtmode and +realmode, so it can trigger the deadlock. + +Suppose the following scene: + +Two physical cpuM, cpuN, two VM instances A, B, each VM has a group of +vcpus. + +If on cpuM, vcpu_A_1 holds bitlock X (HPTE_V_HVLOCK), then is switched +out, and on cpuN, vcpu_A_2 try to lock X in realmode, then cpuN will be +caught in realmode for a long time. + +What makes things even worse if the following happens, + On cpuM, bitlockX is hold, on cpuN, Y is hold. + vcpu_B_2 try to lock Y on cpuM in realmode + vcpu_A_2 try to lock X on cpuN in realmode + +Oops! deadlock happens + +Signed-off-by: Liu Ping Fan +Reviewed-by: Paul Mackerras +Signed-off-by: Alexander Graf +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/kvm/book3s_64_mmu_hv.c | 6 +++++- + arch/powerpc/kvm/book3s_hv_rm_mmu.c | 4 ++++ + 2 files changed, 9 insertions(+), 1 deletion(-) + +--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c ++++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c +@@ -473,11 +473,14 @@ static int kvmppc_mmu_book3s_64_hv_xlate + slb_v = vcpu->kvm->arch.vrma_slb_v; + } + ++ preempt_disable(); + /* Find the HPTE in the hash table */ + index = kvmppc_hv_find_lock_hpte(kvm, eaddr, slb_v, + HPTE_V_VALID | HPTE_V_ABSENT); +- if (index < 0) ++ if (index < 0) { ++ preempt_enable(); + return -ENOENT; ++ } + hptep = (unsigned long *)(kvm->arch.hpt_virt + (index << 4)); + v = hptep[0] & ~HPTE_V_HVLOCK; + gr = kvm->arch.revmap[index].guest_rpte; +@@ -485,6 +488,7 @@ static int kvmppc_mmu_book3s_64_hv_xlate + /* Unlock the HPTE */ + asm volatile("lwsync" : : : "memory"); + hptep[0] = v; ++ preempt_enable(); + + gpte->eaddr = eaddr; + gpte->vpage = ((v & HPTE_V_AVPN) << 4) | ((eaddr >> 12) & 0xfff); +--- a/arch/powerpc/kvm/book3s_hv_rm_mmu.c ++++ b/arch/powerpc/kvm/book3s_hv_rm_mmu.c +@@ -724,6 +724,10 @@ static int slb_base_page_shift[4] = { + 20, /* 1M, unsupported */ + }; + ++/* When called from virtmode, this func should be protected by ++ * preempt_disable(), otherwise, the holding of HPTE_V_HVLOCK ++ * can trigger deadlock issue. ++ */ + long kvmppc_hv_find_lock_hpte(struct kvm *kvm, gva_t eaddr, unsigned long slb_v, + unsigned long valid) + { diff --git a/queue-3.10/series b/queue-3.10/series index b4f10addfcc..1ef217b5bc2 100644 --- a/queue-3.10/series +++ b/queue-3.10/series @@ -1,3 +1,5 @@ usb-serial-fix-race-in-generic-write.patch ceph-cleanup-aborted-requests-when-re-sending-requests.patch ceph-wake-up-safe-waiters-when-unregistering-request.patch +powerpc-kvm-fix-rare-but-potential-deadlock-scene.patch +tty-pmac_zilog-check-existence-of-ports-in-pmz_console_init.patch diff --git a/queue-3.10/tty-pmac_zilog-check-existence-of-ports-in-pmz_console_init.patch b/queue-3.10/tty-pmac_zilog-check-existence-of-ports-in-pmz_console_init.patch new file mode 100644 index 00000000000..798cfbd9dd1 --- /dev/null +++ b/queue-3.10/tty-pmac_zilog-check-existence-of-ports-in-pmz_console_init.patch @@ -0,0 +1,47 @@ +From dc1dc2f8a5dd863bf2e79f338fc3ae29e99c683a Mon Sep 17 00:00:00 2001 +From: Geert Uytterhoeven +Date: Fri, 22 Nov 2013 16:47:26 +0100 +Subject: TTY: pmac_zilog, check existence of ports in pmz_console_init() + +From: Geert Uytterhoeven + +commit dc1dc2f8a5dd863bf2e79f338fc3ae29e99c683a upstream. + +When booting a multi-platform m68k kernel on a non-Mac with "console=ttyS0" +on the kernel command line, it crashes with: + +Unable to handle kernel NULL pointer dereference at virtual address (null) +Oops: 00000000 +PC: [<0013ad28>] __pmz_startup+0x32/0x2a0 +... +Call Trace: [<002c5d3e>] pmz_console_setup+0x64/0xe4 + +The normal tty driver doesn't crash, because init_pmz() checks +pmz_ports_count again after calling pmz_probe(). + +In the serial console initialization path, pmz_console_init() doesn't do +this, causing the driver to crash later. + +Add a check for pmz_ports_count to fix this. + +Signed-off-by: Geert Uytterhoeven +Cc: Finn Thain +Cc: Benjamin Herrenschmidt +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/tty/serial/pmac_zilog.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/tty/serial/pmac_zilog.c ++++ b/drivers/tty/serial/pmac_zilog.c +@@ -2051,6 +2051,9 @@ static int __init pmz_console_init(void) + /* Probe ports */ + pmz_probe(); + ++ if (pmz_ports_count == 0) ++ return -ENODEV; ++ + /* TODO: Autoprobe console based on OF */ + /* pmz_console.index = i; */ + register_console(&pmz_console);