From: Greg Kroah-Hartman Date: Mon, 20 Mar 2017 17:33:20 +0000 (+0100) Subject: 4.10-stable patches X-Git-Tag: v4.4.56~3 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=7b7defae22814b69a5e00075b9e5b5d469e6345d;p=thirdparty%2Fkernel%2Fstable-queue.git 4.10-stable patches added patches: crypto-powerpc-fix-initialisation-of-crc32c-context.patch crypto-s5p-sss-fix-spinlock-recursion-on-lrw-aes.patch futex-add-missing-error-handling-to-futex_requeue_pi.patch futex-fix-potential-use-after-free-in-futex_requeue_pi.patch locking-rwsem-fix-down_write_killable-for-config_rwsem_generic_spinlock-y.patch x86-intel_rdt-put-group-node-in-rdtgroup_kn_unlock.patch x86-kasan-fix-boot-with-kasan-y-and-profile_annotated_branches-y.patch x86-perf-fix-cr4.pce-propagation-to-use-active_mm-instead-of-mm.patch x86-tsc-fix-art-for-tsc_known_freq.patch x86-unwind-fix-last-frame-check-for-aligned-function-stacks.patch --- diff --git a/queue-4.10/crypto-powerpc-fix-initialisation-of-crc32c-context.patch b/queue-4.10/crypto-powerpc-fix-initialisation-of-crc32c-context.patch new file mode 100644 index 00000000000..834ad271734 --- /dev/null +++ b/queue-4.10/crypto-powerpc-fix-initialisation-of-crc32c-context.patch @@ -0,0 +1,47 @@ +From aa2be9b3d6d2d699e9ca7cbfc00867c80e5da213 Mon Sep 17 00:00:00 2001 +From: Daniel Axtens +Date: Fri, 3 Mar 2017 17:56:55 +1100 +Subject: crypto: powerpc - Fix initialisation of crc32c context + +From: Daniel Axtens + +commit aa2be9b3d6d2d699e9ca7cbfc00867c80e5da213 upstream. + +Turning on crypto self-tests on a POWER8 shows: + + alg: hash: Test 1 failed for crc32c-vpmsum + 00000000: ff ff ff ff + +Comparing the code with the Intel CRC32c implementation on which +ours is based shows that we are doing an init with 0, not ~0 +as CRC32c requires. + +This probably wasn't caught because btrfs does its own weird +open-coded initialisation. + +Initialise our internal context to ~0 on init. + +This makes the self-tests pass, and btrfs continues to work. + +Fixes: 6dd7a82cc54e ("crypto: powerpc - Add POWER8 optimised crc32c") +Cc: Anton Blanchard +Signed-off-by: Daniel Axtens +Acked-by: Anton Blanchard +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + arch/powerpc/crypto/crc32c-vpmsum_glue.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/powerpc/crypto/crc32c-vpmsum_glue.c ++++ b/arch/powerpc/crypto/crc32c-vpmsum_glue.c +@@ -52,7 +52,7 @@ static int crc32c_vpmsum_cra_init(struct + { + u32 *key = crypto_tfm_ctx(tfm); + +- *key = 0; ++ *key = ~0; + + return 0; + } diff --git a/queue-4.10/crypto-s5p-sss-fix-spinlock-recursion-on-lrw-aes.patch b/queue-4.10/crypto-s5p-sss-fix-spinlock-recursion-on-lrw-aes.patch new file mode 100644 index 00000000000..5da9cb35a71 --- /dev/null +++ b/queue-4.10/crypto-s5p-sss-fix-spinlock-recursion-on-lrw-aes.patch @@ -0,0 +1,266 @@ +From 28b62b1458685d8f68f67d9b2d511bf8fa32b746 Mon Sep 17 00:00:00 2001 +From: Krzysztof Kozlowski +Date: Wed, 8 Mar 2017 23:14:20 +0200 +Subject: crypto: s5p-sss - Fix spinlock recursion on LRW(AES) +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Krzysztof Kozlowski + +commit 28b62b1458685d8f68f67d9b2d511bf8fa32b746 upstream. + +Running TCRYPT with LRW compiled causes spinlock recursion: + + testing speed of async lrw(aes) (lrw(ecb-aes-s5p)) encryption + tcrypt: test 0 (256 bit key, 16 byte blocks): 19007 operations in 1 seconds (304112 bytes) + tcrypt: test 1 (256 bit key, 64 byte blocks): 15753 operations in 1 seconds (1008192 bytes) + tcrypt: test 2 (256 bit key, 256 byte blocks): 14293 operations in 1 seconds (3659008 bytes) + tcrypt: test 3 (256 bit key, 1024 byte blocks): 11906 operations in 1 seconds (12191744 bytes) + tcrypt: test 4 (256 bit key, 8192 byte blocks): + BUG: spinlock recursion on CPU#1, irq/84-10830000/89 +  lock: 0xeea99a68, .magic: dead4ead, .owner: irq/84-10830000/89, .owner_cpu: 1 + CPU: 1 PID: 89 Comm: irq/84-10830000 Not tainted 4.11.0-rc1-00001-g897ca6d0800d #559 + Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) + [] (unwind_backtrace) from [] (show_stack+0x10/0x14) + [] (show_stack) from [] (dump_stack+0x78/0x8c) + [] (dump_stack) from [] (do_raw_spin_lock+0x11c/0x120) + [] (do_raw_spin_lock) from [] (_raw_spin_lock_irqsave+0x20/0x28) + [] (_raw_spin_lock_irqsave) from [] (s5p_aes_crypt+0x2c/0xb4) + [] (s5p_aes_crypt) from [] (do_encrypt+0x78/0xb0 [lrw]) + [] (do_encrypt [lrw]) from [] (encrypt_done+0x24/0x54 [lrw]) + [] (encrypt_done [lrw]) from [] (s5p_aes_complete+0x60/0xcc) + [] (s5p_aes_complete) from [] (s5p_aes_interrupt+0x134/0x1a0) + [] (s5p_aes_interrupt) from [] (irq_thread_fn+0x1c/0x54) + [] (irq_thread_fn) from [] (irq_thread+0x12c/0x1e0) + [] (irq_thread) from [] (kthread+0x108/0x138) + [] (kthread) from [] (ret_from_fork+0x14/0x3c) + +Interrupt handling routine was calling req->base.complete() under +spinlock. In most cases this wasn't fatal but when combined with some +of the cipher modes (like LRW) this caused recursion - starting the new +encryption (s5p_aes_crypt()) while still holding the spinlock from +previous round (s5p_aes_complete()). + +Beside that, the s5p_aes_interrupt() error handling path could execute +two completions in case of error for RX and TX blocks. + +Rewrite the interrupt handling routine and the completion by: + +1. Splitting the operations on scatterlist copies from + s5p_aes_complete() into separate s5p_sg_done(). This still should be + done under lock. + The s5p_aes_complete() now only calls req->base.complete() and it has + to be called outside of lock. + +2. Moving the s5p_aes_complete() out of spinlock critical sections. + In interrupt service routine s5p_aes_interrupts(), it appeared in few + places, including error paths inside other functions called from ISR. + This code was not so obvious to read so simplify it by putting the + s5p_aes_complete() only within ISR level. + +Reported-by: Nathan Royce +Signed-off-by: Krzysztof Kozlowski +Signed-off-by: Herbert Xu +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/crypto/s5p-sss.c | 127 ++++++++++++++++++++++++++++++----------------- + 1 file changed, 82 insertions(+), 45 deletions(-) + +--- a/drivers/crypto/s5p-sss.c ++++ b/drivers/crypto/s5p-sss.c +@@ -270,7 +270,7 @@ static void s5p_sg_copy_buf(void *buf, s + scatterwalk_done(&walk, out, 0); + } + +-static void s5p_aes_complete(struct s5p_aes_dev *dev, int err) ++static void s5p_sg_done(struct s5p_aes_dev *dev) + { + if (dev->sg_dst_cpy) { + dev_dbg(dev->dev, +@@ -281,8 +281,11 @@ static void s5p_aes_complete(struct s5p_ + } + s5p_free_sg_cpy(dev, &dev->sg_src_cpy); + s5p_free_sg_cpy(dev, &dev->sg_dst_cpy); ++} + +- /* holding a lock outside */ ++/* Calls the completion. Cannot be called with dev->lock hold. */ ++static void s5p_aes_complete(struct s5p_aes_dev *dev, int err) ++{ + dev->req->base.complete(&dev->req->base, err); + dev->busy = false; + } +@@ -368,51 +371,44 @@ exit: + } + + /* +- * Returns true if new transmitting (output) data is ready and its +- * address+length have to be written to device (by calling +- * s5p_set_dma_outdata()). False otherwise. ++ * Returns -ERRNO on error (mapping of new data failed). ++ * On success returns: ++ * - 0 if there is no more data, ++ * - 1 if new transmitting (output) data is ready and its address+length ++ * have to be written to device (by calling s5p_set_dma_outdata()). + */ +-static bool s5p_aes_tx(struct s5p_aes_dev *dev) ++static int s5p_aes_tx(struct s5p_aes_dev *dev) + { +- int err = 0; +- bool ret = false; ++ int ret = 0; + + s5p_unset_outdata(dev); + + if (!sg_is_last(dev->sg_dst)) { +- err = s5p_set_outdata(dev, sg_next(dev->sg_dst)); +- if (err) +- s5p_aes_complete(dev, err); +- else +- ret = true; +- } else { +- s5p_aes_complete(dev, err); +- +- dev->busy = true; +- tasklet_schedule(&dev->tasklet); ++ ret = s5p_set_outdata(dev, sg_next(dev->sg_dst)); ++ if (!ret) ++ ret = 1; + } + + return ret; + } + + /* +- * Returns true if new receiving (input) data is ready and its +- * address+length have to be written to device (by calling +- * s5p_set_dma_indata()). False otherwise. ++ * Returns -ERRNO on error (mapping of new data failed). ++ * On success returns: ++ * - 0 if there is no more data, ++ * - 1 if new receiving (input) data is ready and its address+length ++ * have to be written to device (by calling s5p_set_dma_indata()). + */ +-static bool s5p_aes_rx(struct s5p_aes_dev *dev) ++static int s5p_aes_rx(struct s5p_aes_dev *dev/*, bool *set_dma*/) + { +- int err; +- bool ret = false; ++ int ret = 0; + + s5p_unset_indata(dev); + + if (!sg_is_last(dev->sg_src)) { +- err = s5p_set_indata(dev, sg_next(dev->sg_src)); +- if (err) +- s5p_aes_complete(dev, err); +- else +- ret = true; ++ ret = s5p_set_indata(dev, sg_next(dev->sg_src)); ++ if (!ret) ++ ret = 1; + } + + return ret; +@@ -422,33 +418,73 @@ static irqreturn_t s5p_aes_interrupt(int + { + struct platform_device *pdev = dev_id; + struct s5p_aes_dev *dev = platform_get_drvdata(pdev); +- bool set_dma_tx = false; +- bool set_dma_rx = false; ++ int err_dma_tx = 0; ++ int err_dma_rx = 0; ++ bool tx_end = false; + unsigned long flags; + uint32_t status; ++ int err; + + spin_lock_irqsave(&dev->lock, flags); + ++ /* ++ * Handle rx or tx interrupt. If there is still data (scatterlist did not ++ * reach end), then map next scatterlist entry. ++ * In case of such mapping error, s5p_aes_complete() should be called. ++ * ++ * If there is no more data in tx scatter list, call s5p_aes_complete() ++ * and schedule new tasklet. ++ */ + status = SSS_READ(dev, FCINTSTAT); + if (status & SSS_FCINTSTAT_BRDMAINT) +- set_dma_rx = s5p_aes_rx(dev); +- if (status & SSS_FCINTSTAT_BTDMAINT) +- set_dma_tx = s5p_aes_tx(dev); ++ err_dma_rx = s5p_aes_rx(dev); ++ ++ if (status & SSS_FCINTSTAT_BTDMAINT) { ++ if (sg_is_last(dev->sg_dst)) ++ tx_end = true; ++ err_dma_tx = s5p_aes_tx(dev); ++ } + + SSS_WRITE(dev, FCINTPEND, status); + +- /* +- * Writing length of DMA block (either receiving or transmitting) +- * will start the operation immediately, so this should be done +- * at the end (even after clearing pending interrupts to not miss the +- * interrupt). +- */ +- if (set_dma_tx) +- s5p_set_dma_outdata(dev, dev->sg_dst); +- if (set_dma_rx) +- s5p_set_dma_indata(dev, dev->sg_src); ++ if (err_dma_rx < 0) { ++ err = err_dma_rx; ++ goto error; ++ } ++ if (err_dma_tx < 0) { ++ err = err_dma_tx; ++ goto error; ++ } ++ ++ if (tx_end) { ++ s5p_sg_done(dev); ++ ++ spin_unlock_irqrestore(&dev->lock, flags); ++ ++ s5p_aes_complete(dev, 0); ++ dev->busy = true; ++ tasklet_schedule(&dev->tasklet); ++ } else { ++ /* ++ * Writing length of DMA block (either receiving or ++ * transmitting) will start the operation immediately, so this ++ * should be done at the end (even after clearing pending ++ * interrupts to not miss the interrupt). ++ */ ++ if (err_dma_tx == 1) ++ s5p_set_dma_outdata(dev, dev->sg_dst); ++ if (err_dma_rx == 1) ++ s5p_set_dma_indata(dev, dev->sg_src); ++ ++ spin_unlock_irqrestore(&dev->lock, flags); ++ } ++ ++ return IRQ_HANDLED; + ++error: ++ s5p_sg_done(dev); + spin_unlock_irqrestore(&dev->lock, flags); ++ s5p_aes_complete(dev, err); + + return IRQ_HANDLED; + } +@@ -597,8 +633,9 @@ outdata_error: + s5p_unset_indata(dev); + + indata_error: +- s5p_aes_complete(dev, err); ++ s5p_sg_done(dev); + spin_unlock_irqrestore(&dev->lock, flags); ++ s5p_aes_complete(dev, err); + } + + static void s5p_tasklet_cb(unsigned long data) diff --git a/queue-4.10/futex-add-missing-error-handling-to-futex_requeue_pi.patch b/queue-4.10/futex-add-missing-error-handling-to-futex_requeue_pi.patch new file mode 100644 index 00000000000..1aaea57cdcc --- /dev/null +++ b/queue-4.10/futex-add-missing-error-handling-to-futex_requeue_pi.patch @@ -0,0 +1,42 @@ +From 9bbb25afeb182502ca4f2c4f3f88af0681b34cae Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Sat, 4 Mar 2017 10:27:19 +0100 +Subject: futex: Add missing error handling to FUTEX_REQUEUE_PI + +From: Peter Zijlstra + +commit 9bbb25afeb182502ca4f2c4f3f88af0681b34cae upstream. + +Thomas spotted that fixup_pi_state_owner() can return errors and we +fail to unlock the rt_mutex in that case. + +Reported-by: Thomas Gleixner +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Darren Hart +Cc: juri.lelli@arm.com +Cc: bigeasy@linutronix.de +Cc: xlpang@redhat.com +Cc: rostedt@goodmis.org +Cc: mathieu.desnoyers@efficios.com +Cc: jdesfossez@efficios.com +Cc: dvhart@infradead.org +Cc: bristot@redhat.com +Link: http://lkml.kernel.org/r/20170304093558.867401760@infradead.org +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/futex.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/kernel/futex.c ++++ b/kernel/futex.c +@@ -2896,6 +2896,8 @@ static int futex_wait_requeue_pi(u32 __u + if (q.pi_state && (q.pi_state->owner != current)) { + spin_lock(q.lock_ptr); + ret = fixup_pi_state_owner(uaddr2, &q, current); ++ if (ret && rt_mutex_owner(&q.pi_state->pi_mutex) == current) ++ rt_mutex_unlock(&q.pi_state->pi_mutex); + /* + * Drop the reference to the pi state which + * the requeue_pi() code acquired for us. diff --git a/queue-4.10/futex-fix-potential-use-after-free-in-futex_requeue_pi.patch b/queue-4.10/futex-fix-potential-use-after-free-in-futex_requeue_pi.patch new file mode 100644 index 00000000000..c63e2ec0f8a --- /dev/null +++ b/queue-4.10/futex-fix-potential-use-after-free-in-futex_requeue_pi.patch @@ -0,0 +1,85 @@ +From c236c8e95a3d395b0494e7108f0d41cf36ec107c Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Sat, 4 Mar 2017 10:27:18 +0100 +Subject: futex: Fix potential use-after-free in FUTEX_REQUEUE_PI + +From: Peter Zijlstra + +commit c236c8e95a3d395b0494e7108f0d41cf36ec107c upstream. + +While working on the futex code, I stumbled over this potential +use-after-free scenario. Dmitry triggered it later with syzkaller. + +pi_mutex is a pointer into pi_state, which we drop the reference on in +unqueue_me_pi(). So any access to that pointer after that is bad. + +Since other sites already do rt_mutex_unlock() with hb->lock held, see +for example futex_lock_pi(), simply move the unlock before +unqueue_me_pi(). + +Reported-by: Dmitry Vyukov +Signed-off-by: Peter Zijlstra (Intel) +Reviewed-by: Darren Hart +Cc: juri.lelli@arm.com +Cc: bigeasy@linutronix.de +Cc: xlpang@redhat.com +Cc: rostedt@goodmis.org +Cc: mathieu.desnoyers@efficios.com +Cc: jdesfossez@efficios.com +Cc: dvhart@infradead.org +Cc: bristot@redhat.com +Link: http://lkml.kernel.org/r/20170304093558.801744246@infradead.org +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/futex.c | 20 +++++++++++--------- + 1 file changed, 11 insertions(+), 9 deletions(-) + +--- a/kernel/futex.c ++++ b/kernel/futex.c +@@ -2813,7 +2813,6 @@ static int futex_wait_requeue_pi(u32 __u + { + struct hrtimer_sleeper timeout, *to = NULL; + struct rt_mutex_waiter rt_waiter; +- struct rt_mutex *pi_mutex = NULL; + struct futex_hash_bucket *hb; + union futex_key key2 = FUTEX_KEY_INIT; + struct futex_q q = futex_q_init; +@@ -2905,6 +2904,8 @@ static int futex_wait_requeue_pi(u32 __u + spin_unlock(q.lock_ptr); + } + } else { ++ struct rt_mutex *pi_mutex; ++ + /* + * We have been woken up by futex_unlock_pi(), a timeout, or a + * signal. futex_unlock_pi() will not destroy the lock_ptr nor +@@ -2928,18 +2929,19 @@ static int futex_wait_requeue_pi(u32 __u + if (res) + ret = (res < 0) ? res : 0; + ++ /* ++ * If fixup_pi_state_owner() faulted and was unable to handle ++ * the fault, unlock the rt_mutex and return the fault to ++ * userspace. ++ */ ++ if (ret && rt_mutex_owner(pi_mutex) == current) ++ rt_mutex_unlock(pi_mutex); ++ + /* Unqueue and drop the lock. */ + unqueue_me_pi(&q); + } + +- /* +- * If fixup_pi_state_owner() faulted and was unable to handle the +- * fault, unlock the rt_mutex and return the fault to userspace. +- */ +- if (ret == -EFAULT) { +- if (pi_mutex && rt_mutex_owner(pi_mutex) == current) +- rt_mutex_unlock(pi_mutex); +- } else if (ret == -EINTR) { ++ if (ret == -EINTR) { + /* + * We've already been requeued, but cannot restart by calling + * futex_lock_pi() directly. We could restart this syscall, but diff --git a/queue-4.10/locking-rwsem-fix-down_write_killable-for-config_rwsem_generic_spinlock-y.patch b/queue-4.10/locking-rwsem-fix-down_write_killable-for-config_rwsem_generic_spinlock-y.patch new file mode 100644 index 00000000000..a557b437bc4 --- /dev/null +++ b/queue-4.10/locking-rwsem-fix-down_write_killable-for-config_rwsem_generic_spinlock-y.patch @@ -0,0 +1,85 @@ +From 17fcbd590d0c3e35bd9646e2215f86586378bc42 Mon Sep 17 00:00:00 2001 +From: Niklas Cassel +Date: Sat, 25 Feb 2017 01:17:53 +0100 +Subject: locking/rwsem: Fix down_write_killable() for CONFIG_RWSEM_GENERIC_SPINLOCK=y + +From: Niklas Cassel + +commit 17fcbd590d0c3e35bd9646e2215f86586378bc42 upstream. + +We hang if SIGKILL has been sent, but the task is stuck in down_read() +(after do_exit()), even though no task is doing down_write() on the +rwsem in question: + + INFO: task libupnp:21868 blocked for more than 120 seconds. + libupnp D 0 21868 1 0x08100008 + ... + Call Trace: + __schedule() + schedule() + __down_read() + do_exit() + do_group_exit() + __wake_up_parent() + +This bug has already been fixed for CONFIG_RWSEM_XCHGADD_ALGORITHM=y in +the following commit: + + 04cafed7fc19 ("locking/rwsem: Fix down_write_killable()") + +... however, this bug also exists for CONFIG_RWSEM_GENERIC_SPINLOCK=y. + +Signed-off-by: Niklas Cassel +Signed-off-by: Peter Zijlstra (Intel) +Cc: +Cc: Andrew Morton +Cc: Linus Torvalds +Cc: Niklas Cassel +Cc: Paul E. McKenney +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Fixes: d47996082f52 ("locking/rwsem: Introduce basis for down_write_killable()") +Link: http://lkml.kernel.org/r/1487981873-12649-1-git-send-email-niklass@axis.com +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/locking/rwsem-spinlock.c | 15 ++++++++++----- + 1 file changed, 10 insertions(+), 5 deletions(-) + +--- a/kernel/locking/rwsem-spinlock.c ++++ b/kernel/locking/rwsem-spinlock.c +@@ -216,10 +216,8 @@ int __sched __down_write_common(struct r + */ + if (sem->count == 0) + break; +- if (signal_pending_state(state, current)) { +- ret = -EINTR; +- goto out; +- } ++ if (signal_pending_state(state, current)) ++ goto out_nolock; + set_task_state(tsk, state); + raw_spin_unlock_irqrestore(&sem->wait_lock, flags); + schedule(); +@@ -227,12 +225,19 @@ int __sched __down_write_common(struct r + } + /* got the lock */ + sem->count = -1; +-out: + list_del(&waiter.list); + + raw_spin_unlock_irqrestore(&sem->wait_lock, flags); + + return ret; ++ ++out_nolock: ++ list_del(&waiter.list); ++ if (!list_empty(&sem->wait_list)) ++ __rwsem_do_wake(sem, 1); ++ raw_spin_unlock_irqrestore(&sem->wait_lock, flags); ++ ++ return -EINTR; + } + + void __sched __down_write(struct rw_semaphore *sem) diff --git a/queue-4.10/series b/queue-4.10/series index c3a9ada4821..c3c979aaaa8 100644 --- a/queue-4.10/series +++ b/queue-4.10/series @@ -51,3 +51,13 @@ irqchip-gicv3-its-add-workaround-for-qdf2400-its-erratum-0065.patch drm-i915-lspcon-enable-aux-interrupts-for-resume-time-initialization.patch drm-i915-gen9-enable-hotplug-detection-early.patch drm-i915-lspcon-fix-resume-time-initialization-due-to-unasserted-hpd.patch +x86-unwind-fix-last-frame-check-for-aligned-function-stacks.patch +x86-tsc-fix-art-for-tsc_known_freq.patch +x86-kasan-fix-boot-with-kasan-y-and-profile_annotated_branches-y.patch +x86-intel_rdt-put-group-node-in-rdtgroup_kn_unlock.patch +x86-perf-fix-cr4.pce-propagation-to-use-active_mm-instead-of-mm.patch +futex-fix-potential-use-after-free-in-futex_requeue_pi.patch +futex-add-missing-error-handling-to-futex_requeue_pi.patch +locking-rwsem-fix-down_write_killable-for-config_rwsem_generic_spinlock-y.patch +crypto-powerpc-fix-initialisation-of-crc32c-context.patch +crypto-s5p-sss-fix-spinlock-recursion-on-lrw-aes.patch diff --git a/queue-4.10/x86-intel_rdt-put-group-node-in-rdtgroup_kn_unlock.patch b/queue-4.10/x86-intel_rdt-put-group-node-in-rdtgroup_kn_unlock.patch new file mode 100644 index 00000000000..be070b0d431 --- /dev/null +++ b/queue-4.10/x86-intel_rdt-put-group-node-in-rdtgroup_kn_unlock.patch @@ -0,0 +1,56 @@ +From 49ec8f5b6ae3ab60385492cad900ffc8a523c895 Mon Sep 17 00:00:00 2001 +From: Jiri Olsa +Date: Tue, 14 Mar 2017 15:20:53 +0100 +Subject: x86/intel_rdt: Put group node in rdtgroup_kn_unlock + +From: Jiri Olsa + +commit 49ec8f5b6ae3ab60385492cad900ffc8a523c895 upstream. + +The rdtgroup_kn_unlock waits for the last user to release and put its +node. But it's calling kernfs_put on the node which calls the +rdtgroup_kn_unlock, which might not be the group's directory node, but +another group's file node. + +This race could be easily reproduced by running 2 instances +of following script: + + mount -t resctrl resctrl /sys/fs/resctrl/ + pushd /sys/fs/resctrl/ + mkdir krava + echo "krava" > krava/schemata + rmdir krava + popd + umount /sys/fs/resctrl + +It triggers the slub debug error message with following command +line config: slub_debug=,kernfs_node_cache. + +Call kernfs_put on the group's node to fix it. + +Fixes: 60cf5e101fd4 ("x86/intel_rdt: Add mkdir to resctrl file system") +Signed-off-by: Jiri Olsa +Cc: Fenghua Yu +Cc: Peter Zijlstra +Cc: Peter Zijlstra +Cc: Mike Galbraith +Cc: Shaohua Li +Link: http://lkml.kernel.org/r/1489501253-20248-1-git-send-email-jolsa@kernel.org +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/cpu/intel_rdt_rdtgroup.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c ++++ b/arch/x86/kernel/cpu/intel_rdt_rdtgroup.c +@@ -727,7 +727,7 @@ void rdtgroup_kn_unlock(struct kernfs_no + if (atomic_dec_and_test(&rdtgrp->waitcount) && + (rdtgrp->flags & RDT_DELETED)) { + kernfs_unbreak_active_protection(kn); +- kernfs_put(kn); ++ kernfs_put(rdtgrp->kn); + kfree(rdtgrp); + } else { + kernfs_unbreak_active_protection(kn); diff --git a/queue-4.10/x86-kasan-fix-boot-with-kasan-y-and-profile_annotated_branches-y.patch b/queue-4.10/x86-kasan-fix-boot-with-kasan-y-and-profile_annotated_branches-y.patch new file mode 100644 index 00000000000..11a6d42106f --- /dev/null +++ b/queue-4.10/x86-kasan-fix-boot-with-kasan-y-and-profile_annotated_branches-y.patch @@ -0,0 +1,52 @@ +From be3606ff739d1c1be36389f8737c577ad87e1f57 Mon Sep 17 00:00:00 2001 +From: Andrey Ryabinin +Date: Mon, 13 Mar 2017 19:33:37 +0300 +Subject: x86/kasan: Fix boot with KASAN=y and PROFILE_ANNOTATED_BRANCHES=y + +From: Andrey Ryabinin + +commit be3606ff739d1c1be36389f8737c577ad87e1f57 upstream. + +The kernel doesn't boot with both PROFILE_ANNOTATED_BRANCHES=y and KASAN=y +options selected. With branch profiling enabled we end up calling +ftrace_likely_update() before kasan_early_init(). ftrace_likely_update() is +built with KASAN instrumentation, so calling it before kasan has been +initialized leads to crash. + +Use DISABLE_BRANCH_PROFILING define to make sure that we don't call +ftrace_likely_update() from early code before kasan_early_init(). + +Fixes: ef7f0d6a6ca8 ("x86_64: add KASan support") +Reported-by: Fengguang Wu +Signed-off-by: Andrey Ryabinin +Cc: kasan-dev@googlegroups.com +Cc: Alexander Potapenko +Cc: Andrew Morton +Cc: lkp@01.org +Cc: Dmitry Vyukov +Link: http://lkml.kernel.org/r/20170313163337.1704-1-aryabinin@virtuozzo.com +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/head64.c | 1 + + arch/x86/mm/kasan_init_64.c | 1 + + 2 files changed, 2 insertions(+) + +--- a/arch/x86/kernel/head64.c ++++ b/arch/x86/kernel/head64.c +@@ -4,6 +4,7 @@ + * Copyright (C) 2000 Andrea Arcangeli SuSE + */ + ++#define DISABLE_BRANCH_PROFILING + #include + #include + #include +--- a/arch/x86/mm/kasan_init_64.c ++++ b/arch/x86/mm/kasan_init_64.c +@@ -1,3 +1,4 @@ ++#define DISABLE_BRANCH_PROFILING + #define pr_fmt(fmt) "kasan: " fmt + #include + #include diff --git a/queue-4.10/x86-perf-fix-cr4.pce-propagation-to-use-active_mm-instead-of-mm.patch b/queue-4.10/x86-perf-fix-cr4.pce-propagation-to-use-active_mm-instead-of-mm.patch new file mode 100644 index 00000000000..1538afa7bac --- /dev/null +++ b/queue-4.10/x86-perf-fix-cr4.pce-propagation-to-use-active_mm-instead-of-mm.patch @@ -0,0 +1,47 @@ +From 5dc855d44c2ad960a86f593c60461f1ae1566b6d Mon Sep 17 00:00:00 2001 +From: Andy Lutomirski +Date: Thu, 16 Mar 2017 12:59:39 -0700 +Subject: x86/perf: Fix CR4.PCE propagation to use active_mm instead of mm + +From: Andy Lutomirski + +commit 5dc855d44c2ad960a86f593c60461f1ae1566b6d upstream. + +If one thread mmaps a perf event while another thread in the same mm +is in some context where active_mm != mm (which can happen in the +scheduler, for example), refresh_pce() would write the wrong value +to CR4.PCE. This broke some PAPI tests. + +Reported-and-tested-by: Vince Weaver +Signed-off-by: Andy Lutomirski +Cc: Alexander Shishkin +Cc: Arnaldo Carvalho de Melo +Cc: Borislav Petkov +Cc: H. Peter Anvin +Cc: Jiri Olsa +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Stephane Eranian +Cc: Thomas Gleixner +Fixes: 7911d3f7af14 ("perf/x86: Only allow rdpmc if a perf_event is mapped") +Link: http://lkml.kernel.org/r/0c5b38a76ea50e405f9abe07a13dfaef87c173a1.1489694270.git.luto@kernel.org +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/events/core.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/arch/x86/events/core.c ++++ b/arch/x86/events/core.c +@@ -2100,8 +2100,8 @@ static int x86_pmu_event_init(struct per + + static void refresh_pce(void *ignored) + { +- if (current->mm) +- load_mm_cr4(current->mm); ++ if (current->active_mm) ++ load_mm_cr4(current->active_mm); + } + + static void x86_pmu_event_mapped(struct perf_event *event) diff --git a/queue-4.10/x86-tsc-fix-art-for-tsc_known_freq.patch b/queue-4.10/x86-tsc-fix-art-for-tsc_known_freq.patch new file mode 100644 index 00000000000..1c7aefd19a9 --- /dev/null +++ b/queue-4.10/x86-tsc-fix-art-for-tsc_known_freq.patch @@ -0,0 +1,56 @@ +From 44fee88cea43d3c2cac962e0439cb10a3cabff6d Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Mon, 13 Mar 2017 15:57:12 +0100 +Subject: x86/tsc: Fix ART for TSC_KNOWN_FREQ + +From: Peter Zijlstra + +commit 44fee88cea43d3c2cac962e0439cb10a3cabff6d upstream. + +Subhransu reported that convert_art_to_tsc() isn't working for him. + +The ART to TSC relation is only set up for systems which use the refined +TSC calibration. Systems with known TSC frequency (available via CPUID 15) +are not using the refined calibration and therefor the ART to TSC relation +is never established. + +Add the setup to the known frequency init path which skips ART +calibration. The init code needs to be duplicated as for systems which use +refined calibration the ART setup must be delayed until calibration has +been done. + +The problem has been there since the ART support was introdduced, but only +detected now because Subhransu tested the first time on hardware which has +TSC frequency enumerated via CPUID 15. + +Note for stable: The conditional has changed from TSC_RELIABLE to + TSC_KNOWN_FREQUENCY. + +[ tglx: Rewrote changelog and identified the proper 'Fixes' commit ] + +Fixes: f9677e0f8308 ("x86/tsc: Always Running Timer (ART) correlated clocksource") +Reported-by: "Prusty, Subhransu S" +Signed-off-by: Peter Zijlstra (Intel) +Cc: christopher.s.hall@intel.com +Cc: kevin.b.stanton@intel.com +Cc: john.stultz@linaro.org +Cc: akataria@vmware.com +Link: http://lkml.kernel.org/r/20170313145712.GI3312@twins.programming.kicks-ass.net +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/tsc.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/arch/x86/kernel/tsc.c ++++ b/arch/x86/kernel/tsc.c +@@ -1310,6 +1310,8 @@ static int __init init_tsc_clocksource(v + * the refined calibration and directly register it as a clocksource. + */ + if (boot_cpu_has(X86_FEATURE_TSC_KNOWN_FREQ)) { ++ if (boot_cpu_has(X86_FEATURE_ART)) ++ art_related_clocksource = &clocksource_tsc; + clocksource_register_khz(&clocksource_tsc, tsc_khz); + return 0; + } diff --git a/queue-4.10/x86-unwind-fix-last-frame-check-for-aligned-function-stacks.patch b/queue-4.10/x86-unwind-fix-last-frame-check-for-aligned-function-stacks.patch new file mode 100644 index 00000000000..7f31dbf208c --- /dev/null +++ b/queue-4.10/x86-unwind-fix-last-frame-check-for-aligned-function-stacks.patch @@ -0,0 +1,92 @@ +From 87a6b2975f0d340c75b7488d22d61d2f98fb8abf Mon Sep 17 00:00:00 2001 +From: Josh Poimboeuf +Date: Mon, 13 Mar 2017 23:27:47 -0500 +Subject: x86/unwind: Fix last frame check for aligned function stacks + +From: Josh Poimboeuf + +commit 87a6b2975f0d340c75b7488d22d61d2f98fb8abf upstream. + +Pavel Machek reported the following warning on x86-32: + + WARNING: kernel stack frame pointer at f50cdf98 in swapper/2:0 has bad value (null) + +The warning is caused by the unwinder not realizing that it reached the +end of the stack, due to an unusual prologue which gcc sometimes +generates for aligned stacks. The prologue is based on a gcc feature +called the Dynamic Realign Argument Pointer (DRAP). It's almost always +enabled for aligned stacks when -maccumulate-outgoing-args isn't set. + +This issue is similar to the one fixed by the following commit: + + 8023e0e2a48d ("x86/unwind: Adjust last frame check for aligned function stacks") + +... but that fix was specific to x86-64. + +Make the fix more generic to cover x86-32 as well, and also ensure that +the return address referred to by the frame pointer is a copy of the +original return address. + +Fixes: acb4608ad186 ("x86/unwind: Create stack frames for saved syscall registers") +Reported-by: Pavel Machek +Signed-off-by: Josh Poimboeuf +Link: http://lkml.kernel.org/r/50d4924db716c264b14f1633037385ec80bf89d2.1489465609.git.jpoimboe@redhat.com +Signed-off-by: Thomas Gleixner +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/unwind_frame.c | 36 ++++++++++++++++++++++++++++++------ + 1 file changed, 30 insertions(+), 6 deletions(-) + +--- a/arch/x86/kernel/unwind_frame.c ++++ b/arch/x86/kernel/unwind_frame.c +@@ -80,19 +80,43 @@ static size_t regs_size(struct pt_regs * + return sizeof(*regs); + } + ++#ifdef CONFIG_X86_32 ++#define GCC_REALIGN_WORDS 3 ++#else ++#define GCC_REALIGN_WORDS 1 ++#endif ++ + static bool is_last_task_frame(struct unwind_state *state) + { +- unsigned long bp = (unsigned long)state->bp; +- unsigned long regs = (unsigned long)task_pt_regs(state->task); ++ unsigned long *last_bp = (unsigned long *)task_pt_regs(state->task) - 2; ++ unsigned long *aligned_bp = last_bp - GCC_REALIGN_WORDS; + + /* + * We have to check for the last task frame at two different locations + * because gcc can occasionally decide to realign the stack pointer and +- * change the offset of the stack frame by a word in the prologue of a +- * function called by head/entry code. ++ * change the offset of the stack frame in the prologue of a function ++ * called by head/entry code. Examples: ++ * ++ * : ++ * push %edi ++ * lea 0x8(%esp),%edi ++ * and $0xfffffff8,%esp ++ * pushl -0x4(%edi) ++ * push %ebp ++ * mov %esp,%ebp ++ * ++ * : ++ * lea 0x8(%rsp),%r10 ++ * and $0xfffffffffffffff0,%rsp ++ * pushq -0x8(%r10) ++ * push %rbp ++ * mov %rsp,%rbp ++ * ++ * Note that after aligning the stack, it pushes a duplicate copy of ++ * the return address before pushing the frame pointer. + */ +- return bp == regs - FRAME_HEADER_SIZE || +- bp == regs - FRAME_HEADER_SIZE - sizeof(long); ++ return (state->bp == last_bp || ++ (state->bp == aligned_bp && *(aligned_bp+1) == *(last_bp+1))); + } + + /*