--- /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
+@@ -467,7 +465,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
+@@ -578,8 +578,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
+@@ -588,6 +593,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
+@@ -2563,6 +2563,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
+@@ -1631,8 +1631,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 0dd23f94251f49da99a6cbfb22418b2d757d77d6 Mon Sep 17 00:00:00 2001
+From: Joe Konno <joe.konno@intel.com>
+Date: Tue, 12 May 2015 07:59:42 -0700
+Subject: intel_pstate: set BYT MSR with wrmsrl_on_cpu()
+
+From: Joe Konno <joe.konno@intel.com>
+
+commit 0dd23f94251f49da99a6cbfb22418b2d757d77d6 upstream.
+
+Commit 007bea098b86 (intel_pstate: Add setting voltage value for
+baytrail P states.) introduced byt_set_pstate() with the assumption that
+it would always be run by the CPU whose MSR is to be written by it. It
+turns out, however, that is not always the case in practice, so modify
+byt_set_pstate() to enforce the MSR write done by it to always happen on
+the right CPU.
+
+Fixes: 007bea098b86 (intel_pstate: Add setting voltage value for baytrail P states.)
+Signed-off-by: Joe Konno <joe.konno@intel.com>
+Acked-by: Kristen Carlson Accardi <kristen@linux.intel.com>
+Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/cpufreq/intel_pstate.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/cpufreq/intel_pstate.c
++++ b/drivers/cpufreq/intel_pstate.c
+@@ -417,7 +417,7 @@ static void byt_set_pstate(struct cpudat
+
+ val |= vid;
+
+- wrmsrl(MSR_IA32_PERF_CTL, val);
++ wrmsrl_on_cpu(cpudata->cpu, MSR_IA32_PERF_CTL, val);
+ }
+
+ #define BYT_BCLK_FREQS 5
--- /dev/null
+From 0b3fff54bc01e8e6064d222a33e6fa7adabd94cd Mon Sep 17 00:00:00 2001
+From: Joerg Roedel <jroedel@suse.de>
+Date: Thu, 18 Jun 2015 10:48:34 +0200
+Subject: iommu/amd: Handle large pages correctly in free_pagetable
+
+From: Joerg Roedel <jroedel@suse.de>
+
+commit 0b3fff54bc01e8e6064d222a33e6fa7adabd94cd upstream.
+
+Make sure that we are skipping over large PTEs while walking
+the page-table tree.
+
+Fixes: 5c34c403b723 ("iommu/amd: Fix memory leak in free_pagetable")
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/iommu/amd_iommu.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+--- a/drivers/iommu/amd_iommu.c
++++ b/drivers/iommu/amd_iommu.c
+@@ -1922,9 +1922,15 @@ static void free_pt_##LVL (unsigned long
+ pt = (u64 *)__pt; \
+ \
+ for (i = 0; i < 512; ++i) { \
++ /* PTE present? */ \
+ if (!IOMMU_PTE_PRESENT(pt[i])) \
+ continue; \
+ \
++ /* Large PTE? */ \
++ if (PM_PTE_LEVEL(pt[i]) == 0 || \
++ PM_PTE_LEVEL(pt[i]) == 7) \
++ continue; \
++ \
+ p = (unsigned long)IOMMU_PTE_PAGE(pt[i]); \
+ FN(p); \
+ } \
--- /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
+@@ -571,7 +571,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
+@@ -1109,10 +1109,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
+@@ -94,7 +94,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
+@@ -124,7 +124,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
+@@ -927,7 +927,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;
tcp-do-not-call-tcp_fastopen_reset_cipher-from-interrupt-context.patch
net-phy-fix-phy-link-up-when-limiting-speed-via-device-tree.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
+iommu-amd-handle-large-pages-correctly-in-free_pagetable.patch
+intel_pstate-set-byt-msr-with-wrmsrl_on_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-systems-with-32-bit-addressing.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
+vfs-remove-incorrect-debugging-warn-in-prepend_path.patch
+vfs-ignore-unlocked-mounts-in-fs_fully_visible.patch
--- /dev/null
+From ceeb0e5d39fcdf4dca2c997bf225c7fc49200b37 Mon Sep 17 00:00:00 2001
+From: "Eric W. Biederman" <ebiederm@xmission.com>
+Date: Wed, 7 Jan 2015 08:10:09 -0600
+Subject: vfs: Ignore unlocked mounts in fs_fully_visible
+
+From: "Eric W. Biederman" <ebiederm@xmission.com>
+
+commit ceeb0e5d39fcdf4dca2c997bf225c7fc49200b37 upstream.
+
+Limit the mounts fs_fully_visible considers to locked mounts.
+Unlocked can always be unmounted so considering them adds hassle
+but no security benefit.
+
+Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/namespace.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+--- a/fs/namespace.c
++++ b/fs/namespace.c
+@@ -3031,11 +3031,15 @@ bool fs_fully_visible(struct file_system
+ if (mnt->mnt.mnt_root != mnt->mnt.mnt_sb->s_root)
+ continue;
+
+- /* This mount is not fully visible if there are any child mounts
+- * that cover anything except for empty directories.
++ /* This mount is not fully visible if there are any
++ * locked child mounts that cover anything except for
++ * empty directories.
+ */
+ list_for_each_entry(child, &mnt->mnt_mounts, mnt_child) {
+ struct inode *inode = child->mnt_mountpoint->d_inode;
++ /* Only worry about locked mounts */
++ if (!(mnt->mnt.mnt_flags & MNT_LOCKED))
++ continue;
+ if (!S_ISDIR(inode->i_mode))
+ goto next;
+ if (inode->i_nlink > 2)
--- /dev/null
+From 93e3bce6287e1fb3e60d3324ed08555b5bbafa89 Mon Sep 17 00:00:00 2001
+From: "Eric W. Biederman" <ebiederm@xmission.com>
+Date: Sun, 24 May 2015 09:25:00 -0500
+Subject: vfs: Remove incorrect debugging WARN in prepend_path
+
+From: "Eric W. Biederman" <ebiederm@xmission.com>
+
+commit 93e3bce6287e1fb3e60d3324ed08555b5bbafa89 upstream.
+
+The warning message in prepend_path is unclear and outdated. It was
+added as a warning that the mechanism for generating names of pseudo
+files had been removed from prepend_path and d_dname should be used
+instead. Unfortunately the warning reads like a general warning,
+making it unclear what to do with it.
+
+Remove the warning. The transition it was added to warn about is long
+over, and I added code several years ago which in rare cases causes
+the warning to fire on legitimate code, and the warning is now firing
+and scaring people for no good reason.
+
+Reported-by: Ivan Delalande <colona@arista.com>
+Reported-by: Omar Sandoval <osandov@osandov.com>
+Fixes: f48cfddc6729e ("vfs: In d_path don't call d_dname on a mount point")
+Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ fs/dcache.c | 11 -----------
+ 1 file changed, 11 deletions(-)
+
+--- a/fs/dcache.c
++++ b/fs/dcache.c
+@@ -2905,17 +2905,6 @@ restart:
+ vfsmnt = &mnt->mnt;
+ continue;
+ }
+- /*
+- * Filesystems needing to implement special "root names"
+- * should do so with ->d_dname()
+- */
+- if (IS_ROOT(dentry) &&
+- (dentry->d_name.len != 1 ||
+- dentry->d_name.name[0] != '/')) {
+- WARN(1, "Root dentry has weird name <%.*s>\n",
+- (int) dentry->d_name.len,
+- dentry->d_name.name);
+- }
+ if (!error)
+ error = is_mounted(vfsmnt) ? 1 : 2;
+ break;
--- /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.. */
+
--- /dev/null
+From 3d9fecf6bfb8b12bc2f9a4c7109895a2a2bb9436 Mon Sep 17 00:00:00 2001
+From: Bjorn Helgaas <bhelgaas@google.com>
+Date: Tue, 9 Jun 2015 17:31:38 -0500
+Subject: x86/PCI: Use host bridge _CRS info on systems with >32 bit addressing
+
+From: Bjorn Helgaas <bhelgaas@google.com>
+
+commit 3d9fecf6bfb8b12bc2f9a4c7109895a2a2bb9436 upstream.
+
+We enable _CRS on all systems from 2008 and later. On older systems, we
+ignore _CRS and assume the whole physical address space (excluding RAM and
+other devices) is available for PCI devices, but on systems that support
+physical address spaces larger than 4GB, it's doubtful that the area above
+4GB is really available for PCI.
+
+After d56dbf5bab8c ("PCI: Allocate 64-bit BARs above 4G when possible"), we
+try to use that space above 4GB *first*, so we're more likely to put a
+device there.
+
+On Juan's Toshiba Satellite Pro U200, BIOS left the graphics, sound, 1394,
+and card reader devices unassigned (but only after Windows had been
+booted). Only the sound device had a 64-bit BAR, so it was the only device
+placed above 4GB, and hence the only device that didn't work.
+
+Keep _CRS enabled even on pre-2008 systems if they support physical address
+space larger than 4GB.
+
+Fixes: d56dbf5bab8c ("PCI: Allocate 64-bit BARs above 4G when possible")
+Reported-and-tested-by: Juan Dayer <jdayer@outlook.com>
+Reported-and-tested-by: Alan Horsfield <alan@hazelgarth.co.uk>
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=99221
+Link: https://bugzilla.opensuse.org/show_bug.cgi?id=907092
+Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/pci/acpi.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/pci/acpi.c
++++ b/arch/x86/pci/acpi.c
+@@ -124,8 +124,10 @@ void __init pci_acpi_crs_quirks(void)
+ {
+ int year;
+
+- if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) && year < 2008)
+- pci_use_crs = false;
++ if (dmi_get_date(DMI_BIOS_DATE, &year, NULL, NULL) && year < 2008) {
++ if (iomem_resource.end <= 0xffffffff)
++ pci_use_crs = false;
++ }
+
+ dmi_check_system(pci_crs_quirks);
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
