From: Greg Kroah-Hartman Date: Sat, 9 Apr 2016 23:05:42 +0000 (-0700) Subject: 4.5-stable patches X-Git-Tag: v4.5.1~35 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=1783df7d03ac5700af684825b421ace444b6b885;p=thirdparty%2Fkernel%2Fstable-queue.git 4.5-stable patches added patches: 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-irq-cure-live-lock-in-fixup_irqs.patch x86-mm-tlb_remote_send_ipi-should-count-pages.patch --- diff --git a/queue-4.5/series b/queue-4.5/series index 9d758904d40..c1e50bb7bf7 100644 --- a/queue-4.5/series +++ b/queue-4.5/series @@ -25,3 +25,8 @@ s390-pci-enforce-fmb-page-boundary-rule.patch 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 diff --git a/queue-4.5/x86-apic-fix-suspicious-rcu-usage-in-smp_trace_call_function_interrupt.patch b/queue-4.5/x86-apic-fix-suspicious-rcu-usage-in-smp_trace_call_function_interrupt.patch new file mode 100644 index 00000000000..15b256abc42 --- /dev/null +++ b/queue-4.5/x86-apic-fix-suspicious-rcu-usage-in-smp_trace_call_function_interrupt.patch @@ -0,0 +1,68 @@ +From 7834c10313fb823e538f2772be78edcdeed2e6e3 Mon Sep 17 00:00:00 2001 +From: Dave Jones +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 + +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 +Link: http://lkml.kernel.org/r/20160315012054.GA17765@codemonkey.org.uk +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +------------------------------- +./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: + [] dump_stack+0x67/0x9d + [] lockdep_rcu_suspicious+0xe6/0x100 + [] do_trace_write_msr+0x127/0x1a0 + [] native_apic_msr_eoi_write+0x23/0x30 + [] smp_trace_call_function_interrupt+0x38/0x360 + [] trace_call_function_interrupt+0x90/0xa0 + [] ? 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 +Fixes: 4787c368a9bc "x86/tracing: Add irq_enter/exit() in smp_trace_reschedule_interrupt()" +Signed-off-by: Dave Jones +Signed-off-by: Thomas Gleixner + +--- + 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 +@@ -644,8 +644,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) diff --git a/queue-4.5/x86-iopl-64-properly-context-switch-iopl-on-xen-pv.patch b/queue-4.5/x86-iopl-64-properly-context-switch-iopl-on-xen-pv.patch new file mode 100644 index 00000000000..9c0e49886f9 --- /dev/null +++ b/queue-4.5/x86-iopl-64-properly-context-switch-iopl-on-xen-pv.patch @@ -0,0 +1,92 @@ +From b7a584598aea7ca73140cb87b40319944dd3393f Mon Sep 17 00:00:00 2001 +From: Andy Lutomirski +Date: Wed, 16 Mar 2016 14:14:21 -0700 +Subject: x86/iopl/64: Properly context-switch IOPL on Xen PV + +From: Andy Lutomirski + +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 +Signed-off-by: Andy Lutomirski +Cc: Andrew Cooper +Cc: Andy Lutomirski +Cc: Boris Ostrovsky +Cc: Borislav Petkov +Cc: Brian Gerst +Cc: David Vrabel +Cc: Denys Vlasenko +Cc: H. Peter Anvin +Cc: Jan Beulich +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Link: http://lkml.kernel.org/r/693c3bd7aeb4d3c27c92c622b7d0f554a458173c.1458162709.git.luto@kernel.org +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + 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 + #include + #include ++#include + + 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; + diff --git a/queue-4.5/x86-iopl-fix-iopl-capability-check-on-xen-pv.patch b/queue-4.5/x86-iopl-fix-iopl-capability-check-on-xen-pv.patch new file mode 100644 index 00000000000..b3f8425b3e2 --- /dev/null +++ b/queue-4.5/x86-iopl-fix-iopl-capability-check-on-xen-pv.patch @@ -0,0 +1,64 @@ +From c29016cf41fe9fa994a5ecca607cf5f1cd98801e Mon Sep 17 00:00:00 2001 +From: Andy Lutomirski +Date: Wed, 16 Mar 2016 14:14:22 -0700 +Subject: x86/iopl: Fix iopl capability check on Xen PV + +From: Andy Lutomirski + +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 +Signed-off-by: Andy Lutomirski +Cc: Andrew Cooper +Cc: Andy Lutomirski +Cc: Boris Ostrovsky +Cc: Borislav Petkov +Cc: Brian Gerst +Cc: David Vrabel +Cc: Denys Vlasenko +Cc: H. Peter Anvin +Cc: Jan Beulich +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Link: http://lkml.kernel.org/r/8ce12013e6e4c0a44a97e316be4a6faff31bd5ea.1458162709.git.luto@kernel.org +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + 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; diff --git a/queue-4.5/x86-irq-cure-live-lock-in-fixup_irqs.patch b/queue-4.5/x86-irq-cure-live-lock-in-fixup_irqs.patch new file mode 100644 index 00000000000..388be3c8bee --- /dev/null +++ b/queue-4.5/x86-irq-cure-live-lock-in-fixup_irqs.patch @@ -0,0 +1,221 @@ +From 551adc60573cb68e3d55cacca9ba1b7437313df7 Mon Sep 17 00:00:00 2001 +From: Thomas Gleixner +Date: Mon, 14 Mar 2016 09:40:46 +0100 +Subject: x86/irq: Cure live lock in fixup_irqs() + +From: Thomas Gleixner + +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 +Tested-by: Tony Luck +Signed-off-by: Thomas Gleixner +Cc: Peter Zijlstra +Cc: Joe Lawrence +Cc: Borislav Petkov +Cc: Ben Hutchings +Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1603140931430.3657@nanos +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + 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 +@@ -141,6 +141,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 +@@ -213,6 +213,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: +@@ -655,46 +656,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 diff --git a/queue-4.5/x86-mm-tlb_remote_send_ipi-should-count-pages.patch b/queue-4.5/x86-mm-tlb_remote_send_ipi-should-count-pages.patch new file mode 100644 index 00000000000..070dab10eae --- /dev/null +++ b/queue-4.5/x86-mm-tlb_remote_send_ipi-should-count-pages.patch @@ -0,0 +1,61 @@ +From 18c98243ddf05a1827ad2c359c5ac051101e7ff7 Mon Sep 17 00:00:00 2001 +From: Nadav Amit +Date: Fri, 1 Apr 2016 14:31:23 -0700 +Subject: x86/mm: TLB_REMOTE_SEND_IPI should count pages + +From: Nadav Amit + +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 +Cc: Mel Gorman +Cc: Rik van Riel +Cc: Dave Hansen +Cc: Ingo Molnar +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + 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; +