--- /dev/null
+From 96a85cc517a9ee4ae5e8d7f5a36cba05023784eb Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Thu, 14 Jun 2018 20:56:25 +0300
+Subject: drm/i915: Fix hotplug irq ack on i965/g4x
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Ville Syrjälä <ville.syrjala@linux.intel.com>
+
+commit 96a85cc517a9ee4ae5e8d7f5a36cba05023784eb upstream.
+
+Just like with PIPESTAT, the edge triggered IIR on i965/g4x
+also causes problems for hotplug interrupts. To make sure
+we don't get the IIR port interrupt bit stuck low with the
+ISR bit high we must force an edge in ISR. Unfortunately
+we can't borrow the PIPESTAT trick and toggle the enable
+bits in PORT_HOTPLUG_EN as that act itself generates hotplug
+interrupts. Instead we just have to loop until we've cleared
+PORT_HOTPLUG_STAT, or we just give up and WARN.
+
+v2: Don't frob with PORT_HOTPLUG_EN
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20180614175625.1615-1-ville.syrjala@linux.intel.com
+Reviewed-by: Imre Deak <imre.deak@intel.com>
+(cherry picked from commit 0ba7c51a6fd80a89236f6ceb52e63f8a7f62bfd3)
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_irq.c | 32 ++++++++++++++++++++++++++++++--
+ 1 file changed, 30 insertions(+), 2 deletions(-)
+
+--- a/drivers/gpu/drm/i915/i915_irq.c
++++ b/drivers/gpu/drm/i915/i915_irq.c
+@@ -1684,10 +1684,38 @@ static void valleyview_pipestat_irq_hand
+
+ static u32 i9xx_hpd_irq_ack(struct drm_i915_private *dev_priv)
+ {
+- u32 hotplug_status = I915_READ(PORT_HOTPLUG_STAT);
++ u32 hotplug_status = 0, hotplug_status_mask;
++ int i;
+
+- if (hotplug_status)
++ if (IS_G4X(dev_priv) ||
++ IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
++ hotplug_status_mask = HOTPLUG_INT_STATUS_G4X |
++ DP_AUX_CHANNEL_MASK_INT_STATUS_G4X;
++ else
++ hotplug_status_mask = HOTPLUG_INT_STATUS_I915;
++
++ /*
++ * We absolutely have to clear all the pending interrupt
++ * bits in PORT_HOTPLUG_STAT. Otherwise the ISR port
++ * interrupt bit won't have an edge, and the i965/g4x
++ * edge triggered IIR will not notice that an interrupt
++ * is still pending. We can't use PORT_HOTPLUG_EN to
++ * guarantee the edge as the act of toggling the enable
++ * bits can itself generate a new hotplug interrupt :(
++ */
++ for (i = 0; i < 10; i++) {
++ u32 tmp = I915_READ(PORT_HOTPLUG_STAT) & hotplug_status_mask;
++
++ if (tmp == 0)
++ return hotplug_status;
++
++ hotplug_status |= tmp;
+ I915_WRITE(PORT_HOTPLUG_STAT, hotplug_status);
++ }
++
++ WARN_ONCE(1,
++ "PORT_HOTPLUG_STAT did not clear (0x%08x)\n",
++ I915_READ(PORT_HOTPLUG_STAT));
+
+ return hotplug_status;
+ }
--- /dev/null
+From e1f1b1572e8db87a56609fd05bef76f98f0e456a Mon Sep 17 00:00:00 2001
+From: Hugh Dickins <hughd@google.com>
+Date: Fri, 20 Jul 2018 17:53:45 -0700
+Subject: mm/huge_memory.c: fix data loss when splitting a file pmd
+
+From: Hugh Dickins <hughd@google.com>
+
+commit e1f1b1572e8db87a56609fd05bef76f98f0e456a upstream.
+
+__split_huge_pmd_locked() must check if the cleared huge pmd was dirty,
+and propagate that to PageDirty: otherwise, data may be lost when a huge
+tmpfs page is modified then split then reclaimed.
+
+How has this taken so long to be noticed? Because there was no problem
+when the huge page is written by a write system call (shmem_write_end()
+calls set_page_dirty()), nor when the page is allocated for a write fault
+(fault_dirty_shared_page() calls set_page_dirty()); but when allocated for
+a read fault (which MAP_POPULATE simulates), no set_page_dirty().
+
+Link: http://lkml.kernel.org/r/alpine.LSU.2.11.1807111741430.1106@eggly.anvils
+Fixes: d21b9e57c74c ("thp: handle file pages in split_huge_pmd()")
+Signed-off-by: Hugh Dickins <hughd@google.com>
+Reported-by: Ashwin Chaugule <ashwinch@google.com>
+Reviewed-by: Yang Shi <yang.shi@linux.alibaba.com>
+Reviewed-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
+Cc: "Huang, Ying" <ying.huang@intel.com>
+Cc: <stable@vger.kernel.org> [4.8+]
+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/huge_memory.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/mm/huge_memory.c
++++ b/mm/huge_memory.c
+@@ -1642,6 +1642,8 @@ static void __split_huge_pmd_locked(stru
+ if (vma_is_dax(vma))
+ return;
+ page = pmd_page(_pmd);
++ if (!PageDirty(page) && pmd_dirty(_pmd))
++ set_page_dirty(page);
+ if (!PageReferenced(page) && pmd_young(_pmd))
+ SetPageReferenced(page);
+ page_remove_rmap(page, true);
--- /dev/null
+From 9f15bde671355c351cf20d9f879004b234353100 Mon Sep 17 00:00:00 2001
+From: Jing Xia <jing.xia.mail@gmail.com>
+Date: Fri, 20 Jul 2018 17:53:48 -0700
+Subject: mm: memcg: fix use after free in mem_cgroup_iter()
+
+From: Jing Xia <jing.xia.mail@gmail.com>
+
+commit 9f15bde671355c351cf20d9f879004b234353100 upstream.
+
+It was reported that a kernel crash happened in mem_cgroup_iter(), which
+can be triggered if the legacy cgroup-v1 non-hierarchical mode is used.
+
+Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b8f
+......
+Call trace:
+ mem_cgroup_iter+0x2e0/0x6d4
+ shrink_zone+0x8c/0x324
+ balance_pgdat+0x450/0x640
+ kswapd+0x130/0x4b8
+ kthread+0xe8/0xfc
+ ret_from_fork+0x10/0x20
+
+ mem_cgroup_iter():
+ ......
+ if (css_tryget(css)) <-- crash here
+ break;
+ ......
+
+The crashing reason is that mem_cgroup_iter() uses the memcg object whose
+pointer is stored in iter->position, which has been freed before and
+filled with POISON_FREE(0x6b).
+
+And the root cause of the use-after-free issue is that
+invalidate_reclaim_iterators() fails to reset the value of iter->position
+to NULL when the css of the memcg is released in non- hierarchical mode.
+
+Link: http://lkml.kernel.org/r/1531994807-25639-1-git-send-email-jing.xia@unisoc.com
+Fixes: 6df38689e0e9 ("mm: memcontrol: fix possible memcg leak due to interrupted reclaim")
+Signed-off-by: Jing Xia <jing.xia.mail@gmail.com>
+Acked-by: Michal Hocko <mhocko@suse.com>
+Cc: Johannes Weiner <hannes@cmpxchg.org>
+Cc: Vladimir Davydov <vdavydov.dev@gmail.com>
+Cc: <chunyan.zhang@unisoc.com>
+Cc: Shakeel Butt <shakeelb@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/memcontrol.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/mm/memcontrol.c
++++ b/mm/memcontrol.c
+@@ -895,7 +895,7 @@ static void invalidate_reclaim_iterators
+ int nid;
+ int i;
+
+- while ((memcg = parent_mem_cgroup(memcg))) {
++ for (; memcg; memcg = parent_mem_cgroup(memcg)) {
+ for_each_node(nid) {
+ mz = mem_cgroup_nodeinfo(memcg, nid);
+ for (i = 0; i <= DEF_PRIORITY; i++) {
arc-fix-config_swap.patch
arc-mm-allow-mprotect-to-make-stack-mappings-executable.patch
arc-configs-remove-config_initramfs_source-from-defconfigs.patch
+mm-memcg-fix-use-after-free-in-mem_cgroup_iter.patch
+mm-huge_memory.c-fix-data-loss-when-splitting-a-file-pmd.patch
+vfio-pci-fix-potential-spectre-v1.patch
+drm-i915-fix-hotplug-irq-ack-on-i965-g4x.patch
--- /dev/null
+From 0e714d27786ce1fb3efa9aac58abc096e68b1c2a Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavo@embeddedor.com>
+Date: Tue, 17 Jul 2018 12:39:00 -0500
+Subject: vfio/pci: Fix potential Spectre v1
+
+From: Gustavo A. R. Silva <gustavo@embeddedor.com>
+
+commit 0e714d27786ce1fb3efa9aac58abc096e68b1c2a upstream.
+
+info.index can be indirectly 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:
+
+drivers/vfio/pci/vfio_pci.c:734 vfio_pci_ioctl()
+warn: potential spectre issue 'vdev->region'
+
+Fix this by sanitizing info.index before indirectly using it to index
+vdev->region
+
+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
+
+Cc: stable@vger.kernel.org
+Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
+Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/vfio/pci/vfio_pci.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+--- a/drivers/vfio/pci/vfio_pci.c
++++ b/drivers/vfio/pci/vfio_pci.c
+@@ -28,6 +28,7 @@
+ #include <linux/uaccess.h>
+ #include <linux/vfio.h>
+ #include <linux/vgaarb.h>
++#include <linux/nospec.h>
+
+ #include "vfio_pci_private.h"
+
+@@ -755,6 +756,9 @@ static long vfio_pci_ioctl(void *device_
+ if (info.index >=
+ VFIO_PCI_NUM_REGIONS + vdev->num_regions)
+ return -EINVAL;
++ info.index = array_index_nospec(info.index,
++ VFIO_PCI_NUM_REGIONS +
++ vdev->num_regions);
+
+ i = info.index - VFIO_PCI_NUM_REGIONS;
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
