pinctrl-bcm2835-fix-cut-and-paste-error-in-pull-parsing.patch
pci-disable-io-mem-decoding-for-devices-with-non-compliant-bars.patch
pci-acpi-ia64-fix-io-port-generic-range-check.patch
+x86-irq-cure-live-lock-in-fixup_irqs.patch
+x86-apic-fix-suspicious-rcu-usage-in-smp_trace_call_function_interrupt.patch
+x86-iopl-64-properly-context-switch-iopl-on-xen-pv.patch
+x86-iopl-fix-iopl-capability-check-on-xen-pv.patch
+x86-mm-tlb_remote_send_ipi-should-count-pages.patch
--- /dev/null
+From 7834c10313fb823e538f2772be78edcdeed2e6e3 Mon Sep 17 00:00:00 2001
+From: Dave Jones <davej@codemonkey.org.uk>
+Date: Mon, 14 Mar 2016 21:20:54 -0400
+Subject: x86/apic: Fix suspicious RCU usage in smp_trace_call_function_interrupt()
+
+From: Dave Jones <davej@codemonkey.org.uk>
+
+commit 7834c10313fb823e538f2772be78edcdeed2e6e3 upstream.
+
+Since 4.4, I've been able to trigger this occasionally:
+
+===============================
+[ INFO: suspicious RCU usage. ]
+4.5.0-rc7-think+ #3 Not tainted
+Cc: Andi Kleen <ak@linux.intel.com>
+Link: http://lkml.kernel.org/r/20160315012054.GA17765@codemonkey.org.uk
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+-------------------------------
+./arch/x86/include/asm/msr-trace.h:47 suspicious rcu_dereference_check() usage!
+
+other info that might help us debug this:
+
+RCU used illegally from idle CPU!
+rcu_scheduler_active = 1, debug_locks = 1
+RCU used illegally from extended quiescent state!
+no locks held by swapper/3/0.
+
+stack backtrace:
+CPU: 3 PID: 0 Comm: swapper/3 Not tainted 4.5.0-rc7-think+ #3
+ ffffffff92f821e0 1f3e5c340597d7fc ffff880468e07f10 ffffffff92560c2a
+ ffff880462145280 0000000000000001 ffff880468e07f40 ffffffff921376a6
+ ffffffff93665ea0 0000cc7c876d28da 0000000000000005 ffffffff9383dd60
+Call Trace:
+ <IRQ> [<ffffffff92560c2a>] dump_stack+0x67/0x9d
+ [<ffffffff921376a6>] lockdep_rcu_suspicious+0xe6/0x100
+ [<ffffffff925ae7a7>] do_trace_write_msr+0x127/0x1a0
+ [<ffffffff92061c83>] native_apic_msr_eoi_write+0x23/0x30
+ [<ffffffff92054408>] smp_trace_call_function_interrupt+0x38/0x360
+ [<ffffffff92d1ca60>] trace_call_function_interrupt+0x90/0xa0
+ <EOI> [<ffffffff92ac5124>] ? cpuidle_enter_state+0x1b4/0x520
+
+Move the entering_irq() call before ack_APIC_irq(), because entering_irq()
+tells the RCU susbstems to end the extended quiescent state, so that the
+following trace call in ack_APIC_irq() works correctly.
+
+Suggested-by: Andi Kleen <ak@linux.intel.com>
+Fixes: 4787c368a9bc "x86/tracing: Add irq_enter/exit() in smp_trace_reschedule_interrupt()"
+Signed-off-by: Dave Jones <davej@codemonkey.org.uk>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+
+---
+ arch/x86/include/asm/apic.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/x86/include/asm/apic.h
++++ b/arch/x86/include/asm/apic.h
+@@ -638,8 +638,8 @@ static inline void entering_irq(void)
+
+ static inline void entering_ack_irq(void)
+ {
+- ack_APIC_irq();
+ entering_irq();
++ ack_APIC_irq();
+ }
+
+ static inline void ipi_entering_ack_irq(void)
--- /dev/null
+From b7a584598aea7ca73140cb87b40319944dd3393f Mon Sep 17 00:00:00 2001
+From: Andy Lutomirski <luto@kernel.org>
+Date: Wed, 16 Mar 2016 14:14:21 -0700
+Subject: x86/iopl/64: Properly context-switch IOPL on Xen PV
+
+From: Andy Lutomirski <luto@kernel.org>
+
+commit b7a584598aea7ca73140cb87b40319944dd3393f upstream.
+
+On Xen PV, regs->flags doesn't reliably reflect IOPL and the
+exit-to-userspace code doesn't change IOPL. We need to context
+switch it manually.
+
+I'm doing this without going through paravirt because this is
+specific to Xen PV. After the dust settles, we can merge this with
+the 32-bit code, tidy up the iopl syscall implementation, and remove
+the set_iopl pvop entirely.
+
+Fixes XSA-171.
+
+Reviewewd-by: Jan Beulich <JBeulich@suse.com>
+Signed-off-by: Andy Lutomirski <luto@kernel.org>
+Cc: Andrew Cooper <andrew.cooper3@citrix.com>
+Cc: Andy Lutomirski <luto@amacapital.net>
+Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Brian Gerst <brgerst@gmail.com>
+Cc: David Vrabel <david.vrabel@citrix.com>
+Cc: Denys Vlasenko <dvlasenk@redhat.com>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Jan Beulich <JBeulich@suse.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Link: http://lkml.kernel.org/r/693c3bd7aeb4d3c27c92c622b7d0f554a458173c.1458162709.git.luto@kernel.org
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/xen/hypervisor.h | 2 ++
+ arch/x86/kernel/process_64.c | 12 ++++++++++++
+ arch/x86/xen/enlighten.c | 2 +-
+ 3 files changed, 15 insertions(+), 1 deletion(-)
+
+--- a/arch/x86/include/asm/xen/hypervisor.h
++++ b/arch/x86/include/asm/xen/hypervisor.h
+@@ -62,4 +62,6 @@ void xen_arch_register_cpu(int num);
+ void xen_arch_unregister_cpu(int num);
+ #endif
+
++extern void xen_set_iopl_mask(unsigned mask);
++
+ #endif /* _ASM_X86_XEN_HYPERVISOR_H */
+--- a/arch/x86/kernel/process_64.c
++++ b/arch/x86/kernel/process_64.c
+@@ -48,6 +48,7 @@
+ #include <asm/syscalls.h>
+ #include <asm/debugreg.h>
+ #include <asm/switch_to.h>
++#include <asm/xen/hypervisor.h>
+
+ asmlinkage extern void ret_from_fork(void);
+
+@@ -411,6 +412,17 @@ __switch_to(struct task_struct *prev_p,
+ task_thread_info(prev_p)->flags & _TIF_WORK_CTXSW_PREV))
+ __switch_to_xtra(prev_p, next_p, tss);
+
++#ifdef CONFIG_XEN
++ /*
++ * On Xen PV, IOPL bits in pt_regs->flags have no effect, and
++ * current_pt_regs()->flags may not match the current task's
++ * intended IOPL. We need to switch it manually.
++ */
++ if (unlikely(static_cpu_has(X86_FEATURE_XENPV) &&
++ prev->iopl != next->iopl))
++ xen_set_iopl_mask(next->iopl);
++#endif
++
+ if (static_cpu_has_bug(X86_BUG_SYSRET_SS_ATTRS)) {
+ /*
+ * AMD CPUs have a misfeature: SYSRET sets the SS selector but
+--- a/arch/x86/xen/enlighten.c
++++ b/arch/x86/xen/enlighten.c
+@@ -961,7 +961,7 @@ static void xen_load_sp0(struct tss_stru
+ tss->x86_tss.sp0 = thread->sp0;
+ }
+
+-static void xen_set_iopl_mask(unsigned mask)
++void xen_set_iopl_mask(unsigned mask)
+ {
+ struct physdev_set_iopl set_iopl;
+
--- /dev/null
+From c29016cf41fe9fa994a5ecca607cf5f1cd98801e Mon Sep 17 00:00:00 2001
+From: Andy Lutomirski <luto@kernel.org>
+Date: Wed, 16 Mar 2016 14:14:22 -0700
+Subject: x86/iopl: Fix iopl capability check on Xen PV
+
+From: Andy Lutomirski <luto@kernel.org>
+
+commit c29016cf41fe9fa994a5ecca607cf5f1cd98801e upstream.
+
+iopl(3) is supposed to work if iopl is already 3, even if
+unprivileged. This didn't work right on Xen PV. Fix it.
+
+Reviewewd-by: Jan Beulich <JBeulich@suse.com>
+Signed-off-by: Andy Lutomirski <luto@kernel.org>
+Cc: Andrew Cooper <andrew.cooper3@citrix.com>
+Cc: Andy Lutomirski <luto@amacapital.net>
+Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Brian Gerst <brgerst@gmail.com>
+Cc: David Vrabel <david.vrabel@citrix.com>
+Cc: Denys Vlasenko <dvlasenk@redhat.com>
+Cc: H. Peter Anvin <hpa@zytor.com>
+Cc: Jan Beulich <JBeulich@suse.com>
+Cc: Linus Torvalds <torvalds@linux-foundation.org>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Link: http://lkml.kernel.org/r/8ce12013e6e4c0a44a97e316be4a6faff31bd5ea.1458162709.git.luto@kernel.org
+Signed-off-by: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/ioport.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+--- a/arch/x86/kernel/ioport.c
++++ b/arch/x86/kernel/ioport.c
+@@ -96,9 +96,14 @@ asmlinkage long sys_ioperm(unsigned long
+ SYSCALL_DEFINE1(iopl, unsigned int, level)
+ {
+ struct pt_regs *regs = current_pt_regs();
+- unsigned int old = (regs->flags >> 12) & 3;
+ struct thread_struct *t = ¤t->thread;
+
++ /*
++ * Careful: the IOPL bits in regs->flags are undefined under Xen PV
++ * and changing them has no effect.
++ */
++ unsigned int old = t->iopl >> X86_EFLAGS_IOPL_BIT;
++
+ if (level > 3)
+ return -EINVAL;
+ /* Trying to gain more privileges? */
+@@ -106,8 +111,9 @@ SYSCALL_DEFINE1(iopl, unsigned int, leve
+ if (!capable(CAP_SYS_RAWIO))
+ return -EPERM;
+ }
+- regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) | (level << 12);
+- t->iopl = level << 12;
++ regs->flags = (regs->flags & ~X86_EFLAGS_IOPL) |
++ (level << X86_EFLAGS_IOPL_BIT);
++ t->iopl = level << X86_EFLAGS_IOPL_BIT;
+ set_iopl_mask(t->iopl);
+
+ return 0;
--- /dev/null
+From 551adc60573cb68e3d55cacca9ba1b7437313df7 Mon Sep 17 00:00:00 2001
+From: Thomas Gleixner <tglx@linutronix.de>
+Date: Mon, 14 Mar 2016 09:40:46 +0100
+Subject: x86/irq: Cure live lock in fixup_irqs()
+
+From: Thomas Gleixner <tglx@linutronix.de>
+
+commit 551adc60573cb68e3d55cacca9ba1b7437313df7 upstream.
+
+Harry reported, that he's able to trigger a system freeze with cpu hot
+unplug. The freeze turned out to be a live lock caused by recent changes in
+irq_force_complete_move().
+
+When fixup_irqs() and from there irq_force_complete_move() is called on the
+dying cpu, then all other cpus are in stop machine an wait for the dying cpu
+to complete the teardown. If there is a move of an interrupt pending then
+irq_force_complete_move() sends the cleanup IPI to the cpus in the old_domain
+mask and waits for them to clear the mask. That's obviously impossible as
+those cpus are firmly stuck in stop machine with interrupts disabled.
+
+I should have known that, but I completely overlooked it being concentrated on
+the locking issues around the vectors. And the existance of the call to
+__irq_complete_move() in the code, which actually sends the cleanup IPI made
+it reasonable to wait for that cleanup to complete. That call was bogus even
+before the recent changes as it was just a pointless distraction.
+
+We have to look at two cases:
+
+1) The move_in_progress flag of the interrupt is set
+
+ This means the ioapic has been updated with the new vector, but it has not
+ fired yet. In theory there is a race:
+
+ set_ioapic(new_vector) <-- Interrupt is raised before update is effective,
+ i.e. it's raised on the old vector.
+
+ So if the target cpu cannot handle that interrupt before the old vector is
+ cleaned up, we get a spurious interrupt and in the worst case the ioapic
+ irq line becomes stale, but my experiments so far have only resulted in
+ spurious interrupts.
+
+ But in case of cpu hotplug this should be a non issue because if the
+ affinity update happens right before all cpus rendevouz in stop machine,
+ there is no way that the interrupt can be blocked on the target cpu because
+ all cpus loops first with interrupts enabled in stop machine, so the old
+ vector is not yet cleaned up when the interrupt fires.
+
+ So the only way to run into this issue is if the delivery of the interrupt
+ on the apic/system bus would be delayed beyond the point where the target
+ cpu disables interrupts in stop machine. I doubt that it can happen, but at
+ least there is a theroretical chance. Virtualization might be able to
+ expose this, but AFAICT the IOAPIC emulation is not as stupid as the real
+ hardware.
+
+ I've spent quite some time over the weekend to enforce that situation,
+ though I was not able to trigger the delayed case.
+
+2) The move_in_progress flag is not set and the old_domain cpu mask is not
+ empty.
+
+ That means, that an interrupt was delivered after the change and the
+ cleanup IPI has been sent to the cpus in old_domain, but not all CPUs have
+ responded to it yet.
+
+In both cases we can assume that the next interrupt will arrive on the new
+vector, so we can cleanup the old vectors on the cpus in the old_domain cpu
+mask.
+
+Fixes: 98229aa36caa "x86/irq: Plug vector cleanup race"
+Reported-by: Harry Junior <harryjr@outlook.fr>
+Tested-by: Tony Luck <tony.luck@intel.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: Joe Lawrence <joe.lawrence@stratus.com>
+Cc: Borislav Petkov <bp@alien8.de>
+Cc: Ben Hutchings <ben@decadent.org.uk>
+Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1603140931430.3657@nanos
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/include/asm/hw_irq.h | 1
+ arch/x86/kernel/apic/vector.c | 88 +++++++++++++++++++++++++++++++++---------
+ 2 files changed, 71 insertions(+), 18 deletions(-)
+
+--- a/arch/x86/include/asm/hw_irq.h
++++ b/arch/x86/include/asm/hw_irq.h
+@@ -136,6 +136,7 @@ struct irq_alloc_info {
+ struct irq_cfg {
+ unsigned int dest_apicid;
+ u8 vector;
++ u8 old_vector;
+ };
+
+ extern struct irq_cfg *irq_cfg(unsigned int irq);
+--- a/arch/x86/kernel/apic/vector.c
++++ b/arch/x86/kernel/apic/vector.c
+@@ -211,6 +211,7 @@ update:
+ */
+ cpumask_and(d->old_domain, d->old_domain, cpu_online_mask);
+ d->move_in_progress = !cpumask_empty(d->old_domain);
++ d->cfg.old_vector = d->move_in_progress ? d->cfg.vector : 0;
+ d->cfg.vector = vector;
+ cpumask_copy(d->domain, vector_cpumask);
+ success:
+@@ -653,46 +654,97 @@ void irq_complete_move(struct irq_cfg *c
+ }
+
+ /*
+- * Called with @desc->lock held and interrupts disabled.
++ * Called from fixup_irqs() with @desc->lock held and interrupts disabled.
+ */
+ void irq_force_complete_move(struct irq_desc *desc)
+ {
+ struct irq_data *irqdata = irq_desc_get_irq_data(desc);
+ struct apic_chip_data *data = apic_chip_data(irqdata);
+ struct irq_cfg *cfg = data ? &data->cfg : NULL;
++ unsigned int cpu;
+
+ if (!cfg)
+ return;
+
+- __irq_complete_move(cfg, cfg->vector);
+-
+ /*
+ * This is tricky. If the cleanup of @data->old_domain has not been
+ * done yet, then the following setaffinity call will fail with
+ * -EBUSY. This can leave the interrupt in a stale state.
+ *
+- * The cleanup cannot make progress because we hold @desc->lock. So in
+- * case @data->old_domain is not yet cleaned up, we need to drop the
+- * lock and acquire it again. @desc cannot go away, because the
+- * hotplug code holds the sparse irq lock.
++ * All CPUs are stuck in stop machine with interrupts disabled so
++ * calling __irq_complete_move() would be completely pointless.
+ */
+ raw_spin_lock(&vector_lock);
+- /* Clean out all offline cpus (including ourself) first. */
++ /*
++ * Clean out all offline cpus (including the outgoing one) from the
++ * old_domain mask.
++ */
+ cpumask_and(data->old_domain, data->old_domain, cpu_online_mask);
+- while (!cpumask_empty(data->old_domain)) {
++
++ /*
++ * If move_in_progress is cleared and the old_domain mask is empty,
++ * then there is nothing to cleanup. fixup_irqs() will take care of
++ * the stale vectors on the outgoing cpu.
++ */
++ if (!data->move_in_progress && cpumask_empty(data->old_domain)) {
+ raw_spin_unlock(&vector_lock);
+- raw_spin_unlock(&desc->lock);
+- cpu_relax();
+- raw_spin_lock(&desc->lock);
++ return;
++ }
++
++ /*
++ * 1) The interrupt is in move_in_progress state. That means that we
++ * have not seen an interrupt since the io_apic was reprogrammed to
++ * the new vector.
++ *
++ * 2) The interrupt has fired on the new vector, but the cleanup IPIs
++ * have not been processed yet.
++ */
++ if (data->move_in_progress) {
+ /*
+- * Reevaluate apic_chip_data. It might have been cleared after
+- * we dropped @desc->lock.
++ * In theory there is a race:
++ *
++ * set_ioapic(new_vector) <-- Interrupt is raised before update
++ * is effective, i.e. it's raised on
++ * the old vector.
++ *
++ * So if the target cpu cannot handle that interrupt before
++ * the old vector is cleaned up, we get a spurious interrupt
++ * and in the worst case the ioapic irq line becomes stale.
++ *
++ * But in case of cpu hotplug this should be a non issue
++ * because if the affinity update happens right before all
++ * cpus rendevouz in stop machine, there is no way that the
++ * interrupt can be blocked on the target cpu because all cpus
++ * loops first with interrupts enabled in stop machine, so the
++ * old vector is not yet cleaned up when the interrupt fires.
++ *
++ * So the only way to run into this issue is if the delivery
++ * of the interrupt on the apic/system bus would be delayed
++ * beyond the point where the target cpu disables interrupts
++ * in stop machine. I doubt that it can happen, but at least
++ * there is a theroretical chance. Virtualization might be
++ * able to expose this, but AFAICT the IOAPIC emulation is not
++ * as stupid as the real hardware.
++ *
++ * Anyway, there is nothing we can do about that at this point
++ * w/o refactoring the whole fixup_irq() business completely.
++ * We print at least the irq number and the old vector number,
++ * so we have the necessary information when a problem in that
++ * area arises.
+ */
+- data = apic_chip_data(irqdata);
+- if (!data)
+- return;
+- raw_spin_lock(&vector_lock);
++ pr_warn("IRQ fixup: irq %d move in progress, old vector %d\n",
++ irqdata->irq, cfg->old_vector);
+ }
++ /*
++ * If old_domain is not empty, then other cpus still have the irq
++ * descriptor set in their vector array. Clean it up.
++ */
++ for_each_cpu(cpu, data->old_domain)
++ per_cpu(vector_irq, cpu)[cfg->old_vector] = VECTOR_UNUSED;
++
++ /* Cleanup the left overs of the (half finished) move */
++ cpumask_clear(data->old_domain);
++ data->move_in_progress = 0;
+ raw_spin_unlock(&vector_lock);
+ }
+ #endif
--- /dev/null
+From 18c98243ddf05a1827ad2c359c5ac051101e7ff7 Mon Sep 17 00:00:00 2001
+From: Nadav Amit <namit@vmware.com>
+Date: Fri, 1 Apr 2016 14:31:23 -0700
+Subject: x86/mm: TLB_REMOTE_SEND_IPI should count pages
+
+From: Nadav Amit <namit@vmware.com>
+
+commit 18c98243ddf05a1827ad2c359c5ac051101e7ff7 upstream.
+
+TLB_REMOTE_SEND_IPI was recently introduced, but it counts bytes instead
+of pages. In addition, it does not report correctly the case in which
+flush_tlb_page flushes a page. Fix it to be consistent with other TLB
+counters.
+
+Fixes: 5b74283ab251b9d ("x86, mm: trace when an IPI is about to be sent")
+Signed-off-by: Nadav Amit <namit@vmware.com>
+Cc: Mel Gorman <mgorman@suse.de>
+Cc: Rik van Riel <riel@redhat.com>
+Cc: Dave Hansen <dave.hansen@intel.com>
+Cc: Ingo Molnar <mingo@kernel.org>
+Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/mm/tlb.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+--- a/arch/x86/mm/tlb.c
++++ b/arch/x86/mm/tlb.c
+@@ -106,8 +106,6 @@ static void flush_tlb_func(void *info)
+
+ if (f->flush_mm != this_cpu_read(cpu_tlbstate.active_mm))
+ return;
+- if (!f->flush_end)
+- f->flush_end = f->flush_start + PAGE_SIZE;
+
+ count_vm_tlb_event(NR_TLB_REMOTE_FLUSH_RECEIVED);
+ if (this_cpu_read(cpu_tlbstate.state) == TLBSTATE_OK) {
+@@ -135,12 +133,20 @@ void native_flush_tlb_others(const struc
+ unsigned long end)
+ {
+ struct flush_tlb_info info;
++
++ if (end == 0)
++ end = start + PAGE_SIZE;
+ info.flush_mm = mm;
+ info.flush_start = start;
+ info.flush_end = end;
+
+ count_vm_tlb_event(NR_TLB_REMOTE_FLUSH);
+- trace_tlb_flush(TLB_REMOTE_SEND_IPI, end - start);
++ if (end == TLB_FLUSH_ALL)
++ trace_tlb_flush(TLB_REMOTE_SEND_IPI, TLB_FLUSH_ALL);
++ else
++ trace_tlb_flush(TLB_REMOTE_SEND_IPI,
++ (end - start) >> PAGE_SHIFT);
++
+ if (is_uv_system()) {
+ unsigned int cpu;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
