--- /dev/null
+From f659b10087daaf4ce0087c3f6aec16746be9628f Mon Sep 17 00:00:00 2001
+From: Rabin Vincent <rabinv@axis.com>
+Date: Wed, 21 Sep 2016 16:22:29 +0200
+Subject: dm crypt: fix crash on exit
+
+From: Rabin Vincent <rabinv@axis.com>
+
+commit f659b10087daaf4ce0087c3f6aec16746be9628f upstream.
+
+As the documentation for kthread_stop() says, "if threadfn() may call
+do_exit() itself, the caller must ensure task_struct can't go away".
+dm-crypt does not ensure this and therefore crashes when crypt_dtr()
+calls kthread_stop(). The crash is trivially reproducible by adding a
+delay before the call to kthread_stop() and just opening and closing a
+dm-crypt device.
+
+ general protection fault: 0000 [#1] PREEMPT SMP
+ CPU: 0 PID: 533 Comm: cryptsetup Not tainted 4.8.0-rc7+ #7
+ task: ffff88003bd0df40 task.stack: ffff8800375b4000
+ RIP: 0010: kthread_stop+0x52/0x300
+ Call Trace:
+ crypt_dtr+0x77/0x120
+ dm_table_destroy+0x6f/0x120
+ __dm_destroy+0x130/0x250
+ dm_destroy+0x13/0x20
+ dev_remove+0xe6/0x120
+ ? dev_suspend+0x250/0x250
+ ctl_ioctl+0x1fc/0x530
+ ? __lock_acquire+0x24f/0x1b10
+ dm_ctl_ioctl+0x13/0x20
+ do_vfs_ioctl+0x91/0x6a0
+ ? ____fput+0xe/0x10
+ ? entry_SYSCALL_64_fastpath+0x5/0xbd
+ ? trace_hardirqs_on_caller+0x151/0x1e0
+ SyS_ioctl+0x41/0x70
+ entry_SYSCALL_64_fastpath+0x1f/0xbd
+
+This problem was introduced by bcbd94ff481e ("dm crypt: fix a possible
+hang due to race condition on exit").
+
+Looking at the description of that patch (excerpted below), it seems
+like the problem it addresses can be solved by just using
+set_current_state instead of __set_current_state, since we obviously
+need the memory barrier.
+
+| dm crypt: fix a possible hang due to race condition on exit
+|
+| A kernel thread executes __set_current_state(TASK_INTERRUPTIBLE),
+| __add_wait_queue, spin_unlock_irq and then tests kthread_should_stop().
+| It is possible that the processor reorders memory accesses so that
+| kthread_should_stop() is executed before __set_current_state(). If
+| such reordering happens, there is a possible race on thread
+| termination: [...]
+
+So this patch just reverts the aforementioned patch and changes the
+__set_current_state(TASK_INTERRUPTIBLE) to set_current_state(...). This
+fixes the crash and should also fix the potential hang.
+
+Fixes: bcbd94ff481e ("dm crypt: fix a possible hang due to race condition on exit")
+Cc: Mikulas Patocka <mpatocka@redhat.com>
+Signed-off-by: Rabin Vincent <rabinv@axis.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-crypt.c | 24 ++++++++++--------------
+ 1 file changed, 10 insertions(+), 14 deletions(-)
+
+--- a/drivers/md/dm-crypt.c
++++ b/drivers/md/dm-crypt.c
+@@ -112,8 +112,7 @@ struct iv_tcw_private {
+ * and encrypts / decrypts at the same time.
+ */
+ enum flags { DM_CRYPT_SUSPENDED, DM_CRYPT_KEY_VALID,
+- DM_CRYPT_SAME_CPU, DM_CRYPT_NO_OFFLOAD,
+- DM_CRYPT_EXIT_THREAD};
++ DM_CRYPT_SAME_CPU, DM_CRYPT_NO_OFFLOAD };
+
+ /*
+ * The fields in here must be read only after initialization.
+@@ -1204,18 +1203,20 @@ continue_locked:
+ if (!RB_EMPTY_ROOT(&cc->write_tree))
+ goto pop_from_list;
+
+- if (unlikely(test_bit(DM_CRYPT_EXIT_THREAD, &cc->flags))) {
+- spin_unlock_irq(&cc->write_thread_wait.lock);
+- break;
+- }
+-
+- __set_current_state(TASK_INTERRUPTIBLE);
++ set_current_state(TASK_INTERRUPTIBLE);
+ __add_wait_queue(&cc->write_thread_wait, &wait);
+
+ spin_unlock_irq(&cc->write_thread_wait.lock);
+
++ if (unlikely(kthread_should_stop())) {
++ set_task_state(current, TASK_RUNNING);
++ remove_wait_queue(&cc->write_thread_wait, &wait);
++ break;
++ }
++
+ schedule();
+
++ set_task_state(current, TASK_RUNNING);
+ spin_lock_irq(&cc->write_thread_wait.lock);
+ __remove_wait_queue(&cc->write_thread_wait, &wait);
+ goto continue_locked;
+@@ -1530,13 +1531,8 @@ static void crypt_dtr(struct dm_target *
+ if (!cc)
+ return;
+
+- if (cc->write_thread) {
+- spin_lock_irq(&cc->write_thread_wait.lock);
+- set_bit(DM_CRYPT_EXIT_THREAD, &cc->flags);
+- wake_up_locked(&cc->write_thread_wait);
+- spin_unlock_irq(&cc->write_thread_wait.lock);
++ if (cc->write_thread)
+ kthread_stop(cc->write_thread);
+- }
+
+ if (cc->io_queue)
+ destroy_workqueue(cc->io_queue);
--- /dev/null
+From 3b785fbcf81c3533772c52b717f77293099498d3 Mon Sep 17 00:00:00 2001
+From: Bart Van Assche <bart.vanassche@sandisk.com>
+Date: Wed, 31 Aug 2016 15:17:49 -0700
+Subject: dm: mark request_queue dead before destroying the DM device
+
+From: Bart Van Assche <bart.vanassche@sandisk.com>
+
+commit 3b785fbcf81c3533772c52b717f77293099498d3 upstream.
+
+This avoids that new requests are queued while __dm_destroy() is in
+progress.
+
+Signed-off-by: Bart Van Assche <bart.vanassche@sandisk.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/md/dm.c
++++ b/drivers/md/dm.c
+@@ -2869,6 +2869,7 @@ EXPORT_SYMBOL_GPL(dm_device_name);
+
+ static void __dm_destroy(struct mapped_device *md, bool wait)
+ {
++ struct request_queue *q = dm_get_md_queue(md);
+ struct dm_table *map;
+ int srcu_idx;
+
+@@ -2879,6 +2880,10 @@ static void __dm_destroy(struct mapped_d
+ set_bit(DMF_FREEING, &md->flags);
+ spin_unlock(&_minor_lock);
+
++ spin_lock_irq(q->queue_lock);
++ queue_flag_set(QUEUE_FLAG_DYING, q);
++ spin_unlock_irq(q->queue_lock);
++
+ if (dm_request_based(md) && md->kworker_task)
+ flush_kthread_worker(&md->kworker);
+
--- /dev/null
+From f10e06b744074824fb8ec7066bc03ecc90918f5b Mon Sep 17 00:00:00 2001
+From: Mike Snitzer <snitzer@redhat.com>
+Date: Thu, 1 Sep 2016 12:06:37 -0400
+Subject: dm mpath: check if path's request_queue is dying in activate_path()
+
+From: Mike Snitzer <snitzer@redhat.com>
+
+commit f10e06b744074824fb8ec7066bc03ecc90918f5b upstream.
+
+If pg_init_retries is set and a request is queued against a multipath
+device with all underlying block device request_queues in the "dying"
+state then an infinite loop is triggered because activate_path() never
+succeeds and hence never calls pg_init_done().
+
+This change avoids that device removal triggers an infinite loop by
+failing the activate_path() which causes the "dying" path to be failed.
+
+Reported-by: Bart Van Assche <bart.vanassche@sandisk.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm-mpath.c | 6 +++---
+ 1 file changed, 3 insertions(+), 3 deletions(-)
+
+--- a/drivers/md/dm-mpath.c
++++ b/drivers/md/dm-mpath.c
+@@ -1220,10 +1220,10 @@ static void activate_path(struct work_st
+ {
+ struct pgpath *pgpath =
+ container_of(work, struct pgpath, activate_path.work);
++ struct request_queue *q = bdev_get_queue(pgpath->path.dev->bdev);
+
+- if (pgpath->is_active)
+- scsi_dh_activate(bdev_get_queue(pgpath->path.dev->bdev),
+- pg_init_done, pgpath);
++ if (pgpath->is_active && !blk_queue_dying(q))
++ scsi_dh_activate(q, pg_init_done, pgpath);
+ else
+ pg_init_done(pgpath, SCSI_DH_DEV_OFFLINED);
+ }
--- /dev/null
+From 8dc23658b7aaa8b6b0609c81c8ad75e98b612801 Mon Sep 17 00:00:00 2001
+From: Minfei Huang <mnghuan@gmail.com>
+Date: Tue, 6 Sep 2016 16:00:29 +0800
+Subject: dm: return correct error code in dm_resume()'s retry loop
+
+From: Minfei Huang <mnghuan@gmail.com>
+
+commit 8dc23658b7aaa8b6b0609c81c8ad75e98b612801 upstream.
+
+dm_resume() will return success (0) rather than -EINVAL if
+!dm_suspended_md() upon retry within dm_resume().
+
+Reset the error code at the start of dm_resume()'s retry loop.
+Also, remove a useless assignment at the end of dm_resume().
+
+Fixes: ffcc393641 ("dm: enhance internal suspend and resume interface")
+Signed-off-by: Minfei Huang <mnghuan@gmail.com>
+Signed-off-by: Mike Snitzer <snitzer@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/md/dm.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/drivers/md/dm.c
++++ b/drivers/md/dm.c
+@@ -3250,10 +3250,11 @@ static int __dm_resume(struct mapped_dev
+
+ int dm_resume(struct mapped_device *md)
+ {
+- int r = -EINVAL;
++ int r;
+ struct dm_table *map = NULL;
+
+ retry:
++ r = -EINVAL;
+ mutex_lock_nested(&md->suspend_lock, SINGLE_DEPTH_NESTING);
+
+ if (!dm_suspended_md(md))
+@@ -3277,8 +3278,6 @@ retry:
+ goto out;
+
+ clear_bit(DMF_SUSPENDED, &md->flags);
+-
+- r = 0;
+ out:
+ mutex_unlock(&md->suspend_lock);
+
--- /dev/null
+From 51ee6481fa8e879cc942bcc1b0af713e158b7a98 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Wed, 28 Sep 2016 14:41:35 +0300
+Subject: perf intel-pt: Fix estimated timestamps for cycle-accurate mode
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit 51ee6481fa8e879cc942bcc1b0af713e158b7a98 upstream.
+
+In cycle-accurate mode, timestamps can be calculated from CYC packets.
+The decoder also estimates timestamps based on the number of
+instructions since the last timestamp. For that to work in
+cycle-accurate mode, the instruction count needs to be reset to zero
+when a timestamp is calculated from a CYC packet, but that wasn't
+happening, so fix it.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Link: http://lkml.kernel.org/r/1475062896-22274-1-git-send-email-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
++++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+@@ -1323,6 +1323,8 @@ static void intel_pt_calc_cyc_timestamp(
+ timestamp, decoder->timestamp);
+ else
+ decoder->timestamp = timestamp;
++
++ decoder->timestamp_insn_cnt = 0;
+ }
+
+ /* Walk PSB+ packets when already in sync. */
--- /dev/null
+From 3bccbe20f6d188ce7b00326e776b745cfd35b10a Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Wed, 28 Sep 2016 14:41:36 +0300
+Subject: perf intel-pt: Fix MTC timestamp calculation for large MTC periods
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit 3bccbe20f6d188ce7b00326e776b745cfd35b10a upstream.
+
+The MTC packet provides a 8-bit slice of CTC which is related to TSC by
+the TMA packet, however the TMA packet only provides the lower 16 bits
+of CTC. If mtc_shift > 8 then some of the MTC bits are not in the CTC
+provided by the TMA packet. Fix-up the last_mtc calculated from the TMA
+packet by copying the missing bits from the current MTC assuming the
+least difference between the two, and that the current MTC comes after
+last_mtc.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Link: http://lkml.kernel.org/r/1475062896-22274-2-git-send-email-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/intel-pt-decoder/intel-pt-decoder.c | 36 ++++++++++++++++++++
+ 1 file changed, 36 insertions(+)
+
+--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
++++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+@@ -89,6 +89,7 @@ struct intel_pt_decoder {
+ bool pge;
+ bool have_tma;
+ bool have_cyc;
++ bool fixup_last_mtc;
+ uint64_t pos;
+ uint64_t last_ip;
+ uint64_t ip;
+@@ -584,10 +585,31 @@ struct intel_pt_calc_cyc_to_tsc_info {
+ uint64_t tsc_timestamp;
+ uint64_t timestamp;
+ bool have_tma;
++ bool fixup_last_mtc;
+ bool from_mtc;
+ double cbr_cyc_to_tsc;
+ };
+
++/*
++ * MTC provides a 8-bit slice of CTC but the TMA packet only provides the lower
++ * 16 bits of CTC. If mtc_shift > 8 then some of the MTC bits are not in the CTC
++ * provided by the TMA packet. Fix-up the last_mtc calculated from the TMA
++ * packet by copying the missing bits from the current MTC assuming the least
++ * difference between the two, and that the current MTC comes after last_mtc.
++ */
++static void intel_pt_fixup_last_mtc(uint32_t mtc, int mtc_shift,
++ uint32_t *last_mtc)
++{
++ uint32_t first_missing_bit = 1U << (16 - mtc_shift);
++ uint32_t mask = ~(first_missing_bit - 1);
++
++ *last_mtc |= mtc & mask;
++ if (*last_mtc >= mtc) {
++ *last_mtc -= first_missing_bit;
++ *last_mtc &= 0xff;
++ }
++}
++
+ static int intel_pt_calc_cyc_cb(struct intel_pt_pkt_info *pkt_info)
+ {
+ struct intel_pt_decoder *decoder = pkt_info->decoder;
+@@ -617,6 +639,11 @@ static int intel_pt_calc_cyc_cb(struct i
+ return 0;
+
+ mtc = pkt_info->packet.payload;
++ if (decoder->mtc_shift > 8 && data->fixup_last_mtc) {
++ data->fixup_last_mtc = false;
++ intel_pt_fixup_last_mtc(mtc, decoder->mtc_shift,
++ &data->last_mtc);
++ }
+ if (mtc > data->last_mtc)
+ mtc_delta = mtc - data->last_mtc;
+ else
+@@ -685,6 +712,7 @@ static int intel_pt_calc_cyc_cb(struct i
+
+ data->ctc_delta = 0;
+ data->have_tma = true;
++ data->fixup_last_mtc = true;
+
+ return 0;
+
+@@ -751,6 +779,7 @@ static void intel_pt_calc_cyc_to_tsc(str
+ .tsc_timestamp = decoder->tsc_timestamp,
+ .timestamp = decoder->timestamp,
+ .have_tma = decoder->have_tma,
++ .fixup_last_mtc = decoder->fixup_last_mtc,
+ .from_mtc = from_mtc,
+ .cbr_cyc_to_tsc = 0,
+ };
+@@ -1241,6 +1270,7 @@ static void intel_pt_calc_tma(struct int
+ }
+ decoder->ctc_delta = 0;
+ decoder->have_tma = true;
++ decoder->fixup_last_mtc = true;
+ intel_pt_log("CTC timestamp " x64_fmt " last MTC %#x CTC rem %#x\n",
+ decoder->ctc_timestamp, decoder->last_mtc, ctc_rem);
+ }
+@@ -1255,6 +1285,12 @@ static void intel_pt_calc_mtc_timestamp(
+
+ mtc = decoder->packet.payload;
+
++ if (decoder->mtc_shift > 8 && decoder->fixup_last_mtc) {
++ decoder->fixup_last_mtc = false;
++ intel_pt_fixup_last_mtc(mtc, decoder->mtc_shift,
++ &decoder->last_mtc);
++ }
++
+ if (mtc > decoder->last_mtc)
+ mtc_delta = mtc - decoder->last_mtc;
+ else
--- /dev/null
+From 810c398bc09b2f2dfde52a7d2483a710612c5fb8 Mon Sep 17 00:00:00 2001
+From: Adrian Hunter <adrian.hunter@intel.com>
+Date: Fri, 23 Sep 2016 17:38:41 +0300
+Subject: perf intel-pt: Fix snapshot overlap detection decoder errors
+
+From: Adrian Hunter <adrian.hunter@intel.com>
+
+commit 810c398bc09b2f2dfde52a7d2483a710612c5fb8 upstream.
+
+Fix occasional decoder errors decoding trace data collected in snapshot
+mode.
+
+Snapshot mode can take successive snapshots of trace which might overlap.
+The decoder checks whether there is an overlap but only looks at the
+current and previous buffer. However buffers that do not contain
+synchronization (i.e. PSB) packets cannot be decoded or used for overlap
+checking. That means the decoder actually needs to check overlaps between
+the current buffer and the previous buffer that contained usable data.
+Make that change.
+
+Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
+Cc: Jiri Olsa <jolsa@redhat.com>
+Cc: Masami Hiramatsu <mhiramat@kernel.org>
+Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
+Link: http://lkml.kernel.org/r/1474641528-18776-10-git-send-email-adrian.hunter@intel.com
+Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ tools/perf/util/intel-pt.c | 15 +++++++++++----
+ 1 file changed, 11 insertions(+), 4 deletions(-)
+
+--- a/tools/perf/util/intel-pt.c
++++ b/tools/perf/util/intel-pt.c
+@@ -238,7 +238,7 @@ static int intel_pt_get_trace(struct int
+ }
+
+ queue = &ptq->pt->queues.queue_array[ptq->queue_nr];
+-
++next:
+ buffer = auxtrace_buffer__next(queue, buffer);
+ if (!buffer) {
+ if (old_buffer)
+@@ -261,9 +261,6 @@ static int intel_pt_get_trace(struct int
+ intel_pt_do_fix_overlap(ptq->pt, old_buffer, buffer))
+ return -ENOMEM;
+
+- if (old_buffer)
+- auxtrace_buffer__drop_data(old_buffer);
+-
+ if (buffer->use_data) {
+ b->len = buffer->use_size;
+ b->buf = buffer->use_data;
+@@ -273,6 +270,16 @@ static int intel_pt_get_trace(struct int
+ }
+ b->ref_timestamp = buffer->reference;
+
++ /*
++ * If in snapshot mode and the buffer has no usable data, get next
++ * buffer and again check overlap against old_buffer.
++ */
++ if (ptq->pt->snapshot_mode && !b->len)
++ goto next;
++
++ if (old_buffer)
++ auxtrace_buffer__drop_data(old_buffer);
++
+ if (!old_buffer || ptq->pt->sampling_mode || (ptq->pt->snapshot_mode &&
+ !buffer->consecutive)) {
+ b->consecutive = false;
--- /dev/null
+From 1a34439e5a0b2235e43f96816dbb15ee1154f656 Mon Sep 17 00:00:00 2001
+From: Paul Mackerras <paulus@ozlabs.org>
+Date: Tue, 11 Oct 2016 22:25:47 +1100
+Subject: powerpc/64: Fix incorrect return value from __copy_tofrom_user
+
+From: Paul Mackerras <paulus@ozlabs.org>
+
+commit 1a34439e5a0b2235e43f96816dbb15ee1154f656 upstream.
+
+Debugging a data corruption issue with virtio-net/vhost-net led to
+the observation that __copy_tofrom_user was occasionally returning
+a value 16 larger than it should. Since the return value from
+__copy_tofrom_user is the number of bytes not copied, this means
+that __copy_tofrom_user can occasionally return a value larger
+than the number of bytes it was asked to copy. In turn this can
+cause higher-level copy functions such as copy_page_to_iter_iovec
+to corrupt memory by copying data into the wrong memory locations.
+
+It turns out that the failing case involves a fault on the store
+at label 79, and at that point the first unmodified byte of the
+destination is at R3 + 16. Consequently the exception handler
+for that store needs to add 16 to R3 before using it to work out
+how many bytes were not copied, but in this one case it was not
+adding the offset to R3. To fix it, this moves the label 179 to
+the point where we add 16 to R3. I have checked manually all the
+exception handlers for the loads and stores in this code and the
+rest of them are correct (it would be excellent to have an
+automated test of all the exception cases).
+
+This bug has been present since this code was initially
+committed in May 2002 to Linux version 2.5.20.
+
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/lib/copyuser_64.S | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/powerpc/lib/copyuser_64.S
++++ b/arch/powerpc/lib/copyuser_64.S
+@@ -359,6 +359,7 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
+ addi r3,r3,8
+ 171:
+ 177:
++179:
+ addi r3,r3,8
+ 370:
+ 372:
+@@ -373,7 +374,6 @@ END_FTR_SECTION_IFCLR(CPU_FTR_UNALIGNED_
+ 173:
+ 174:
+ 175:
+-179:
+ 181:
+ 184:
+ 186:
--- /dev/null
+From d63e51b31e0b655ed0f581b8a8fd4c4b4f8d1919 Mon Sep 17 00:00:00 2001
+From: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Date: Tue, 2 Aug 2016 14:10:29 +1000
+Subject: powerpc/powernv: Pass CPU-endian PE number to opal_pci_eeh_freeze_clear()
+
+From: Gavin Shan <gwshan@linux.vnet.ibm.com>
+
+commit d63e51b31e0b655ed0f581b8a8fd4c4b4f8d1919 upstream.
+
+The PE number (@frozen_pe_no), filled by opal_pci_next_error() is in
+big-endian format. It should be converted to CPU-endian before it is
+passed to opal_pci_eeh_freeze_clear() when clearing the frozen state if
+the PE is invalid one. As Michael Ellerman pointed out, the issue is
+also detected by sparse:
+
+ eeh-powernv.c:1541:41: warning: incorrect type in argument 2 (different base types)
+
+This passes CPU-endian PE number to opal_pci_eeh_freeze_clear() and it
+should be part of commit <0f36db77643b> ("powerpc/eeh: Fix wrong printed
+PE number"), which was merged to 4.3 kernel.
+
+Fixes: 71b540adffd9 ("powerpc/powernv: Don't escalate non-existing frozen PE")
+Suggested-by: Paul Mackerras <paulus@samba.org>
+Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Reviewed-by: Russell Currey <ruscur@russell.cc>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/platforms/powernv/eeh-powernv.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/powerpc/platforms/powernv/eeh-powernv.c
++++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
+@@ -1395,7 +1395,7 @@ static int pnv_eeh_next_error(struct eeh
+
+ /* Try best to clear it */
+ opal_pci_eeh_freeze_clear(phb->opal_id,
+- frozen_pe_no,
++ be64_to_cpu(frozen_pe_no),
+ OPAL_EEH_ACTION_CLEAR_FREEZE_ALL);
+ ret = EEH_NEXT_ERR_NONE;
+ } else if ((*pe)->state & EEH_PE_ISOLATED ||
--- /dev/null
+From a7032132d7560a8434e1f54b71efd7fa20f073bd Mon Sep 17 00:00:00 2001
+From: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Date: Tue, 2 Aug 2016 14:10:30 +1000
+Subject: powerpc/powernv: Use CPU-endian hub diag-data type in pnv_eeh_get_and_dump_hub_diag()
+
+From: Gavin Shan <gwshan@linux.vnet.ibm.com>
+
+commit a7032132d7560a8434e1f54b71efd7fa20f073bd upstream.
+
+The hub diag-data type is filled with big-endian data by OPAL call
+opal_pci_get_hub_diag_data(). We need convert it to CPU-endian value
+before using it. The issue is reported by sparse as pointed by Michael
+Ellerman:
+
+ eeh-powernv.c:1309:21: warning: restricted __be16 degrades to integer
+
+This converts hub diag-data type to CPU-endian before using it in
+pnv_eeh_get_and_dump_hub_diag().
+
+Fixes: 2a485ad7c88d ("powerpc/powernv: Drop PHB operation next_error()")
+Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Reviewed-by: Russell Currey <ruscur@russell.cc>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/platforms/powernv/eeh-powernv.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/arch/powerpc/platforms/powernv/eeh-powernv.c
++++ b/arch/powerpc/platforms/powernv/eeh-powernv.c
+@@ -1163,7 +1163,7 @@ static void pnv_eeh_get_and_dump_hub_dia
+ return;
+ }
+
+- switch (data->type) {
++ switch (be16_to_cpu(data->type)) {
+ case OPAL_P7IOC_DIAG_TYPE_RGC:
+ pr_info("P7IOC diag-data for RGC\n\n");
+ pnv_eeh_dump_hub_diag_common(data);
--- /dev/null
+From 5adaf8629b193f185ca5a1665b9e777a0579f518 Mon Sep 17 00:00:00 2001
+From: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Date: Tue, 2 Aug 2016 14:10:32 +1000
+Subject: powerpc/powernv: Use CPU-endian PEST in pnv_pci_dump_p7ioc_diag_data()
+
+From: Gavin Shan <gwshan@linux.vnet.ibm.com>
+
+commit 5adaf8629b193f185ca5a1665b9e777a0579f518 upstream.
+
+This fixes the warnings reported from sparse:
+
+ pci.c:312:33: warning: restricted __be64 degrades to integer
+ pci.c:313:33: warning: restricted __be64 degrades to integer
+
+Fixes: cee72d5bb489 ("powerpc/powernv: Display diag data on p7ioc EEH errors")
+Signed-off-by: Gavin Shan <gwshan@linux.vnet.ibm.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/platforms/powernv/pci.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/powerpc/platforms/powernv/pci.c
++++ b/arch/powerpc/platforms/powernv/pci.c
+@@ -197,8 +197,8 @@ static void pnv_pci_dump_p7ioc_diag_data
+ be64_to_cpu(data->dma1ErrorLog1));
+
+ for (i = 0; i < OPAL_P7IOC_NUM_PEST_REGS; i++) {
+- if ((data->pestA[i] >> 63) == 0 &&
+- (data->pestB[i] >> 63) == 0)
++ if ((be64_to_cpu(data->pestA[i]) >> 63) == 0 &&
++ (be64_to_cpu(data->pestB[i]) >> 63) == 0)
+ continue;
+
+ pr_info("PE[%3d] A/B: %016llx %016llx\n",
--- /dev/null
+From 05af40e885955065aee8bb7425058eb3e1adca08 Mon Sep 17 00:00:00 2001
+From: Laurent Dufour <ldufour@linux.vnet.ibm.com>
+Date: Thu, 6 Oct 2016 15:33:21 +0200
+Subject: powerpc/pseries: Fix stack corruption in htpe code
+
+From: Laurent Dufour <ldufour@linux.vnet.ibm.com>
+
+commit 05af40e885955065aee8bb7425058eb3e1adca08 upstream.
+
+This commit fixes a stack corruption in the pseries specific code dealing
+with the huge pages.
+
+In __pSeries_lpar_hugepage_invalidate() the buffer used to pass arguments
+to the hypervisor is not large enough. This leads to a stack corruption
+where a previously saved register could be corrupted leading to unexpected
+result in the caller, like the following panic:
+
+ Oops: Kernel access of bad area, sig: 11 [#1]
+ SMP NR_CPUS=2048 NUMA pSeries
+ Modules linked in: virtio_balloon ip_tables x_tables autofs4
+ virtio_blk 8139too virtio_pci virtio_ring 8139cp virtio
+ CPU: 11 PID: 1916 Comm: mmstress Not tainted 4.8.0 #76
+ task: c000000005394880 task.stack: c000000005570000
+ NIP: c00000000027bf6c LR: c00000000027bf64 CTR: 0000000000000000
+ REGS: c000000005573820 TRAP: 0300 Not tainted (4.8.0)
+ MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE> CR: 84822884 XER: 20000000
+ CFAR: c00000000010a924 DAR: 420000000014e5e0 DSISR: 40000000 SOFTE: 1
+ GPR00: c00000000027bf64 c000000005573aa0 c000000000e02800 c000000004447964
+ GPR04: c00000000404de18 c000000004d38810 00000000042100f5 00000000f5002104
+ GPR08: e0000000f5002104 0000000000000001 042100f5000000e0 00000000042100f5
+ GPR12: 0000000000002200 c00000000fe02c00 c00000000404de18 0000000000000000
+ GPR16: c1ffffffffffe7ff 00003fff62000000 420000000014e5e0 00003fff63000000
+ GPR20: 0008000000000000 c0000000f7014800 0405e600000000e0 0000000000010000
+ GPR24: c000000004d38810 c000000004447c10 c00000000404de18 c000000004447964
+ GPR28: c000000005573b10 c000000004d38810 00003fff62000000 420000000014e5e0
+ NIP [c00000000027bf6c] zap_huge_pmd+0x4c/0x470
+ LR [c00000000027bf64] zap_huge_pmd+0x44/0x470
+ Call Trace:
+ [c000000005573aa0] [c00000000027bf64] zap_huge_pmd+0x44/0x470 (unreliable)
+ [c000000005573af0] [c00000000022bbd8] unmap_page_range+0xcf8/0xed0
+ [c000000005573c30] [c00000000022c2d4] unmap_vmas+0x84/0x120
+ [c000000005573c80] [c000000000235448] unmap_region+0xd8/0x1b0
+ [c000000005573d80] [c0000000002378f0] do_munmap+0x2d0/0x4c0
+ [c000000005573df0] [c000000000237be4] SyS_munmap+0x64/0xb0
+ [c000000005573e30] [c000000000009560] system_call+0x38/0x108
+ Instruction dump:
+ fbe1fff8 fb81ffe0 7c7f1b78 7ca32b78 7cbd2b78 f8010010 7c9a2378 f821ffb1
+ 7cde3378 4bfffea9 7c7b1b79 41820298 <e87f0000> 48000130 7fa5eb78 7fc4f378
+
+Most of the time, the bug is surfacing in a caller up in the stack from
+__pSeries_lpar_hugepage_invalidate() which is quite confusing.
+
+This bug is pending since v3.11 but was hidden if a caller of the
+caller of __pSeries_lpar_hugepage_invalidate() has pushed the corruped
+register (r18 in this case) in the stack and is not using it until
+restoring it. GCC 6.2.0 seems to raise it more frequently.
+
+This commit also change the definition of the parameter buffer in
+pSeries_lpar_flush_hash_range() to rely on the global define
+PLPAR_HCALL9_BUFSIZE (no functional change here).
+
+Fixes: 1a5272866f87 ("powerpc: Optimize hugepage invalidate")
+Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
+Reviewed-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
+Acked-by: Balbir Singh <bsingharora@gmail.com>
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/platforms/pseries/lpar.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/powerpc/platforms/pseries/lpar.c
++++ b/arch/powerpc/platforms/pseries/lpar.c
+@@ -406,7 +406,7 @@ static void __pSeries_lpar_hugepage_inva
+ unsigned long *vpn, int count,
+ int psize, int ssize)
+ {
+- unsigned long param[8];
++ unsigned long param[PLPAR_HCALL9_BUFSIZE];
+ int i = 0, pix = 0, rc;
+ unsigned long flags = 0;
+ int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
+@@ -523,7 +523,7 @@ static void pSeries_lpar_flush_hash_rang
+ unsigned long flags = 0;
+ struct ppc64_tlb_batch *batch = this_cpu_ptr(&ppc64_tlb_batch);
+ int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
+- unsigned long param[9];
++ unsigned long param[PLPAR_HCALL9_BUFSIZE];
+ unsigned long hash, index, shift, hidx, slot;
+ real_pte_t pte;
+ int psize, ssize;
--- /dev/null
+From 5045ea37377ce8cca6890d32b127ad6770e6dce5 Mon Sep 17 00:00:00 2001
+From: Anton Blanchard <anton@samba.org>
+Date: Sun, 25 Sep 2016 17:16:53 +1000
+Subject: powerpc/vdso64: Use double word compare on pointers
+
+From: Anton Blanchard <anton@samba.org>
+
+commit 5045ea37377ce8cca6890d32b127ad6770e6dce5 upstream.
+
+__kernel_get_syscall_map() and __kernel_clock_getres() use cmpli to
+check if the passed in pointer is non zero. cmpli maps to a 32 bit
+compare on binutils, so we ignore the top 32 bits.
+
+A simple test case can be created by passing in a bogus pointer with
+the bottom 32 bits clear. Using a clk_id that is handled by the VDSO,
+then one that is handled by the kernel shows the problem:
+
+ printf("%d\n", clock_getres(CLOCK_REALTIME, (void *)0x100000000));
+ printf("%d\n", clock_getres(CLOCK_BOOTTIME, (void *)0x100000000));
+
+And we get:
+
+ 0
+ -1
+
+The bigger issue is if we pass a valid pointer with the bottom 32 bits
+clear, in this case we will return success but won't write any data
+to the pointer.
+
+I stumbled across this issue because the LLVM integrated assembler
+doesn't accept cmpli with 3 arguments. Fix this by converting them to
+cmpldi.
+
+Fixes: a7f290dad32e ("[PATCH] powerpc: Merge vdso's and add vdso support to 32 bits kernel")
+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/kernel/vdso64/datapage.S | 2 +-
+ arch/powerpc/kernel/vdso64/gettimeofday.S | 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+--- a/arch/powerpc/kernel/vdso64/datapage.S
++++ b/arch/powerpc/kernel/vdso64/datapage.S
+@@ -59,7 +59,7 @@ V_FUNCTION_BEGIN(__kernel_get_syscall_ma
+ bl V_LOCAL_FUNC(__get_datapage)
+ mtlr r12
+ addi r3,r3,CFG_SYSCALL_MAP64
+- cmpli cr0,r4,0
++ cmpldi cr0,r4,0
+ crclr cr0*4+so
+ beqlr
+ li r0,__NR_syscalls
+--- a/arch/powerpc/kernel/vdso64/gettimeofday.S
++++ b/arch/powerpc/kernel/vdso64/gettimeofday.S
+@@ -145,7 +145,7 @@ V_FUNCTION_BEGIN(__kernel_clock_getres)
+ bne cr0,99f
+
+ li r3,0
+- cmpli cr0,r4,0
++ cmpldi cr0,r4,0
+ crclr cr0*4+so
+ beqlr
+ lis r5,CLOCK_REALTIME_RES@h
pstore-core-drop-cmpxchg-based-updates.patch
pstore-ram-use-memcpy_toio-instead-of-memcpy.patch
pstore-ram-use-memcpy_fromio-to-save-old-buffer.patch
+perf-intel-pt-fix-snapshot-overlap-detection-decoder-errors.patch
+perf-intel-pt-fix-estimated-timestamps-for-cycle-accurate-mode.patch
+perf-intel-pt-fix-mtc-timestamp-calculation-for-large-mtc-periods.patch
+dm-mark-request_queue-dead-before-destroying-the-dm-device.patch
+dm-return-correct-error-code-in-dm_resume-s-retry-loop.patch
+dm-mpath-check-if-path-s-request_queue-is-dying-in-activate_path.patch
+dm-crypt-fix-crash-on-exit.patch
+powerpc-vdso64-use-double-word-compare-on-pointers.patch
+powerpc-powernv-pass-cpu-endian-pe-number-to-opal_pci_eeh_freeze_clear.patch
+powerpc-powernv-use-cpu-endian-hub-diag-data-type-in-pnv_eeh_get_and_dump_hub_diag.patch
+powerpc-powernv-use-cpu-endian-pest-in-pnv_pci_dump_p7ioc_diag_data.patch
+powerpc-64-fix-incorrect-return-value-from-__copy_tofrom_user.patch
+powerpc-pseries-fix-stack-corruption-in-htpe-code.patch
+ubi-deal-with-interrupted-erasures-in-wl.patch
--- /dev/null
+From 2365418879e9abf12ea9def7f9f3caf0dfa7ffb0 Mon Sep 17 00:00:00 2001
+From: Richard Weinberger <richard@nod.at>
+Date: Wed, 24 Aug 2016 14:36:13 +0200
+Subject: ubi: Deal with interrupted erasures in WL
+
+From: Richard Weinberger <richard@nod.at>
+
+commit 2365418879e9abf12ea9def7f9f3caf0dfa7ffb0 upstream.
+
+When Fastmap is used we can face here an -EBADMSG
+since Fastmap cannot know about unmaps.
+If the erasure was interrupted the PEB may show ECC
+errors and UBI would go to ro-mode as it assumes
+that the PEB was check during attach time, which is
+not the case with Fastmap.
+
+Fixes: dbb7d2a88d ("UBI: Add fastmap core")
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mtd/ubi/wl.c | 21 +++++++++++++++++++--
+ 1 file changed, 19 insertions(+), 2 deletions(-)
+
+--- a/drivers/mtd/ubi/wl.c
++++ b/drivers/mtd/ubi/wl.c
+@@ -643,7 +643,7 @@ static int wear_leveling_worker(struct u
+ int shutdown)
+ {
+ int err, scrubbing = 0, torture = 0, protect = 0, erroneous = 0;
+- int vol_id = -1, lnum = -1;
++ int erase = 0, keep = 0, vol_id = -1, lnum = -1;
+ #ifdef CONFIG_MTD_UBI_FASTMAP
+ int anchor = wrk->anchor;
+ #endif
+@@ -777,6 +777,16 @@ static int wear_leveling_worker(struct u
+ e1->pnum);
+ scrubbing = 1;
+ goto out_not_moved;
++ } else if (ubi->fast_attach && err == UBI_IO_BAD_HDR_EBADMSG) {
++ /*
++ * While a full scan would detect interrupted erasures
++ * at attach time we can face them here when attached from
++ * Fastmap.
++ */
++ dbg_wl("PEB %d has ECC errors, maybe from an interrupted erasure",
++ e1->pnum);
++ erase = 1;
++ goto out_not_moved;
+ }
+
+ ubi_err(ubi, "error %d while reading VID header from PEB %d",
+@@ -810,6 +820,7 @@ static int wear_leveling_worker(struct u
+ * Target PEB had bit-flips or write error - torture it.
+ */
+ torture = 1;
++ keep = 1;
+ goto out_not_moved;
+ }
+
+@@ -895,7 +906,7 @@ out_not_moved:
+ ubi->erroneous_peb_count += 1;
+ } else if (scrubbing)
+ wl_tree_add(e1, &ubi->scrub);
+- else
++ else if (keep)
+ wl_tree_add(e1, &ubi->used);
+ ubi_assert(!ubi->move_to_put);
+ ubi->move_from = ubi->move_to = NULL;
+@@ -907,6 +918,12 @@ out_not_moved:
+ if (err)
+ goto out_ro;
+
++ if (erase) {
++ err = do_sync_erase(ubi, e1, vol_id, lnum, 1);
++ if (err)
++ goto out_ro;
++ }
++
+ mutex_unlock(&ubi->move_mutex);
+ return 0;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
