--- /dev/null
+From 85e84ba31039595995dae80b277378213602891b Mon Sep 17 00:00:00 2001
+From: Marc Zyngier <marc.zyngier@arm.com>
+Date: Mon, 16 Mar 2015 10:59:43 +0000
+Subject: arm: KVM: force execution of HCPTR access on VM exit
+
+From: Marc Zyngier <marc.zyngier@arm.com>
+
+commit 85e84ba31039595995dae80b277378213602891b upstream.
+
+On VM entry, we disable access to the VFP registers in order to
+perform a lazy save/restore of these registers.
+
+On VM exit, we restore access, test if we did enable them before,
+and save/restore the guest/host registers if necessary. In this
+sequence, the FPEXC register is always accessed, irrespective
+of the trapping configuration.
+
+If the guest didn't touch the VFP registers, then the HCPTR access
+has now enabled such access, but we're missing a barrier to ensure
+architectural execution of the new HCPTR configuration. If the HCPTR
+access has been delayed/reordered, the subsequent access to FPEXC
+will cause a trap, which we aren't prepared to handle at all.
+
+The same condition exists when trapping to enable VFP for the guest.
+
+The fix is to introduce a barrier after enabling VFP access. In the
+vmexit case, it can be relaxed to only takes place if the guest hasn't
+accessed its view of the VFP registers, making the access to FPEXC safe.
+
+The set_hcptr macro is modified to deal with both vmenter/vmexit and
+vmtrap operations, and now takes an optional label that is branched to
+when the guest hasn't touched the VFP registers.
+
+Reported-by: Vikram Sethi <vikrams@codeaurora.org>
+Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm/kvm/interrupts.S | 10 ++++------
+ arch/arm/kvm/interrupts_head.S | 20 ++++++++++++++++++--
+ 2 files changed, 22 insertions(+), 8 deletions(-)
+
+--- a/arch/arm/kvm/interrupts.S
++++ b/arch/arm/kvm/interrupts.S
+@@ -159,13 +159,9 @@ __kvm_vcpu_return:
+ @ Don't trap coprocessor accesses for host kernel
+ set_hstr vmexit
+ set_hdcr vmexit
+- set_hcptr vmexit, (HCPTR_TTA | HCPTR_TCP(10) | HCPTR_TCP(11))
++ set_hcptr vmexit, (HCPTR_TTA | HCPTR_TCP(10) | HCPTR_TCP(11)), after_vfp_restore
+
+ #ifdef CONFIG_VFPv3
+- @ Save floating point registers we if let guest use them.
+- tst r2, #(HCPTR_TCP(10) | HCPTR_TCP(11))
+- bne after_vfp_restore
+-
+ @ Switch VFP/NEON hardware state to the host's
+ add r7, vcpu, #VCPU_VFP_GUEST
+ store_vfp_state r7
+@@ -177,6 +173,8 @@ after_vfp_restore:
+ @ Restore FPEXC_EN which we clobbered on entry
+ pop {r2}
+ VFPFMXR FPEXC, r2
++#else
++after_vfp_restore:
+ #endif
+
+ @ Reset Hyp-role
+@@ -458,7 +456,7 @@ switch_to_guest_vfp:
+ push {r3-r7}
+
+ @ NEON/VFP used. Turn on VFP access.
+- set_hcptr vmexit, (HCPTR_TCP(10) | HCPTR_TCP(11))
++ set_hcptr vmtrap, (HCPTR_TCP(10) | HCPTR_TCP(11))
+
+ @ Switch VFP/NEON hardware state to the guest's
+ add r7, r0, #VCPU_VFP_HOST
+--- a/arch/arm/kvm/interrupts_head.S
++++ b/arch/arm/kvm/interrupts_head.S
+@@ -570,8 +570,13 @@ vcpu .req r0 @ vcpu pointer always in r
+ .endm
+
+ /* Configures the HCPTR (Hyp Coprocessor Trap Register) on entry/return
+- * (hardware reset value is 0). Keep previous value in r2. */
+-.macro set_hcptr operation, mask
++ * (hardware reset value is 0). Keep previous value in r2.
++ * An ISB is emited on vmexit/vmtrap, but executed on vmexit only if
++ * VFP wasn't already enabled (always executed on vmtrap).
++ * If a label is specified with vmexit, it is branched to if VFP wasn't
++ * enabled.
++ */
++.macro set_hcptr operation, mask, label = none
+ mrc p15, 4, r2, c1, c1, 2
+ ldr r3, =\mask
+ .if \operation == vmentry
+@@ -580,6 +585,17 @@ vcpu .req r0 @ vcpu pointer always in r
+ bic r3, r2, r3 @ Don't trap defined coproc-accesses
+ .endif
+ mcr p15, 4, r3, c1, c1, 2
++ .if \operation != vmentry
++ .if \operation == vmexit
++ tst r2, #(HCPTR_TCP(10) | HCPTR_TCP(11))
++ beq 1f
++ .endif
++ isb
++ .if \label != none
++ b \label
++ .endif
++1:
++ .endif
+ .endm
+
+ /* Configures the HDCR (Hyp Debug Configuration Register) on entry/return
--- /dev/null
+From 5fa7dadc898567ce14d6d6d427e7bd8ce6eb5d39 Mon Sep 17 00:00:00 2001
+From: Horia Geant? <horia.geanta@freescale.com>
+Date: Mon, 11 May 2015 20:03:24 +0300
+Subject: crypto: talitos - avoid memleak in talitos_alg_alloc()
+
+From: Horia Geant? <horia.geanta@freescale.com>
+
+commit 5fa7dadc898567ce14d6d6d427e7bd8ce6eb5d39 upstream.
+
+Fixes: 1d11911a8c57 ("crypto: talitos - fix warning: 'alg' may be used uninitialized in this function")
+Signed-off-by: Horia Geanta <horia.geanta@freescale.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/talitos.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/crypto/talitos.c
++++ b/drivers/crypto/talitos.c
+@@ -2621,6 +2621,7 @@ static struct talitos_crypto_alg *talito
+ break;
+ default:
+ dev_err(dev, "unknown algorithm type %d\n", t_alg->algt.type);
++ kfree(t_alg);
+ return ERR_PTR(-EINVAL);
+ }
+
--- /dev/null
+From 2426f3910069ed47c0cc58559a6d088af7920201 Mon Sep 17 00:00:00 2001
+From: Jan Kara <jack@suse.cz>
+Date: Thu, 21 May 2015 16:05:52 +0200
+Subject: fs: Fix S_NOSEC handling
+
+From: Jan Kara <jack@suse.cz>
+
+commit 2426f3910069ed47c0cc58559a6d088af7920201 upstream.
+
+file_remove_suid() could mistakenly set S_NOSEC inode bit when root was
+modifying the file. As a result following writes to the file by ordinary
+user would avoid clearing suid or sgid bits.
+
+Fix the bug by checking actual mode bits before setting S_NOSEC.
+
+Signed-off-by: Jan Kara <jack@suse.cz>
+Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/inode.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/fs/inode.c
++++ b/fs/inode.c
+@@ -1628,8 +1628,8 @@ int file_remove_suid(struct file *file)
+ error = security_inode_killpriv(dentry);
+ if (!error && killsuid)
+ error = __remove_suid(dentry, killsuid);
+- if (!error && (inode->i_sb->s_flags & MS_NOSEC))
+- inode->i_flags |= S_NOSEC;
++ if (!error)
++ inode_has_no_xattr(inode);
+
+ return error;
+ }
--- /dev/null
+From 42720138b06301cc8a7ee8a495a6d021c4b6a9bc Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= <rkrcmar@redhat.com>
+Date: Wed, 1 Jul 2015 15:31:49 +0200
+Subject: KVM: x86: make vapics_in_nmi_mode atomic
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: =?UTF-8?q?Radim=20Kr=C4=8Dm=C3=A1=C5=99?= <rkrcmar@redhat.com>
+
+commit 42720138b06301cc8a7ee8a495a6d021c4b6a9bc upstream.
+
+Writes were a bit racy, but hard to turn into a bug at the same time.
+(Particularly because modern Linux doesn't use this feature anymore.)
+
+Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
+[Actually the next patch makes it much, much easier to trigger the race
+ so I'm including this one for stable@ as well. - Paolo]
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/kvm_host.h | 2 +-
+ arch/x86/kvm/i8254.c | 2 +-
+ arch/x86/kvm/lapic.c | 4 ++--
+ 3 files changed, 4 insertions(+), 4 deletions(-)
+
+--- a/arch/x86/include/asm/kvm_host.h
++++ b/arch/x86/include/asm/kvm_host.h
+@@ -541,7 +541,7 @@ struct kvm_arch {
+ struct kvm_pic *vpic;
+ struct kvm_ioapic *vioapic;
+ struct kvm_pit *vpit;
+- int vapics_in_nmi_mode;
++ atomic_t vapics_in_nmi_mode;
+ struct mutex apic_map_lock;
+ struct kvm_apic_map *apic_map;
+
+--- a/arch/x86/kvm/i8254.c
++++ b/arch/x86/kvm/i8254.c
+@@ -305,7 +305,7 @@ static void pit_do_work(struct kthread_w
+ * LVT0 to NMI delivery. Other PIC interrupts are just sent to
+ * VCPU0, and only if its LVT0 is in EXTINT mode.
+ */
+- if (kvm->arch.vapics_in_nmi_mode > 0)
++ if (atomic_read(&kvm->arch.vapics_in_nmi_mode) > 0)
+ kvm_for_each_vcpu(i, vcpu, kvm)
+ kvm_apic_nmi_wd_deliver(vcpu);
+ }
+--- a/arch/x86/kvm/lapic.c
++++ b/arch/x86/kvm/lapic.c
+@@ -1123,10 +1123,10 @@ static void apic_manage_nmi_watchdog(str
+ if (!nmi_wd_enabled) {
+ apic_debug("Receive NMI setting on APIC_LVT0 "
+ "for cpu %d\n", apic->vcpu->vcpu_id);
+- apic->vcpu->kvm->arch.vapics_in_nmi_mode++;
++ atomic_inc(&apic->vcpu->kvm->arch.vapics_in_nmi_mode);
+ }
+ } else if (nmi_wd_enabled)
+- apic->vcpu->kvm->arch.vapics_in_nmi_mode--;
++ atomic_dec(&apic->vcpu->kvm->arch.vapics_in_nmi_mode);
+ }
+
+ static int apic_reg_write(struct kvm_lapic *apic, u32 reg, u32 val)
--- /dev/null
+From 8e748c8d09a9314eedb5c6367d9acfaacddcdc88 Mon Sep 17 00:00:00 2001
+From: James Hogan <james.hogan@imgtec.com>
+Date: Mon, 27 Apr 2015 15:07:16 +0100
+Subject: MIPS: Fix KVM guest fixmap address
+
+From: James Hogan <james.hogan@imgtec.com>
+
+commit 8e748c8d09a9314eedb5c6367d9acfaacddcdc88 upstream.
+
+KVM guest kernels for trap & emulate run in user mode, with a modified
+set of kernel memory segments. However the fixmap address is still in
+the normal KSeg3 region at 0xfffe0000 regardless, causing problems when
+cache alias handling makes use of them when handling copy on write.
+
+Therefore define FIXADDR_TOP as 0x7ffe0000 in the guest kernel mapped
+region when CONFIG_KVM_GUEST is defined.
+
+Signed-off-by: James Hogan <james.hogan@imgtec.com>
+Cc: linux-mips@linux-mips.org
+Patchwork: https://patchwork.linux-mips.org/patch/9887/
+Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/mips/include/asm/mach-generic/spaces.h | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/arch/mips/include/asm/mach-generic/spaces.h
++++ b/arch/mips/include/asm/mach-generic/spaces.h
+@@ -90,7 +90,11 @@
+ #endif
+
+ #ifndef FIXADDR_TOP
++#ifdef CONFIG_KVM_GUEST
++#define FIXADDR_TOP ((unsigned long)(long)(int)0x7ffe0000)
++#else
+ #define FIXADDR_TOP ((unsigned long)(long)(int)0xfffe0000)
+ #endif
++#endif
+
+ #endif /* __ASM_MACH_GENERIC_SPACES_H */
--- /dev/null
+From 72e349f1124a114435e599479c9b8d14bfd1ebcd Mon Sep 17 00:00:00 2001
+From: Anton Blanchard <anton@samba.org>
+Date: Tue, 26 May 2015 15:10:24 +1000
+Subject: powerpc/perf: Fix book3s kernel to userspace backtraces
+
+From: Anton Blanchard <anton@samba.org>
+
+commit 72e349f1124a114435e599479c9b8d14bfd1ebcd upstream.
+
+When we take a PMU exception or a software event we call
+perf_read_regs(). This overloads regs->result with a boolean that
+describes if we should use the sampled instruction address register
+(SIAR) or the regs.
+
+If the exception is in kernel, we start with the kernel regs and
+backtrace through the kernel stack. At this point we switch to the
+userspace regs and backtrace the user stack with perf_callchain_user().
+
+Unfortunately these regs have not got the perf_read_regs() treatment,
+so regs->result could be anything. If it is non zero,
+perf_instruction_pointer() decides to use the SIAR, and we get issues
+like this:
+
+0.11% qemu-system-ppc [kernel.kallsyms] [k] _raw_spin_lock_irqsave
+ |
+ ---_raw_spin_lock_irqsave
+ |
+ |--52.35%-- 0
+ | |
+ | |--46.39%-- __hrtimer_start_range_ns
+ | | kvmppc_run_core
+ | | kvmppc_vcpu_run_hv
+ | | kvmppc_vcpu_run
+ | | kvm_arch_vcpu_ioctl_run
+ | | kvm_vcpu_ioctl
+ | | do_vfs_ioctl
+ | | sys_ioctl
+ | | system_call
+ | | |
+ | | |--67.08%-- _raw_spin_lock_irqsave <--- hi mum
+ | | | |
+ | | | --100.00%-- 0x7e714
+ | | | 0x7e714
+
+Notice the bogus _raw_spin_irqsave when we transition from kernel
+(system_call) to userspace (0x7e714). We inserted what was in the SIAR.
+
+Add a check in regs_use_siar() to check that the regs in question
+are from a PMU exception. With this fix the backtrace makes sense:
+
+ 0.47% qemu-system-ppc [kernel.vmlinux] [k] _raw_spin_lock_irqsave
+ |
+ ---_raw_spin_lock_irqsave
+ |
+ |--53.83%-- 0
+ | |
+ | |--44.73%-- hrtimer_try_to_cancel
+ | | kvmppc_start_thread
+ | | kvmppc_run_core
+ | | kvmppc_vcpu_run_hv
+ | | kvmppc_vcpu_run
+ | | kvm_arch_vcpu_ioctl_run
+ | | kvm_vcpu_ioctl
+ | | do_vfs_ioctl
+ | | sys_ioctl
+ | | system_call
+ | | __ioctl
+ | | 0x7e714
+ | | 0x7e714
+
+Signed-off-by: Anton Blanchard <anton@samba.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/perf/core-book3s.c | 11 ++++++++++-
+ 1 file changed, 10 insertions(+), 1 deletion(-)
+
+--- a/arch/powerpc/perf/core-book3s.c
++++ b/arch/powerpc/perf/core-book3s.c
+@@ -112,7 +112,16 @@ static inline void power_pmu_bhrb_read(s
+
+ static bool regs_use_siar(struct pt_regs *regs)
+ {
+- return !!regs->result;
++ /*
++ * When we take a performance monitor exception the regs are setup
++ * using perf_read_regs() which overloads some fields, in particular
++ * regs->result to tell us whether to use SIAR.
++ *
++ * However if the regs are from another exception, eg. a syscall, then
++ * they have not been setup using perf_read_regs() and so regs->result
++ * is something random.
++ */
++ return ((TRAP(regs) == 0xf00) && regs->result);
+ }
+
+ /*
--- /dev/null
+From 69d9cd8c592f1abce820dbce7181bbbf6812cfbd Mon Sep 17 00:00:00 2001
+From: Horia Geant? <horia.geanta@freescale.com>
+Date: Mon, 11 May 2015 20:04:49 +0300
+Subject: Revert "crypto: talitos - convert to use be16_add_cpu()"
+
+From: Horia Geant? <horia.geanta@freescale.com>
+
+commit 69d9cd8c592f1abce820dbce7181bbbf6812cfbd upstream.
+
+This reverts commit 7291a932c6e27d9768e374e9d648086636daf61c.
+
+The conversion to be16_add_cpu() is incorrect in case cryptlen is
+negative due to premature (i.e. before addition / subtraction)
+implicit conversion of cryptlen (int -> u16) leading to sign loss.
+
+Cc: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
+Signed-off-by: Horia Geanta <horia.geanta@freescale.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/crypto/talitos.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/crypto/talitos.c
++++ b/drivers/crypto/talitos.c
+@@ -935,7 +935,8 @@ static int sg_to_link_tbl(struct scatter
+ sg_count--;
+ link_tbl_ptr--;
+ }
+- be16_add_cpu(&link_tbl_ptr->len, cryptlen);
++ link_tbl_ptr->len = cpu_to_be16(be16_to_cpu(link_tbl_ptr->len)
++ + cryptlen);
+
+ /* tag end of link table */
+ link_tbl_ptr->j_extent = DESC_PTR_LNKTBL_RETURN;
packet-read-num_members-once-in-packet_rcv_fanout.patch
packet-avoid-out-of-bounds-read-in-round-robin-fanout.patch
sctp-fix-race-between-ootb-responce-and-route-removal.patch
+crypto-talitos-avoid-memleak-in-talitos_alg_alloc.patch
+revert-crypto-talitos-convert-to-use-be16_add_cpu.patch
+arm-kvm-force-execution-of-hcptr-access-on-vm-exit.patch
+powerpc-perf-fix-book3s-kernel-to-userspace-backtraces.patch
+x86-pci-use-host-bridge-_crs-info-on-foxconn-k8m890-8237a.patch
+mips-fix-kvm-guest-fixmap-address.patch
+kvm-x86-make-vapics_in_nmi_mode-atomic.patch
+fs-fix-s_nosec-handling.patch
--- /dev/null
+From 1dace0116d0b05c967d94644fc4dfe96be2ecd3d Mon Sep 17 00:00:00 2001
+From: Bjorn Helgaas <bhelgaas@google.com>
+Date: Tue, 9 Jun 2015 18:54:07 -0500
+Subject: x86/PCI: Use host bridge _CRS info on Foxconn K8M890-8237A
+
+From: Bjorn Helgaas <bhelgaas@google.com>
+
+commit 1dace0116d0b05c967d94644fc4dfe96be2ecd3d upstream.
+
+The Foxconn K8M890-8237A has two PCI host bridges, and we can't assign
+resources correctly without the information from _CRS that tells us which
+address ranges are claimed by which bridge. In the bugs mentioned below,
+we incorrectly assign a sound card address (this example is from 1033299):
+
+ bus: 00 index 2 [mem 0x80000000-0xfcffffffff]
+ ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-7f])
+ pci_root PNP0A08:00: host bridge window [mem 0x80000000-0xbfefffff] (ignored)
+ pci_root PNP0A08:00: host bridge window [mem 0xc0000000-0xdfffffff] (ignored)
+ pci_root PNP0A08:00: host bridge window [mem 0xf0000000-0xfebfffff] (ignored)
+ ACPI: PCI Root Bridge [PCI1] (domain 0000 [bus 80-ff])
+ pci_root PNP0A08:01: host bridge window [mem 0xbff00000-0xbfffffff] (ignored)
+ pci 0000:80:01.0: [1106:3288] type 0 class 0x000403
+ pci 0000:80:01.0: reg 10: [mem 0xbfffc000-0xbfffffff 64bit]
+ pci 0000:80:01.0: address space collision: [mem 0xbfffc000-0xbfffffff 64bit] conflicts with PCI Bus #00 [mem 0x80000000-0xfcffffffff]
+ pci 0000:80:01.0: BAR 0: assigned [mem 0xfd00000000-0xfd00003fff 64bit]
+ BUG: unable to handle kernel paging request at ffffc90000378000
+ IP: [<ffffffffa0345f63>] azx_create+0x37c/0x822 [snd_hda_intel]
+
+We assigned 0xfd_0000_0000, but that is not in any of the host bridge
+windows, and the sound card doesn't work.
+
+Turn on pci=use_crs automatically for this system.
+
+Link: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/931368
+Link: https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1033299
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/pci/acpi.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+--- a/arch/x86/pci/acpi.c
++++ b/arch/x86/pci/acpi.c
+@@ -84,6 +84,17 @@ static const struct dmi_system_id pci_cr
+ DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies, LTD"),
+ },
+ },
++ /* https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/931368 */
++ /* https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1033299 */
++ {
++ .callback = set_use_crs,
++ .ident = "Foxconn K8M890-8237A",
++ .matches = {
++ DMI_MATCH(DMI_BOARD_VENDOR, "Foxconn"),
++ DMI_MATCH(DMI_BOARD_NAME, "K8M890-8237A"),
++ DMI_MATCH(DMI_BIOS_VENDOR, "Phoenix Technologies, LTD"),
++ },
++ },
+
+ /* Now for the blacklist.. */
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
