--- /dev/null
+From 32c3fa7cdf0c4a3eb8405fc3e13398de019e828b Mon Sep 17 00:00:00 2001
+From: Will Deacon <will.deacon@arm.com>
+Date: Mon, 21 May 2018 17:44:57 +0100
+Subject: arm64: lse: Add early clobbers to some input/output asm operands
+
+From: Will Deacon <will.deacon@arm.com>
+
+commit 32c3fa7cdf0c4a3eb8405fc3e13398de019e828b upstream.
+
+For LSE atomics that read and write a register operand, we need to
+ensure that these operands are annotated as "early clobber" if the
+register is written before all of the input operands have been consumed.
+Failure to do so can result in the compiler allocating the same register
+to both operands, leading to splats such as:
+
+ Unable to handle kernel paging request at virtual address 11111122222221
+ [...]
+ x1 : 1111111122222222 x0 : 1111111122222221
+ Process swapper/0 (pid: 1, stack limit = 0x000000008209f908)
+ Call trace:
+ test_atomic64+0x1360/0x155c
+
+where x0 has been allocated as both the value to be stored and also the
+atomic_t pointer.
+
+This patch adds the missing clobbers.
+
+Cc: <stable@vger.kernel.org>
+Cc: Dave Martin <dave.martin@arm.com>
+Cc: Robin Murphy <robin.murphy@arm.com>
+Reported-by: Mark Salter <msalter@redhat.com>
+Signed-off-by: Will Deacon <will.deacon@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/arm64/include/asm/atomic_lse.h | 24 ++++++++++++------------
+ 1 file changed, 12 insertions(+), 12 deletions(-)
+
+--- a/arch/arm64/include/asm/atomic_lse.h
++++ b/arch/arm64/include/asm/atomic_lse.h
+@@ -117,7 +117,7 @@ static inline void atomic_and(int i, ato
+ /* LSE atomics */
+ " mvn %w[i], %w[i]\n"
+ " stclr %w[i], %[v]")
+- : [i] "+r" (w0), [v] "+Q" (v->counter)
++ : [i] "+&r" (w0), [v] "+Q" (v->counter)
+ : "r" (x1)
+ : __LL_SC_CLOBBERS);
+ }
+@@ -135,7 +135,7 @@ static inline int atomic_fetch_and##name
+ /* LSE atomics */ \
+ " mvn %w[i], %w[i]\n" \
+ " ldclr" #mb " %w[i], %w[i], %[v]") \
+- : [i] "+r" (w0), [v] "+Q" (v->counter) \
++ : [i] "+&r" (w0), [v] "+Q" (v->counter) \
+ : "r" (x1) \
+ : __LL_SC_CLOBBERS, ##cl); \
+ \
+@@ -161,7 +161,7 @@ static inline void atomic_sub(int i, ato
+ /* LSE atomics */
+ " neg %w[i], %w[i]\n"
+ " stadd %w[i], %[v]")
+- : [i] "+r" (w0), [v] "+Q" (v->counter)
++ : [i] "+&r" (w0), [v] "+Q" (v->counter)
+ : "r" (x1)
+ : __LL_SC_CLOBBERS);
+ }
+@@ -180,7 +180,7 @@ static inline int atomic_sub_return##nam
+ " neg %w[i], %w[i]\n" \
+ " ldadd" #mb " %w[i], w30, %[v]\n" \
+ " add %w[i], %w[i], w30") \
+- : [i] "+r" (w0), [v] "+Q" (v->counter) \
++ : [i] "+&r" (w0), [v] "+Q" (v->counter) \
+ : "r" (x1) \
+ : __LL_SC_CLOBBERS , ##cl); \
+ \
+@@ -207,7 +207,7 @@ static inline int atomic_fetch_sub##name
+ /* LSE atomics */ \
+ " neg %w[i], %w[i]\n" \
+ " ldadd" #mb " %w[i], %w[i], %[v]") \
+- : [i] "+r" (w0), [v] "+Q" (v->counter) \
++ : [i] "+&r" (w0), [v] "+Q" (v->counter) \
+ : "r" (x1) \
+ : __LL_SC_CLOBBERS, ##cl); \
+ \
+@@ -314,7 +314,7 @@ static inline void atomic64_and(long i,
+ /* LSE atomics */
+ " mvn %[i], %[i]\n"
+ " stclr %[i], %[v]")
+- : [i] "+r" (x0), [v] "+Q" (v->counter)
++ : [i] "+&r" (x0), [v] "+Q" (v->counter)
+ : "r" (x1)
+ : __LL_SC_CLOBBERS);
+ }
+@@ -332,7 +332,7 @@ static inline long atomic64_fetch_and##n
+ /* LSE atomics */ \
+ " mvn %[i], %[i]\n" \
+ " ldclr" #mb " %[i], %[i], %[v]") \
+- : [i] "+r" (x0), [v] "+Q" (v->counter) \
++ : [i] "+&r" (x0), [v] "+Q" (v->counter) \
+ : "r" (x1) \
+ : __LL_SC_CLOBBERS, ##cl); \
+ \
+@@ -358,7 +358,7 @@ static inline void atomic64_sub(long i,
+ /* LSE atomics */
+ " neg %[i], %[i]\n"
+ " stadd %[i], %[v]")
+- : [i] "+r" (x0), [v] "+Q" (v->counter)
++ : [i] "+&r" (x0), [v] "+Q" (v->counter)
+ : "r" (x1)
+ : __LL_SC_CLOBBERS);
+ }
+@@ -377,7 +377,7 @@ static inline long atomic64_sub_return##
+ " neg %[i], %[i]\n" \
+ " ldadd" #mb " %[i], x30, %[v]\n" \
+ " add %[i], %[i], x30") \
+- : [i] "+r" (x0), [v] "+Q" (v->counter) \
++ : [i] "+&r" (x0), [v] "+Q" (v->counter) \
+ : "r" (x1) \
+ : __LL_SC_CLOBBERS, ##cl); \
+ \
+@@ -404,7 +404,7 @@ static inline long atomic64_fetch_sub##n
+ /* LSE atomics */ \
+ " neg %[i], %[i]\n" \
+ " ldadd" #mb " %[i], %[i], %[v]") \
+- : [i] "+r" (x0), [v] "+Q" (v->counter) \
++ : [i] "+&r" (x0), [v] "+Q" (v->counter) \
+ : "r" (x1) \
+ : __LL_SC_CLOBBERS, ##cl); \
+ \
+@@ -435,7 +435,7 @@ static inline long atomic64_dec_if_posit
+ " sub x30, x30, %[ret]\n"
+ " cbnz x30, 1b\n"
+ "2:")
+- : [ret] "+r" (x0), [v] "+Q" (v->counter)
++ : [ret] "+&r" (x0), [v] "+Q" (v->counter)
+ :
+ : __LL_SC_CLOBBERS, "cc", "memory");
+
+@@ -516,7 +516,7 @@ static inline long __cmpxchg_double##nam
+ " eor %[old1], %[old1], %[oldval1]\n" \
+ " eor %[old2], %[old2], %[oldval2]\n" \
+ " orr %[old1], %[old1], %[old2]") \
+- : [old1] "+r" (x0), [old2] "+r" (x1), \
++ : [old1] "+&r" (x0), [old2] "+&r" (x1), \
+ [v] "+Q" (*(unsigned long *)ptr) \
+ : [new1] "r" (x2), [new2] "r" (x3), [ptr] "r" (x4), \
+ [oldval1] "r" (oldval1), [oldval2] "r" (oldval2) \
--- /dev/null
+From 938ae7259c908ad031da35d551da297640bb640c Mon Sep 17 00:00:00 2001
+From: Thomas Hellstrom <thellstrom@vmware.com>
+Date: Wed, 23 May 2018 16:11:24 +0200
+Subject: drm/vmwgfx: Fix 32-bit VMW_PORT_HB_[IN|OUT] macros
+
+From: Thomas Hellstrom <thellstrom@vmware.com>
+
+commit 938ae7259c908ad031da35d551da297640bb640c upstream.
+
+Depending on whether the kernel is compiled with frame-pointer or not,
+the temporary memory location used for the bp parameter in these macros
+is referenced relative to the stack pointer or the frame pointer.
+Hence we can never reference that parameter when we've modified either
+the stack pointer or the frame pointer, because then the compiler would
+generate an incorrect stack reference.
+
+Fix this by pushing the temporary memory parameter on a known location on
+the stack before modifying the stack- and frame pointers.
+
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
+Reviewed-by: Brian Paul <brianp@vmware.com>
+Reviewed-by: Sinclair Yeh <syeh@vmware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vmwgfx/vmwgfx_msg.h | 25 +++++++++++++++++--------
+ 1 file changed, 17 insertions(+), 8 deletions(-)
+
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_msg.h
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_msg.h
+@@ -135,17 +135,24 @@
+
+ #else
+
+-/* In the 32-bit version of this macro, we use "m" because there is no
+- * more register left for bp
++/*
++ * In the 32-bit version of this macro, we store bp in a memory location
++ * because we've ran out of registers.
++ * Now we can't reference that memory location while we've modified
++ * %esp or %ebp, so we first push it on the stack, just before we push
++ * %ebp, and then when we need it we read it from the stack where we
++ * just pushed it.
+ */
+ #define VMW_PORT_HB_OUT(cmd, in_ecx, in_si, in_di, \
+ port_num, magic, bp, \
+ eax, ebx, ecx, edx, si, di) \
+ ({ \
+- asm volatile ("push %%ebp;" \
+- "mov %12, %%ebp;" \
++ asm volatile ("push %12;" \
++ "push %%ebp;" \
++ "mov 0x04(%%esp), %%ebp;" \
+ "rep outsb;" \
+- "pop %%ebp;" : \
++ "pop %%ebp;" \
++ "add $0x04, %%esp;" : \
+ "=a"(eax), \
+ "=b"(ebx), \
+ "=c"(ecx), \
+@@ -167,10 +174,12 @@
+ port_num, magic, bp, \
+ eax, ebx, ecx, edx, si, di) \
+ ({ \
+- asm volatile ("push %%ebp;" \
+- "mov %12, %%ebp;" \
++ asm volatile ("push %12;" \
++ "push %%ebp;" \
++ "mov 0x04(%%esp), %%ebp;" \
+ "rep insb;" \
+- "pop %%ebp" : \
++ "pop %%ebp;" \
++ "add $0x04, %%esp;" : \
+ "=a"(eax), \
+ "=b"(ebx), \
+ "=c"(ecx), \
--- /dev/null
+From f9e76ca3771bf23d2142a81a88ddd8f31f5c4c03 Mon Sep 17 00:00:00 2001
+From: "Michael J. Ruhl" <michael.j.ruhl@intel.com>
+Date: Wed, 2 May 2018 06:42:51 -0700
+Subject: IB/hfi1: Use after free race condition in send context error path
+
+From: Michael J. Ruhl <michael.j.ruhl@intel.com>
+
+commit f9e76ca3771bf23d2142a81a88ddd8f31f5c4c03 upstream.
+
+A pio send egress error can occur when the PSM library attempts to
+to send a bad packet. That issue is still being investigated.
+
+The pio error interrupt handler then attempts to progress the recovery
+of the errored pio send context.
+
+Code inspection reveals that the handling lacks the necessary locking
+if that recovery interleaves with a PSM close of the "context" object
+contains the pio send context.
+
+The lack of the locking can cause the recovery to access the already
+freed pio send context object and incorrectly deduce that the pio
+send context is actually a kernel pio send context as shown by the
+NULL deref stack below:
+
+[<ffffffff8143d78c>] _dev_info+0x6c/0x90
+[<ffffffffc0613230>] sc_restart+0x70/0x1f0 [hfi1]
+[<ffffffff816ab124>] ? __schedule+0x424/0x9b0
+[<ffffffffc06133c5>] sc_halted+0x15/0x20 [hfi1]
+[<ffffffff810aa3ba>] process_one_work+0x17a/0x440
+[<ffffffff810ab086>] worker_thread+0x126/0x3c0
+[<ffffffff810aaf60>] ? manage_workers.isra.24+0x2a0/0x2a0
+[<ffffffff810b252f>] kthread+0xcf/0xe0
+[<ffffffff810b2460>] ? insert_kthread_work+0x40/0x40
+[<ffffffff816b8798>] ret_from_fork+0x58/0x90
+[<ffffffff810b2460>] ? insert_kthread_work+0x40/0x40
+
+This is the best case scenario and other scenarios can corrupt the
+already freed memory.
+
+Fix by adding the necessary locking in the pio send context error
+handler.
+
+Cc: <stable@vger.kernel.org> # 4.9.x
+Reviewed-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
+Reviewed-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
+Signed-off-by: Michael J. Ruhl <michael.j.ruhl@intel.com>
+Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
+Signed-off-by: Doug Ledford <dledford@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/hw/hfi1/chip.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/infiniband/hw/hfi1/chip.c
++++ b/drivers/infiniband/hw/hfi1/chip.c
+@@ -5945,6 +5945,7 @@ static void is_sendctxt_err_int(struct h
+ u64 status;
+ u32 sw_index;
+ int i = 0;
++ unsigned long irq_flags;
+
+ sw_index = dd->hw_to_sw[hw_context];
+ if (sw_index >= dd->num_send_contexts) {
+@@ -5954,10 +5955,12 @@ static void is_sendctxt_err_int(struct h
+ return;
+ }
+ sci = &dd->send_contexts[sw_index];
++ spin_lock_irqsave(&dd->sc_lock, irq_flags);
+ sc = sci->sc;
+ if (!sc) {
+ dd_dev_err(dd, "%s: context %u(%u): no sc?\n", __func__,
+ sw_index, hw_context);
++ spin_unlock_irqrestore(&dd->sc_lock, irq_flags);
+ return;
+ }
+
+@@ -5979,6 +5982,7 @@ static void is_sendctxt_err_int(struct h
+ */
+ if (sc->type != SC_USER)
+ queue_work(dd->pport->hfi1_wq, &sc->halt_work);
++ spin_unlock_irqrestore(&dd->sc_lock, irq_flags);
+
+ /*
+ * Update the counters for the corresponding status bits.
--- /dev/null
+From 8e907ed4882714fd13cfe670681fc6cb5284c780 Mon Sep 17 00:00:00 2001
+From: Lidong Chen <jemmy858585@gmail.com>
+Date: Tue, 8 May 2018 16:50:16 +0800
+Subject: IB/umem: Use the correct mm during ib_umem_release
+
+From: Lidong Chen <jemmy858585@gmail.com>
+
+commit 8e907ed4882714fd13cfe670681fc6cb5284c780 upstream.
+
+User-space may invoke ibv_reg_mr and ibv_dereg_mr in different threads.
+
+If ibv_dereg_mr is called after the thread which invoked ibv_reg_mr has
+exited, get_pid_task will return NULL and ib_umem_release will not
+decrease mm->pinned_vm.
+
+Instead of using threads to locate the mm, use the overall tgid from the
+ib_ucontext struct instead. This matches the behavior of ODP and
+disassociate in handling the mm of the process that called ibv_reg_mr.
+
+Cc: <stable@vger.kernel.org>
+Fixes: 87773dd56d54 ("IB: ib_umem_release() should decrement mm->pinned_vm from ib_umem_get")
+Signed-off-by: Lidong Chen <lidongchen@tencent.com>
+Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/infiniband/core/umem.c | 7 +------
+ include/rdma/ib_umem.h | 1 -
+ 2 files changed, 1 insertion(+), 7 deletions(-)
+
+--- a/drivers/infiniband/core/umem.c
++++ b/drivers/infiniband/core/umem.c
+@@ -119,7 +119,6 @@ struct ib_umem *ib_umem_get(struct ib_uc
+ umem->length = size;
+ umem->address = addr;
+ umem->page_shift = PAGE_SHIFT;
+- umem->pid = get_task_pid(current, PIDTYPE_PID);
+ /*
+ * We ask for writable memory if any of the following
+ * access flags are set. "Local write" and "remote write"
+@@ -132,7 +131,6 @@ struct ib_umem *ib_umem_get(struct ib_uc
+ IB_ACCESS_REMOTE_ATOMIC | IB_ACCESS_MW_BIND));
+
+ if (access & IB_ACCESS_ON_DEMAND) {
+- put_pid(umem->pid);
+ ret = ib_umem_odp_get(context, umem, access);
+ if (ret) {
+ kfree(umem);
+@@ -148,7 +146,6 @@ struct ib_umem *ib_umem_get(struct ib_uc
+
+ page_list = (struct page **) __get_free_page(GFP_KERNEL);
+ if (!page_list) {
+- put_pid(umem->pid);
+ kfree(umem);
+ return ERR_PTR(-ENOMEM);
+ }
+@@ -231,7 +228,6 @@ out:
+ if (ret < 0) {
+ if (need_release)
+ __ib_umem_release(context->device, umem, 0);
+- put_pid(umem->pid);
+ kfree(umem);
+ } else
+ current->mm->pinned_vm = locked;
+@@ -274,8 +270,7 @@ void ib_umem_release(struct ib_umem *ume
+
+ __ib_umem_release(umem->context->device, umem, 1);
+
+- task = get_pid_task(umem->pid, PIDTYPE_PID);
+- put_pid(umem->pid);
++ task = get_pid_task(umem->context->tgid, PIDTYPE_PID);
+ if (!task)
+ goto out;
+ mm = get_task_mm(task);
+--- a/include/rdma/ib_umem.h
++++ b/include/rdma/ib_umem.h
+@@ -48,7 +48,6 @@ struct ib_umem {
+ int writable;
+ int hugetlb;
+ struct work_struct work;
+- struct pid *pid;
+ struct mm_struct *mm;
+ unsigned long diff;
+ struct ib_umem_odp *odp_data;
--- /dev/null
+From 7a4deea1aa8bddfed4ef1b35fc2b6732563d8ad5 Mon Sep 17 00:00:00 2001
+From: Matthew Wilcox <mawilcox@microsoft.com>
+Date: Fri, 25 May 2018 14:47:24 -0700
+Subject: idr: fix invalid ptr dereference on item delete
+
+From: Matthew Wilcox <mawilcox@microsoft.com>
+
+commit 7a4deea1aa8bddfed4ef1b35fc2b6732563d8ad5 upstream.
+
+If the radix tree underlying the IDR happens to be full and we attempt
+to remove an id which is larger than any id in the IDR, we will call
+__radix_tree_delete() with an uninitialised 'slot' pointer, at which
+point anything could happen. This was easiest to hit with a single
+entry at id 0 and attempting to remove a non-0 id, but it could have
+happened with 64 entries and attempting to remove an id >= 64.
+
+Roman said:
+
+ The syzcaller test boils down to opening /dev/kvm, creating an
+ eventfd, and calling a couple of KVM ioctls. None of this requires
+ superuser. And the result is dereferencing an uninitialized pointer
+ which is likely a crash. The specific path caught by syzbot is via
+ KVM_HYPERV_EVENTD ioctl which is new in 4.17. But I guess there are
+ other user-triggerable paths, so cc:stable is probably justified.
+
+Matthew added:
+
+ We have around 250 calls to idr_remove() in the kernel today. Many of
+ them pass an ID which is embedded in the object they're removing, so
+ they're safe. Picking a few likely candidates:
+
+ drivers/firewire/core-cdev.c looks unsafe; the ID comes from an ioctl.
+ drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c is similar
+ drivers/atm/nicstar.c could be taken down by a handcrafted packet
+
+Link: http://lkml.kernel.org/r/20180518175025.GD6361@bombadil.infradead.org
+Fixes: 0a835c4f090a ("Reimplement IDR and IDA using the radix tree")
+Reported-by: <syzbot+35666cba7f0a337e2e79@syzkaller.appspotmail.com>
+Debugged-by: Roman Kagan <rkagan@virtuozzo.com>
+Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com>
+Cc: <stable@vger.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>
+
+---
+ lib/radix-tree.c | 4 +++-
+ tools/testing/radix-tree/idr-test.c | 7 +++++++
+ 2 files changed, 10 insertions(+), 1 deletion(-)
+
+--- a/lib/radix-tree.c
++++ b/lib/radix-tree.c
+@@ -2037,10 +2037,12 @@ void *radix_tree_delete_item(struct radi
+ unsigned long index, void *item)
+ {
+ struct radix_tree_node *node = NULL;
+- void __rcu **slot;
++ void __rcu **slot = NULL;
+ void *entry;
+
+ entry = __radix_tree_lookup(root, index, &node, &slot);
++ if (!slot)
++ return NULL;
+ if (!entry && (!is_idr(root) || node_tag_get(root, node, IDR_FREE,
+ get_slot_offset(node, slot))))
+ return NULL;
+--- a/tools/testing/radix-tree/idr-test.c
++++ b/tools/testing/radix-tree/idr-test.c
+@@ -202,6 +202,13 @@ void idr_checks(void)
+ idr_remove(&idr, 3);
+ idr_remove(&idr, 0);
+
++ assert(idr_alloc(&idr, DUMMY_PTR, 0, 0, GFP_KERNEL) == 0);
++ idr_remove(&idr, 1);
++ for (i = 1; i < RADIX_TREE_MAP_SIZE; i++)
++ assert(idr_alloc(&idr, DUMMY_PTR, 0, 0, GFP_KERNEL) == i);
++ idr_remove(&idr, 1 << 30);
++ idr_destroy(&idr);
++
+ for (i = INT_MAX - 3UL; i < INT_MAX + 1UL; i++) {
+ struct item *item = item_create(i, 0);
+ assert(idr_alloc(&idr, item, i, i + 10, GFP_KERNEL) == i);
--- /dev/null
+From 8f89c007b6dec16a1793cb88de88fcc02117bbbc Mon Sep 17 00:00:00 2001
+From: Davidlohr Bueso <dave@stgolabs.net>
+Date: Fri, 25 May 2018 14:47:30 -0700
+Subject: ipc/shm: fix shmat() nil address after round-down when remapping
+
+From: Davidlohr Bueso <dave@stgolabs.net>
+
+commit 8f89c007b6dec16a1793cb88de88fcc02117bbbc upstream.
+
+shmat()'s SHM_REMAP option forbids passing a nil address for; this is in
+fact the very first thing we check for. Andrea reported that for
+SHM_RND|SHM_REMAP cases we can end up bypassing the initial addr check,
+but we need to check again if the address was rounded down to nil. As
+of this patch, such cases will return -EINVAL.
+
+Link: http://lkml.kernel.org/r/20180503204934.kk63josdu6u53fbd@linux-n805
+Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
+Reported-by: Andrea Arcangeli <aarcange@redhat.com>
+Cc: Joe Lawrence <joe.lawrence@redhat.com>
+Cc: Manfred Spraul <manfred@colorfullife.com>
+Cc: <stable@vger.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>
+
+---
+ ipc/shm.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+--- a/ipc/shm.c
++++ b/ipc/shm.c
+@@ -1309,9 +1309,17 @@ long do_shmat(int shmid, char __user *sh
+
+ if (addr) {
+ if (addr & (shmlba - 1)) {
+- if (shmflg & SHM_RND)
++ if (shmflg & SHM_RND) {
+ addr &= ~(shmlba - 1); /* round down */
+- else
++
++ /*
++ * Ensure that the round-down is non-nil
++ * when remapping. This can happen for
++ * cases when addr < shmlba.
++ */
++ if (!addr && (shmflg & SHM_REMAP))
++ goto out;
++ } else
+ #ifndef __ARCH_FORCE_SHMLBA
+ if (addr & ~PAGE_MASK)
+ #endif
--- /dev/null
+From 3f1959721558a976aaf9c2024d5bc884e6411bf7 Mon Sep 17 00:00:00 2001
+From: David Hildenbrand <david@redhat.com>
+Date: Fri, 25 May 2018 14:48:11 -0700
+Subject: kasan: fix memory hotplug during boot
+
+From: David Hildenbrand <david@redhat.com>
+
+commit 3f1959721558a976aaf9c2024d5bc884e6411bf7 upstream.
+
+Using module_init() is wrong. E.g. ACPI adds and onlines memory before
+our memory notifier gets registered.
+
+This makes sure that ACPI memory detected during boot up will not result
+in a kernel crash.
+
+Easily reproducible with QEMU, just specify a DIMM when starting up.
+
+Link: http://lkml.kernel.org/r/20180522100756.18478-3-david@redhat.com
+Fixes: 786a8959912e ("kasan: disable memory hotplug")
+Signed-off-by: David Hildenbrand <david@redhat.com>
+Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
+Cc: Alexander Potapenko <glider@google.com>
+Cc: Dmitry Vyukov <dvyukov@google.com>
+Cc: <stable@vger.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>
+
+---
+ mm/kasan/kasan.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/kasan/kasan.c
++++ b/mm/kasan/kasan.c
+@@ -843,5 +843,5 @@ static int __init kasan_memhotplug_init(
+ return 0;
+ }
+
+-module_init(kasan_memhotplug_init);
++core_initcall(kasan_memhotplug_init);
+ #endif
--- /dev/null
+From ed1596f9ab958dd156a66c9ff1029d3761c1786a Mon Sep 17 00:00:00 2001
+From: David Hildenbrand <david@redhat.com>
+Date: Fri, 25 May 2018 14:48:08 -0700
+Subject: kasan: free allocated shadow memory on MEM_CANCEL_ONLINE
+
+From: David Hildenbrand <david@redhat.com>
+
+commit ed1596f9ab958dd156a66c9ff1029d3761c1786a upstream.
+
+We have to free memory again when we cancel onlining, otherwise a later
+onlining attempt will fail.
+
+Link: http://lkml.kernel.org/r/20180522100756.18478-2-david@redhat.com
+Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug")
+Signed-off-by: David Hildenbrand <david@redhat.com>
+Acked-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
+Cc: Alexander Potapenko <glider@google.com>
+Cc: Dmitry Vyukov <dvyukov@google.com>
+Cc: <stable@vger.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>
+
+---
+ mm/kasan/kasan.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/mm/kasan/kasan.c
++++ b/mm/kasan/kasan.c
+@@ -811,6 +811,7 @@ static int __meminit kasan_mem_notifier(
+ kmemleak_ignore(ret);
+ return NOTIFY_OK;
+ }
++ case MEM_CANCEL_ONLINE:
+ case MEM_OFFLINE: {
+ struct vm_struct *vm;
+
--- /dev/null
+From 23d6aef74da86a33fa6bb75f79565e0a16ee97c2 Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
+Date: Fri, 25 May 2018 14:47:57 -0700
+Subject: kernel/sys.c: fix potential Spectre v1 issue
+
+From: Gustavo A. R. Silva <gustavo@embeddedor.com>
+
+commit 23d6aef74da86a33fa6bb75f79565e0a16ee97c2 upstream.
+
+`resource' can be controlled by user-space, hence leading to a potential
+exploitation of the Spectre variant 1 vulnerability.
+
+This issue was detected with the help of Smatch:
+
+ kernel/sys.c:1474 __do_compat_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap)
+ kernel/sys.c:1455 __do_sys_old_getrlimit() warn: potential spectre issue 'get_current()->signal->rlim' (local cap)
+
+Fix this by sanitizing *resource* before using it to index
+current->signal->rlim
+
+Notice that given that speculation windows are large, the policy is to
+kill the speculation on the first load and not worry if it can be
+completed with a dependent load/store [1].
+
+[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2
+
+Link: http://lkml.kernel.org/r/20180515030038.GA11822@embeddedor.com
+Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
+Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
+Cc: Alexei Starovoitov <ast@kernel.org>
+Cc: Dan Williams <dan.j.williams@intel.com>
+Cc: Thomas Gleixner <tglx@linutronix.de>
+Cc: Peter Zijlstra <peterz@infradead.org>
+Cc: <stable@vger.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>
+
+---
+ kernel/sys.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/kernel/sys.c
++++ b/kernel/sys.c
+@@ -1395,6 +1395,7 @@ SYSCALL_DEFINE2(old_getrlimit, unsigned
+ if (resource >= RLIM_NLIMITS)
+ return -EINVAL;
+
++ resource = array_index_nospec(resource, RLIM_NLIMITS);
+ task_lock(current->group_leader);
+ x = current->signal->rlim[resource];
+ task_unlock(current->group_leader);
+@@ -1414,6 +1415,7 @@ COMPAT_SYSCALL_DEFINE2(old_getrlimit, un
+ if (resource >= RLIM_NLIMITS)
+ return -EINVAL;
+
++ resource = array_index_nospec(resource, RLIM_NLIMITS);
+ task_lock(current->group_leader);
+ r = current->signal->rlim[resource];
+ task_unlock(current->group_leader);
--- /dev/null
+From 136d769e0b3475d71350aa3648a116a6ee7a8f6c Mon Sep 17 00:00:00 2001
+From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Date: Sat, 19 May 2018 22:29:36 +0100
+Subject: libata: blacklist Micron 500IT SSD with MU01 firmware
+
+From: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+
+commit 136d769e0b3475d71350aa3648a116a6ee7a8f6c upstream.
+
+While whitelisting Micron M500DC drives, the tweaked blacklist entry
+enabled queued TRIM from M500IT variants also. But these do not support
+queued TRIM. And while using those SSDs with the latest kernel we have
+seen errors and even the partition table getting corrupted.
+
+Some part from the dmesg:
+[ 6.727384] ata1.00: ATA-9: Micron_M500IT_MTFDDAK060MBD, MU01, max UDMA/133
+[ 6.727390] ata1.00: 117231408 sectors, multi 16: LBA48 NCQ (depth 31/32), AA
+[ 6.741026] ata1.00: supports DRM functions and may not be fully accessible
+[ 6.759887] ata1.00: configured for UDMA/133
+[ 6.762256] scsi 0:0:0:0: Direct-Access ATA Micron_M500IT_MT MU01 PQ: 0 ANSI: 5
+
+and then for the error:
+[ 120.860334] ata1.00: exception Emask 0x1 SAct 0x7ffc0007 SErr 0x0 action 0x6 frozen
+[ 120.860338] ata1.00: irq_stat 0x40000008
+[ 120.860342] ata1.00: failed command: SEND FPDMA QUEUED
+[ 120.860351] ata1.00: cmd 64/01:00:00:00:00/00:00:00:00:00/a0 tag 0 ncq dma 512 out
+ res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x5 (timeout)
+[ 120.860353] ata1.00: status: { DRDY }
+[ 120.860543] ata1: hard resetting link
+[ 121.166128] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
+[ 121.166376] ata1.00: supports DRM functions and may not be fully accessible
+[ 121.186238] ata1.00: supports DRM functions and may not be fully accessible
+[ 121.204445] ata1.00: configured for UDMA/133
+[ 121.204454] ata1.00: device reported invalid CHS sector 0
+[ 121.204541] sd 0:0:0:0: [sda] tag#18 UNKNOWN(0x2003) Result: hostbyte=0x00 driverbyte=0x08
+[ 121.204546] sd 0:0:0:0: [sda] tag#18 Sense Key : 0x5 [current]
+[ 121.204550] sd 0:0:0:0: [sda] tag#18 ASC=0x21 ASCQ=0x4
+[ 121.204555] sd 0:0:0:0: [sda] tag#18 CDB: opcode=0x93 93 08 00 00 00 00 00 04 28 80 00 00 00 30 00 00
+[ 121.204559] print_req_error: I/O error, dev sda, sector 272512
+
+After few reboots with these errors, and the SSD is corrupted.
+After blacklisting it, the errors are not seen and the SSD does not get
+corrupted any more.
+
+Fixes: 243918be6393 ("libata: Do not blacklist Micron M500DC")
+Cc: Martin K. Petersen <martin.petersen@oracle.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/libata-core.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/ata/libata-core.c
++++ b/drivers/ata/libata-core.c
+@@ -4547,6 +4547,8 @@ static const struct ata_blacklist_entry
+ { "SanDisk SD7UB3Q*G1001", NULL, ATA_HORKAGE_NOLPM, },
+
+ /* devices that don't properly handle queued TRIM commands */
++ { "Micron_M500IT_*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |
++ ATA_HORKAGE_ZERO_AFTER_TRIM, },
+ { "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
+ ATA_HORKAGE_ZERO_AFTER_TRIM, },
+ { "Crucial_CT*M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |
--- /dev/null
+From 322579dcc865b94b47345ad1b6002ad167f85405 Mon Sep 17 00:00:00 2001
+From: Tejun Heo <tj@kernel.org>
+Date: Tue, 8 May 2018 14:21:56 -0700
+Subject: libata: Blacklist some Sandisk SSDs for NCQ
+
+From: Tejun Heo <tj@kernel.org>
+
+commit 322579dcc865b94b47345ad1b6002ad167f85405 upstream.
+
+Sandisk SSDs SD7SN6S256G and SD8SN8U256G are regularly locking up
+regularly under sustained moderate load with NCQ enabled. Blacklist
+for now.
+
+Signed-off-by: Tejun Heo <tj@kernel.org>
+Reported-by: Dave Jones <davej@codemonkey.org.uk>
+Cc: stable@vger.kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/ata/libata-core.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/ata/libata-core.c
++++ b/drivers/ata/libata-core.c
+@@ -4483,6 +4483,10 @@ static const struct ata_blacklist_entry
+ /* https://bugzilla.kernel.org/show_bug.cgi?id=15573 */
+ { "C300-CTFDDAC128MAG", "0001", ATA_HORKAGE_NONCQ, },
+
++ /* Some Sandisk SSDs lock up hard with NCQ enabled. Reported on
++ SD7SN6S256G and SD8SN8U256G */
++ { "SanDisk SD[78]SN*G", NULL, ATA_HORKAGE_NONCQ, },
++
+ /* devices which puke on READ_NATIVE_MAX */
+ { "HDS724040KLSA80", "KFAOA20N", ATA_HORKAGE_BROKEN_HPA, },
+ { "WDC WD3200JD-00KLB0", "WD-WCAMR1130137", ATA_HORKAGE_BROKEN_HPA },
--- /dev/null
+From 0f901dcbc31f88ae41a2aaa365f7802b5d520a28 Mon Sep 17 00:00:00 2001
+From: Andrey Ryabinin <aryabinin@virtuozzo.com>
+Date: Fri, 25 May 2018 14:47:38 -0700
+Subject: mm/kasan: don't vfree() nonexistent vm_area
+
+From: Andrey Ryabinin <aryabinin@virtuozzo.com>
+
+commit 0f901dcbc31f88ae41a2aaa365f7802b5d520a28 upstream.
+
+KASAN uses different routines to map shadow for hot added memory and
+memory obtained in boot process. Attempt to offline memory onlined by
+normal boot process leads to this:
+
+ Trying to vfree() nonexistent vm area (000000005d3b34b9)
+ WARNING: CPU: 2 PID: 13215 at mm/vmalloc.c:1525 __vunmap+0x147/0x190
+
+ Call Trace:
+ kasan_mem_notifier+0xad/0xb9
+ notifier_call_chain+0x166/0x260
+ __blocking_notifier_call_chain+0xdb/0x140
+ __offline_pages+0x96a/0xb10
+ memory_subsys_offline+0x76/0xc0
+ device_offline+0xb8/0x120
+ store_mem_state+0xfa/0x120
+ kernfs_fop_write+0x1d5/0x320
+ __vfs_write+0xd4/0x530
+ vfs_write+0x105/0x340
+ SyS_write+0xb0/0x140
+
+Obviously we can't call vfree() to free memory that wasn't allocated via
+vmalloc(). Use find_vm_area() to see if we can call vfree().
+
+Unfortunately it's a bit tricky to properly unmap and free shadow
+allocated during boot, so we'll have to keep it. If memory will come
+online again that shadow will be reused.
+
+Matthew asked: how can you call vfree() on something that isn't a
+vmalloc address?
+
+ vfree() is able to free any address returned by
+ __vmalloc_node_range(). And __vmalloc_node_range() gives you any
+ address you ask. It doesn't have to be an address in [VMALLOC_START,
+ VMALLOC_END] range.
+
+ That's also how the module_alloc()/module_memfree() works on
+ architectures that have designated area for modules.
+
+[aryabinin@virtuozzo.com: improve comments]
+ Link: http://lkml.kernel.org/r/dabee6ab-3a7a-51cd-3b86-5468718e0390@virtuozzo.com
+[akpm@linux-foundation.org: fix typos, reflow comment]
+Link: http://lkml.kernel.org/r/20180201163349.8700-1-aryabinin@virtuozzo.com
+Fixes: fa69b5989bb0 ("mm/kasan: add support for memory hotplug")
+Signed-off-by: Andrey Ryabinin <aryabinin@virtuozzo.com>
+Reported-by: Paul Menzel <pmenzel+linux-kasan-dev@molgen.mpg.de>
+Cc: Alexander Potapenko <glider@google.com>
+Cc: Dmitry Vyukov <dvyukov@google.com>
+Cc: Matthew Wilcox <willy@infradead.org>
+Cc: <stable@vger.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>
+
+---
+ mm/kasan/kasan.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++++++++--
+ 1 file changed, 61 insertions(+), 2 deletions(-)
+
+--- a/mm/kasan/kasan.c
++++ b/mm/kasan/kasan.c
+@@ -737,6 +737,40 @@ void __asan_unpoison_stack_memory(const
+ EXPORT_SYMBOL(__asan_unpoison_stack_memory);
+
+ #ifdef CONFIG_MEMORY_HOTPLUG
++static bool shadow_mapped(unsigned long addr)
++{
++ pgd_t *pgd = pgd_offset_k(addr);
++ p4d_t *p4d;
++ pud_t *pud;
++ pmd_t *pmd;
++ pte_t *pte;
++
++ if (pgd_none(*pgd))
++ return false;
++ p4d = p4d_offset(pgd, addr);
++ if (p4d_none(*p4d))
++ return false;
++ pud = pud_offset(p4d, addr);
++ if (pud_none(*pud))
++ return false;
++
++ /*
++ * We can't use pud_large() or pud_huge(), the first one is
++ * arch-specific, the last one depends on HUGETLB_PAGE. So let's abuse
++ * pud_bad(), if pud is bad then it's bad because it's huge.
++ */
++ if (pud_bad(*pud))
++ return true;
++ pmd = pmd_offset(pud, addr);
++ if (pmd_none(*pmd))
++ return false;
++
++ if (pmd_bad(*pmd))
++ return true;
++ pte = pte_offset_kernel(pmd, addr);
++ return !pte_none(*pte);
++}
++
+ static int __meminit kasan_mem_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+ {
+@@ -758,6 +792,14 @@ static int __meminit kasan_mem_notifier(
+ case MEM_GOING_ONLINE: {
+ void *ret;
+
++ /*
++ * If shadow is mapped already than it must have been mapped
++ * during the boot. This could happen if we onlining previously
++ * offlined memory.
++ */
++ if (shadow_mapped(shadow_start))
++ return NOTIFY_OK;
++
+ ret = __vmalloc_node_range(shadow_size, PAGE_SIZE, shadow_start,
+ shadow_end, GFP_KERNEL,
+ PAGE_KERNEL, VM_NO_GUARD,
+@@ -769,8 +811,25 @@ static int __meminit kasan_mem_notifier(
+ kmemleak_ignore(ret);
+ return NOTIFY_OK;
+ }
+- case MEM_OFFLINE:
+- vfree((void *)shadow_start);
++ case MEM_OFFLINE: {
++ struct vm_struct *vm;
++
++ /*
++ * shadow_start was either mapped during boot by kasan_init()
++ * or during memory online by __vmalloc_node_range().
++ * In the latter case we can use vfree() to free shadow.
++ * Non-NULL result of the find_vm_area() will tell us if
++ * that was the second case.
++ *
++ * Currently it's not possible to free shadow mapped
++ * during boot by kasan_init(). It's because the code
++ * to do that hasn't been written yet. So we'll just
++ * leak the memory.
++ */
++ vm = find_vm_area((void *)shadow_start);
++ if (vm)
++ vfree((void *)shadow_start);
++ }
+ }
+
+ return NOTIFY_OK;
--- /dev/null
+From 3de06d5a1f05c11c94cbb68af14dbfa7fb81d78b Mon Sep 17 00:00:00 2001
+From: Corneliu Doban <corneliu.doban@broadcom.com>
+Date: Fri, 18 May 2018 15:03:57 -0700
+Subject: mmc: sdhci-iproc: add SDHCI_QUIRK2_HOST_OFF_CARD_ON for cygnus
+
+From: Corneliu Doban <corneliu.doban@broadcom.com>
+
+commit 3de06d5a1f05c11c94cbb68af14dbfa7fb81d78b upstream.
+
+The SDHCI_QUIRK2_HOST_OFF_CARD_ON is needed for the driver to
+properly reset the host controller (reset all) on initialization
+after exiting deep sleep.
+
+Signed-off-by: Corneliu Doban <corneliu.doban@broadcom.com>
+Signed-off-by: Scott Branden <scott.branden@broadcom.com>
+Reviewed-by: Ray Jui <ray.jui@broadcom.com>
+Reviewed-by: Srinath Mannam <srinath.mannam@broadcom.com>
+Fixes: c833e92bbb60 ("mmc: sdhci-iproc: support standard byte register accesses")
+Cc: stable@vger.kernel.org # v4.10+
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-iproc.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/mmc/host/sdhci-iproc.c
++++ b/drivers/mmc/host/sdhci-iproc.c
+@@ -186,7 +186,7 @@ static const struct sdhci_ops sdhci_ipro
+
+ static const struct sdhci_pltfm_data sdhci_iproc_cygnus_pltfm_data = {
+ .quirks = SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK,
+- .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN,
++ .quirks2 = SDHCI_QUIRK2_ACMD23_BROKEN | SDHCI_QUIRK2_HOST_OFF_CARD_ON,
+ .ops = &sdhci_iproc_32only_ops,
+ };
+
--- /dev/null
+From 5f651b870485ee60f5abbbd85195a6852978894a Mon Sep 17 00:00:00 2001
+From: Corneliu Doban <corneliu.doban@broadcom.com>
+Date: Fri, 18 May 2018 15:03:56 -0700
+Subject: mmc: sdhci-iproc: fix 32bit writes for TRANSFER_MODE register
+
+From: Corneliu Doban <corneliu.doban@broadcom.com>
+
+commit 5f651b870485ee60f5abbbd85195a6852978894a upstream.
+
+When the host controller accepts only 32bit writes, the value of the
+16bit TRANSFER_MODE register, that has the same 32bit address as the
+16bit COMMAND register, needs to be saved and it will be written
+in a 32bit write together with the command as this will trigger the
+host to send the command on the SD interface.
+When sending the tuning command, TRANSFER_MODE is written and then
+sdhci_set_transfer_mode reads it back to clear AUTO_CMD12 bit and
+write it again resulting in wrong value to be written because the
+initial write value was saved in a shadow and the read-back returned
+a wrong value, from the register.
+Fix sdhci_iproc_readw to return the saved value of TRANSFER_MODE
+when a saved value exist.
+Same fix for read of BLOCK_SIZE and BLOCK_COUNT registers, that are
+saved for a different reason, although a scenario that will cause the
+mentioned problem on this registers is not probable.
+
+Fixes: b580c52d58d9 ("mmc: sdhci-iproc: add IPROC SDHCI driver")
+Signed-off-by: Corneliu Doban <corneliu.doban@broadcom.com>
+Signed-off-by: Scott Branden <scott.branden@broadcom.com>
+Cc: stable@vger.kernel.org # v4.1+
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-iproc.c | 30 +++++++++++++++++++++++++-----
+ 1 file changed, 25 insertions(+), 5 deletions(-)
+
+--- a/drivers/mmc/host/sdhci-iproc.c
++++ b/drivers/mmc/host/sdhci-iproc.c
+@@ -33,6 +33,8 @@ struct sdhci_iproc_host {
+ const struct sdhci_iproc_data *data;
+ u32 shadow_cmd;
+ u32 shadow_blk;
++ bool is_cmd_shadowed;
++ bool is_blk_shadowed;
+ };
+
+ #define REG_OFFSET_IN_BITS(reg) ((reg) << 3 & 0x18)
+@@ -48,8 +50,22 @@ static inline u32 sdhci_iproc_readl(stru
+
+ static u16 sdhci_iproc_readw(struct sdhci_host *host, int reg)
+ {
+- u32 val = sdhci_iproc_readl(host, (reg & ~3));
+- u16 word = val >> REG_OFFSET_IN_BITS(reg) & 0xffff;
++ struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
++ struct sdhci_iproc_host *iproc_host = sdhci_pltfm_priv(pltfm_host);
++ u32 val;
++ u16 word;
++
++ if ((reg == SDHCI_TRANSFER_MODE) && iproc_host->is_cmd_shadowed) {
++ /* Get the saved transfer mode */
++ val = iproc_host->shadow_cmd;
++ } else if ((reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) &&
++ iproc_host->is_blk_shadowed) {
++ /* Get the saved block info */
++ val = iproc_host->shadow_blk;
++ } else {
++ val = sdhci_iproc_readl(host, (reg & ~3));
++ }
++ word = val >> REG_OFFSET_IN_BITS(reg) & 0xffff;
+ return word;
+ }
+
+@@ -105,13 +121,15 @@ static void sdhci_iproc_writew(struct sd
+
+ if (reg == SDHCI_COMMAND) {
+ /* Write the block now as we are issuing a command */
+- if (iproc_host->shadow_blk != 0) {
++ if (iproc_host->is_blk_shadowed) {
+ sdhci_iproc_writel(host, iproc_host->shadow_blk,
+ SDHCI_BLOCK_SIZE);
+- iproc_host->shadow_blk = 0;
++ iproc_host->is_blk_shadowed = false;
+ }
+ oldval = iproc_host->shadow_cmd;
+- } else if (reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) {
++ iproc_host->is_cmd_shadowed = false;
++ } else if ((reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) &&
++ iproc_host->is_blk_shadowed) {
+ /* Block size and count are stored in shadow reg */
+ oldval = iproc_host->shadow_blk;
+ } else {
+@@ -123,9 +141,11 @@ static void sdhci_iproc_writew(struct sd
+ if (reg == SDHCI_TRANSFER_MODE) {
+ /* Save the transfer mode until the command is issued */
+ iproc_host->shadow_cmd = newval;
++ iproc_host->is_cmd_shadowed = true;
+ } else if (reg == SDHCI_BLOCK_SIZE || reg == SDHCI_BLOCK_COUNT) {
+ /* Save the block info until the command is issued */
+ iproc_host->shadow_blk = newval;
++ iproc_host->is_blk_shadowed = true;
+ } else {
+ /* Command or other regular 32-bit write */
+ sdhci_iproc_writel(host, newval, reg & ~3);
--- /dev/null
+From 4c94238f37af87a2165c3fb491b4a8b50e90649c Mon Sep 17 00:00:00 2001
+From: Srinath Mannam <srinath.mannam@broadcom.com>
+Date: Fri, 18 May 2018 15:03:55 -0700
+Subject: mmc: sdhci-iproc: remove hard coded mmc cap 1.8v
+
+From: Srinath Mannam <srinath.mannam@broadcom.com>
+
+commit 4c94238f37af87a2165c3fb491b4a8b50e90649c upstream.
+
+Remove hard coded mmc cap 1.8v from platform data as it is board specific.
+The 1.8v DDR mmc caps can be enabled using DTS property for those
+boards that support it.
+
+Fixes: b17b4ab8ce38 ("mmc: sdhci-iproc: define MMC caps in platform data")
+Signed-off-by: Srinath Mannam <srinath.mannam@broadcom.com>
+Signed-off-by: Scott Branden <scott.branden@broadcom.com>
+Reviewed-by: Ray Jui <ray.jui@broadcom.com>
+Cc: stable@vger.kernel.org # v4.8+
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/sdhci-iproc.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+--- a/drivers/mmc/host/sdhci-iproc.c
++++ b/drivers/mmc/host/sdhci-iproc.c
+@@ -206,7 +206,6 @@ static const struct sdhci_iproc_data ipr
+ .caps1 = SDHCI_DRIVER_TYPE_C |
+ SDHCI_DRIVER_TYPE_D |
+ SDHCI_SUPPORT_DDR50,
+- .mmc_caps = MMC_CAP_1_8V_DDR,
+ };
+
+ static const struct sdhci_pltfm_data sdhci_bcm2835_pltfm_data = {
--- /dev/null
+From faf37c44a105f3608115785f17cbbf3500f8bc71 Mon Sep 17 00:00:00 2001
+From: Michael Neuling <mikey@neuling.org>
+Date: Fri, 18 May 2018 11:37:42 +1000
+Subject: powerpc/64s: Clear PCR on boot
+
+From: Michael Neuling <mikey@neuling.org>
+
+commit faf37c44a105f3608115785f17cbbf3500f8bc71 upstream.
+
+Clear the PCR (Processor Compatibility Register) on boot to ensure we
+are not running in a compatibility mode.
+
+We've seen this cause problems when a crash (and kdump) occurs while
+running compat mode guests. The kdump kernel then runs with the PCR
+set and causes problems. The symptom in the kdump kernel (also seen in
+petitboot after fast-reboot) is early userspace programs taking
+sigills on newer instructions (seen in libc).
+
+Signed-off-by: Michael Neuling <mikey@neuling.org>
+Cc: stable@vger.kernel.org
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kernel/cpu_setup_power.S | 6 ++++++
+ arch/powerpc/kernel/dt_cpu_ftrs.c | 1 +
+ 2 files changed, 7 insertions(+)
+
+--- a/arch/powerpc/kernel/cpu_setup_power.S
++++ b/arch/powerpc/kernel/cpu_setup_power.S
+@@ -28,6 +28,7 @@ _GLOBAL(__setup_cpu_power7)
+ beqlr
+ li r0,0
+ mtspr SPRN_LPID,r0
++ mtspr SPRN_PCR,r0
+ mfspr r3,SPRN_LPCR
+ li r4,(LPCR_LPES1 >> LPCR_LPES_SH)
+ bl __init_LPCR_ISA206
+@@ -42,6 +43,7 @@ _GLOBAL(__restore_cpu_power7)
+ beqlr
+ li r0,0
+ mtspr SPRN_LPID,r0
++ mtspr SPRN_PCR,r0
+ mfspr r3,SPRN_LPCR
+ li r4,(LPCR_LPES1 >> LPCR_LPES_SH)
+ bl __init_LPCR_ISA206
+@@ -59,6 +61,7 @@ _GLOBAL(__setup_cpu_power8)
+ beqlr
+ li r0,0
+ mtspr SPRN_LPID,r0
++ mtspr SPRN_PCR,r0
+ mfspr r3,SPRN_LPCR
+ ori r3, r3, LPCR_PECEDH
+ li r4,0 /* LPES = 0 */
+@@ -81,6 +84,7 @@ _GLOBAL(__restore_cpu_power8)
+ beqlr
+ li r0,0
+ mtspr SPRN_LPID,r0
++ mtspr SPRN_PCR,r0
+ mfspr r3,SPRN_LPCR
+ ori r3, r3, LPCR_PECEDH
+ li r4,0 /* LPES = 0 */
+@@ -103,6 +107,7 @@ _GLOBAL(__setup_cpu_power9)
+ mtspr SPRN_PSSCR,r0
+ mtspr SPRN_LPID,r0
+ mtspr SPRN_PID,r0
++ mtspr SPRN_PCR,r0
+ mfspr r3,SPRN_LPCR
+ LOAD_REG_IMMEDIATE(r4, LPCR_PECEDH | LPCR_PECE_HVEE | LPCR_HVICE | LPCR_HEIC)
+ or r3, r3, r4
+@@ -128,6 +133,7 @@ _GLOBAL(__restore_cpu_power9)
+ mtspr SPRN_PSSCR,r0
+ mtspr SPRN_LPID,r0
+ mtspr SPRN_PID,r0
++ mtspr SPRN_PCR,r0
+ mfspr r3,SPRN_LPCR
+ LOAD_REG_IMMEDIATE(r4, LPCR_PECEDH | LPCR_PECE_HVEE | LPCR_HVICE | LPCR_HEIC)
+ or r3, r3, r4
+--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
++++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
+@@ -137,6 +137,7 @@ static void __restore_cpu_cpufeatures(vo
+ if (hv_mode) {
+ mtspr(SPRN_LPID, 0);
+ mtspr(SPRN_HFSCR, system_registers.hfscr);
++ mtspr(SPRN_PCR, 0);
+ }
+ mtspr(SPRN_FSCR, system_registers.fscr);
+
--- /dev/null
+From a73ab244f0dad8fffb3291b905f73e2d3eaa7c00 Mon Sep 17 00:00:00 2001
+From: Davidlohr Bueso <dave@stgolabs.net>
+Date: Fri, 25 May 2018 14:47:27 -0700
+Subject: Revert "ipc/shm: Fix shmat mmap nil-page protection"
+
+From: Davidlohr Bueso <dave@stgolabs.net>
+
+commit a73ab244f0dad8fffb3291b905f73e2d3eaa7c00 upstream.
+
+Patch series "ipc/shm: shmat() fixes around nil-page".
+
+These patches fix two issues reported[1] a while back by Joe and Andrea
+around how shmat(2) behaves with nil-page.
+
+The first reverts a commit that it was incorrectly thought that mapping
+nil-page (address=0) was a no no with MAP_FIXED. This is not the case,
+with the exception of SHM_REMAP; which is address in the second patch.
+
+I chose two patches because it is easier to backport and it explicitly
+reverts bogus behaviour. Both patches ought to be in -stable and ltp
+testcases need updated (the added testcase around the cve can be
+modified to just test for SHM_RND|SHM_REMAP).
+
+[1] lkml.kernel.org/r/20180430172152.nfa564pvgpk3ut7p@linux-n805
+
+This patch (of 2):
+
+Commit 95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection")
+worked on the idea that we should not be mapping as root addr=0 and
+MAP_FIXED. However, it was reported that this scenario is in fact
+valid, thus making the patch both bogus and breaks userspace as well.
+
+For example X11's libint10.so relies on shmat(1, SHM_RND) for lowmem
+initialization[1].
+
+[1] https://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/linux/int10/linux.c#n347
+Link: http://lkml.kernel.org/r/20180503203243.15045-2-dave@stgolabs.net
+Fixes: 95e91b831f87 ("ipc/shm: Fix shmat mmap nil-page protection")
+Signed-off-by: Davidlohr Bueso <dbueso@suse.de>
+Reported-by: Joe Lawrence <joe.lawrence@redhat.com>
+Reported-by: Andrea Arcangeli <aarcange@redhat.com>
+Cc: Manfred Spraul <manfred@colorfullife.com>
+Cc: <stable@vger.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>
+
+---
+ ipc/shm.c | 9 ++-------
+ 1 file changed, 2 insertions(+), 7 deletions(-)
+
+--- a/ipc/shm.c
++++ b/ipc/shm.c
+@@ -1309,13 +1309,8 @@ long do_shmat(int shmid, char __user *sh
+
+ if (addr) {
+ if (addr & (shmlba - 1)) {
+- /*
+- * Round down to the nearest multiple of shmlba.
+- * For sane do_mmap_pgoff() parameters, avoid
+- * round downs that trigger nil-page and MAP_FIXED.
+- */
+- if ((shmflg & SHM_RND) && addr >= shmlba)
+- addr &= ~(shmlba - 1);
++ if (shmflg & SHM_RND)
++ addr &= ~(shmlba - 1); /* round down */
+ else
+ #ifndef __ARCH_FORCE_SHMLBA
+ if (addr & ~PAGE_MASK)
aio-fix-io_destroy-2-vs.-lookup_ioctx-race.patch
alsa-timer-fix-pause-event-notification.patch
do-d_instantiate-unlock_new_inode-combinations-safely.patch
+mmc-sdhci-iproc-remove-hard-coded-mmc-cap-1.8v.patch
+mmc-sdhci-iproc-fix-32bit-writes-for-transfer_mode-register.patch
+mmc-sdhci-iproc-add-sdhci_quirk2_host_off_card_on-for-cygnus.patch
+libata-blacklist-some-sandisk-ssds-for-ncq.patch
+libata-blacklist-micron-500it-ssd-with-mu01-firmware.patch
+xen-swiotlb-fix-the-check-condition-for-xen_swiotlb_free_coherent.patch
+drm-vmwgfx-fix-32-bit-vmw_port_hb_-macros.patch
+arm64-lse-add-early-clobbers-to-some-input-output-asm-operands.patch
+powerpc-64s-clear-pcr-on-boot.patch
+ib-hfi1-use-after-free-race-condition-in-send-context-error-path.patch
+ib-umem-use-the-correct-mm-during-ib_umem_release.patch
+sr-pass-down-correctly-sized-scsi-sense-buffer.patch
+idr-fix-invalid-ptr-dereference-on-item-delete.patch
+revert-ipc-shm-fix-shmat-mmap-nil-page-protection.patch
+ipc-shm-fix-shmat-nil-address-after-round-down-when-remapping.patch
+mm-kasan-don-t-vfree-nonexistent-vm_area.patch
+kasan-free-allocated-shadow-memory-on-mem_cancel_online.patch
+kasan-fix-memory-hotplug-during-boot.patch
+kernel-sys.c-fix-potential-spectre-v1-issue.patch
--- /dev/null
+From f7068114d45ec55996b9040e98111afa56e010fe Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Mon, 21 May 2018 12:21:14 -0600
+Subject: sr: pass down correctly sized SCSI sense buffer
+
+From: Jens Axboe <axboe@kernel.dk>
+
+commit f7068114d45ec55996b9040e98111afa56e010fe upstream.
+
+We're casting the CDROM layer request_sense to the SCSI sense
+buffer, but the former is 64 bytes and the latter is 96 bytes.
+As we generally allocate these on the stack, we end up blowing
+up the stack.
+
+Fix this by wrapping the scsi_execute() call with a properly
+sized sense buffer, and copying back the bits for the CDROM
+layer.
+
+Cc: stable@vger.kernel.org
+Reported-by: Piotr Gabriel Kosinski <pg.kosinski@gmail.com>
+Reported-by: Daniel Shapira <daniel@twistlock.com>
+Tested-by: Kees Cook <keescook@chromium.org>
+Fixes: 82ed4db499b8 ("block: split scsi_request out of struct request")
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/scsi/sr_ioctl.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/drivers/scsi/sr_ioctl.c
++++ b/drivers/scsi/sr_ioctl.c
+@@ -188,9 +188,13 @@ int sr_do_ioctl(Scsi_CD *cd, struct pack
+ struct scsi_device *SDev;
+ struct scsi_sense_hdr sshdr;
+ int result, err = 0, retries = 0;
++ unsigned char sense_buffer[SCSI_SENSE_BUFFERSIZE], *senseptr = NULL;
+
+ SDev = cd->device;
+
++ if (cgc->sense)
++ senseptr = sense_buffer;
++
+ retry:
+ if (!scsi_block_when_processing_errors(SDev)) {
+ err = -ENODEV;
+@@ -198,10 +202,12 @@ int sr_do_ioctl(Scsi_CD *cd, struct pack
+ }
+
+ result = scsi_execute(SDev, cgc->cmd, cgc->data_direction,
+- cgc->buffer, cgc->buflen,
+- (unsigned char *)cgc->sense, &sshdr,
++ cgc->buffer, cgc->buflen, senseptr, &sshdr,
+ cgc->timeout, IOCTL_RETRIES, 0, 0, NULL);
+
++ if (cgc->sense)
++ memcpy(cgc->sense, sense_buffer, sizeof(*cgc->sense));
++
+ /* Minimal error checking. Ignore cases we know about, and report the rest. */
+ if (driver_byte(result) != 0) {
+ switch (sshdr.sense_key) {
--- /dev/null
+From 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 Mon Sep 17 00:00:00 2001
+From: Joe Jin <joe.jin@oracle.com>
+Date: Thu, 17 May 2018 12:33:28 -0700
+Subject: xen-swiotlb: fix the check condition for xen_swiotlb_free_coherent
+
+From: Joe Jin <joe.jin@oracle.com>
+
+commit 4855c92dbb7b3b85c23e88ab7ca04f99b9677b41 upstream.
+
+When run raidconfig from Dom0 we found that the Xen DMA heap is reduced,
+but Dom Heap is increased by the same size. Tracing raidconfig we found
+that the related ioctl() in megaraid_sas will call dma_alloc_coherent()
+to apply memory. If the memory allocated by Dom0 is not in the DMA area,
+it will exchange memory with Xen to meet the requiment. Later drivers
+call dma_free_coherent() to free the memory, on xen_swiotlb_free_coherent()
+the check condition (dev_addr + size - 1 <= dma_mask) is always false,
+it prevents calling xen_destroy_contiguous_region() to return the memory
+to the Xen DMA heap.
+
+This issue introduced by commit 6810df88dcfc2 "xen-swiotlb: When doing
+coherent alloc/dealloc check before swizzling the MFNs.".
+
+Signed-off-by: Joe Jin <joe.jin@oracle.com>
+Tested-by: John Sobecki <john.sobecki@oracle.com>
+Reviewed-by: Rzeszutek Wilk <konrad.wilk@oracle.com>
+Cc: stable@vger.kernel.org
+Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/xen/swiotlb-xen.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/xen/swiotlb-xen.c
++++ b/drivers/xen/swiotlb-xen.c
+@@ -365,7 +365,7 @@ xen_swiotlb_free_coherent(struct device
+ * physical address */
+ phys = xen_bus_to_phys(dev_addr);
+
+- if (((dev_addr + size - 1 > dma_mask)) ||
++ if (((dev_addr + size - 1 <= dma_mask)) ||
+ range_straddles_page_boundary(phys, size))
+ xen_destroy_contiguous_region(phys, order);
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
