--- /dev/null
+From 9a00674213a3f00394f4e3221b88f2d21fc05789 Mon Sep 17 00:00:00 2001
+From: Eric Biggers <ebiggers@google.com>
+Date: Fri, 29 Dec 2017 14:30:19 -0600
+Subject: crypto: algapi - fix NULL dereference in crypto_remove_spawns()
+
+From: Eric Biggers <ebiggers@google.com>
+
+commit 9a00674213a3f00394f4e3221b88f2d21fc05789 upstream.
+
+syzkaller triggered a NULL pointer dereference in crypto_remove_spawns()
+via a program that repeatedly and concurrently requests AEADs
+"authenc(cmac(des3_ede-asm),pcbc-aes-aesni)" and hashes "cmac(des3_ede)"
+through AF_ALG, where the hashes are requested as "untested"
+(CRYPTO_ALG_TESTED is set in ->salg_mask but clear in ->salg_feat; this
+causes the template to be instantiated for every request).
+
+Although AF_ALG users really shouldn't be able to request an "untested"
+algorithm, the NULL pointer dereference is actually caused by a
+longstanding race condition where crypto_remove_spawns() can encounter
+an instance which has had spawn(s) "grabbed" but hasn't yet been
+registered, resulting in ->cra_users still being NULL.
+
+We probably should properly initialize ->cra_users earlier, but that
+would require updating many templates individually. For now just fix
+the bug in a simple way that can easily be backported: make
+crypto_remove_spawns() treat a NULL ->cra_users list as empty.
+
+Reported-by: syzbot <syzkaller@googlegroups.com>
+Signed-off-by: Eric Biggers <ebiggers@google.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ crypto/algapi.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/crypto/algapi.c
++++ b/crypto/algapi.c
+@@ -167,6 +167,18 @@ void crypto_remove_spawns(struct crypto_
+
+ spawn->alg = NULL;
+ spawns = &inst->alg.cra_users;
++
++ /*
++ * We may encounter an unregistered instance here, since
++ * an instance's spawns are set up prior to the instance
++ * being registered. An unregistered instance will have
++ * NULL ->cra_users.next, since ->cra_users isn't
++ * properly initialized until registration. But an
++ * unregistered instance cannot have any users, so treat
++ * it the same as ->cra_users being empty.
++ */
++ if (spawns->next == NULL)
++ break;
+ }
+ } while ((spawns = crypto_more_spawns(alg, &stack, &top,
+ &secondary_spawns)));
--- /dev/null
+From 3572f04c69ed4369da5d3c65d84fb18774aa60b6 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Thu, 16 Nov 2017 18:02:15 +0200
+Subject: drm/i915: Fix init_clock_gating for resume
+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 3572f04c69ed4369da5d3c65d84fb18774aa60b6 upstream.
+
+Moving the init_clock_gating() call from intel_modeset_init_hw() to
+intel_modeset_gem_init() had an unintended effect of not applying
+some workarounds on resume. This, for example, cause some kind of
+corruption to appear at the top of my IVB Thinkpad X1 Carbon LVDS
+screen after hibernation. Fix the problem by explicitly calling
+init_clock_gating() from the resume path.
+
+I really hope this doesn't break something else again. At least
+the problems reported at https://bugs.freedesktop.org/show_bug.cgi?id=103549
+didn't make a comeback, even after a hibernate cycle.
+
+v2: Reorder the init_clock_gating vs. modeset_init_hw to match
+ the display reset path (Rodrigo)
+
+Cc: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Fixes: 6ac43272768c ("drm/i915: Move init_clock_gating() back to where it was")
+Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+Link: https://patchwork.freedesktop.org/patch/msgid/20171116160215.25715-1-ville.syrjala@linux.intel.com
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+(cherry picked from commit 675f7ff35bd256e65d3d0f52718d8babf5d1002a)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_drv.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/gpu/drm/i915/i915_drv.c
++++ b/drivers/gpu/drm/i915/i915_drv.c
+@@ -1693,6 +1693,7 @@ static int i915_drm_resume(struct drm_de
+ intel_guc_resume(dev_priv);
+
+ intel_modeset_init_hw(dev);
++ intel_init_clock_gating(dev_priv);
+
+ spin_lock_irq(&dev_priv->irq_lock);
+ if (dev_priv->display.hpd_irq_setup)
--- /dev/null
+From 121d760d0788f95619049c63449d977065cab69d Mon Sep 17 00:00:00 2001
+From: Zhi Wang <zhi.a.wang@intel.com>
+Date: Fri, 29 Dec 2017 02:50:08 +0800
+Subject: drm/i915/gvt: Clear the shadow page table entry after post-sync
+
+From: Zhi Wang <zhi.a.wang@intel.com>
+
+commit 121d760d0788f95619049c63449d977065cab69d upstream.
+
+A shadow page table entry needs to be cleared after being set as
+post-sync. This patch fixes the recent error reported in Win7-32 test.
+
+Fixes: 2707e4446688 ("drm/i915/gvt: vGPU graphics memory virtualization")
+Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
+Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/gvt/gtt.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+--- a/drivers/gpu/drm/i915/gvt/gtt.c
++++ b/drivers/gpu/drm/i915/gvt/gtt.c
+@@ -1359,12 +1359,15 @@ static int ppgtt_handle_guest_write_page
+ return ret;
+ } else {
+ if (!test_bit(index, spt->post_shadow_bitmap)) {
++ int type = spt->shadow_page.type;
++
+ ppgtt_get_shadow_entry(spt, &se, index);
+ ret = ppgtt_handle_guest_entry_removal(gpt, &se, index);
+ if (ret)
+ return ret;
++ ops->set_pfn(&se, vgpu->gtt.scratch_pt[type].page_mfn);
++ ppgtt_set_shadow_entry(spt, &se, index);
+ }
+-
+ ppgtt_set_post_shadow(spt, index);
+ }
+
--- /dev/null
+From 6ac43272768ca901daac4076a66c2c4e3c7b9321 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala@linux.intel.com>
+Date: Wed, 8 Nov 2017 15:35:55 +0200
+Subject: drm/i915: Move init_clock_gating() back to where it was
+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 6ac43272768ca901daac4076a66c2c4e3c7b9321 upstream.
+
+Apparently setting up a bunch of GT registers before we've properly
+initialized the rest of the GT hardware leads to these setting being
+lost. So looks like I broke HSW with commit b7048ea12fbb ("drm/i915:
+Do .init_clock_gating() earlier to avoid it clobbering watermarks")
+by doing init_clock_gating() too early. This should actually affect
+other platforms as well, but apparently not to such a great degree.
+
+What I was ultimately after in that commit was to move the
+ilk_init_lp_watermarks() call earlier. So let's undo the damage and
+move init_clock_gating() back to where it was, and call
+ilk_init_lp_watermarks() just before the watermark state readout.
+
+This highlights how fragile and messed up our init order really is.
+I wonder why we even initialize the display before gem. The opposite
+order would make much more sense to me...
+
+v2: Keep WaRsPkgCStateDisplayPMReq:hsw early as it really must
+ be done before all planes might get disabled.
+
+Cc: Chris Wilson <chris@chris-wilson.co.uk>
+Cc: Mark Janes <mark.a.janes@intel.com>
+Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
+Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
+Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
+Cc: Oscar Mateo <oscar.mateo@intel.com>
+Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
+Reported-by: Mark Janes <mark.a.janes@intel.com>
+Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103549
+Fixes: b7048ea12fbb ("drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks")
+References: https://lists.freedesktop.org/archives/intel-gfx/2017-November/145432.html
+Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20171108133555.14091-1-ville.syrjala@linux.intel.com
+Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
+Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
+(cherry picked from commit f72b84c677d61f201b869223a8d6e389c7bb7d3d)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+
+---
+ drivers/gpu/drm/i915/intel_display.c | 14 +++++++++--
+ drivers/gpu/drm/i915/intel_pm.c | 44 ++++++++++++++---------------------
+ 2 files changed, 30 insertions(+), 28 deletions(-)
+
+--- a/drivers/gpu/drm/i915/intel_display.c
++++ b/drivers/gpu/drm/i915/intel_display.c
+@@ -3800,6 +3800,7 @@ void intel_finish_reset(struct drm_i915_
+
+ intel_pps_unlock_regs_wa(dev_priv);
+ intel_modeset_init_hw(dev);
++ intel_init_clock_gating(dev_priv);
+
+ spin_lock_irq(&dev_priv->irq_lock);
+ if (dev_priv->display.hpd_irq_setup)
+@@ -14406,8 +14407,6 @@ void intel_modeset_init_hw(struct drm_de
+
+ intel_update_cdclk(dev_priv);
+ dev_priv->cdclk.logical = dev_priv->cdclk.actual = dev_priv->cdclk.hw;
+-
+- intel_init_clock_gating(dev_priv);
+ }
+
+ /*
+@@ -15124,6 +15123,15 @@ intel_modeset_setup_hw_state(struct drm_
+ struct intel_encoder *encoder;
+ int i;
+
++ if (IS_HASWELL(dev_priv)) {
++ /*
++ * WaRsPkgCStateDisplayPMReq:hsw
++ * System hang if this isn't done before disabling all planes!
++ */
++ I915_WRITE(CHICKEN_PAR1_1,
++ I915_READ(CHICKEN_PAR1_1) | FORCE_ARB_IDLE_PLANES);
++ }
++
+ intel_modeset_readout_hw_state(dev);
+
+ /* HW state is read out, now we need to sanitize this mess. */
+@@ -15220,6 +15228,8 @@ void intel_modeset_gem_init(struct drm_d
+
+ intel_init_gt_powersave(dev_priv);
+
++ intel_init_clock_gating(dev_priv);
++
+ intel_setup_overlay(dev_priv);
+ }
+
+--- a/drivers/gpu/drm/i915/intel_pm.c
++++ b/drivers/gpu/drm/i915/intel_pm.c
+@@ -5669,12 +5669,30 @@ void vlv_wm_sanitize(struct drm_i915_pri
+ mutex_unlock(&dev_priv->wm.wm_mutex);
+ }
+
++/*
++ * FIXME should probably kill this and improve
++ * the real watermark readout/sanitation instead
++ */
++static void ilk_init_lp_watermarks(struct drm_i915_private *dev_priv)
++{
++ I915_WRITE(WM3_LP_ILK, I915_READ(WM3_LP_ILK) & ~WM1_LP_SR_EN);
++ I915_WRITE(WM2_LP_ILK, I915_READ(WM2_LP_ILK) & ~WM1_LP_SR_EN);
++ I915_WRITE(WM1_LP_ILK, I915_READ(WM1_LP_ILK) & ~WM1_LP_SR_EN);
++
++ /*
++ * Don't touch WM1S_LP_EN here.
++ * Doing so could cause underruns.
++ */
++}
++
+ void ilk_wm_get_hw_state(struct drm_device *dev)
+ {
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct ilk_wm_values *hw = &dev_priv->wm.hw;
+ struct drm_crtc *crtc;
+
++ ilk_init_lp_watermarks(dev_priv);
++
+ for_each_crtc(dev, crtc)
+ ilk_pipe_wm_get_hw_state(crtc);
+
+@@ -7959,18 +7977,6 @@ static void g4x_disable_trickle_feed(str
+ }
+ }
+
+-static void ilk_init_lp_watermarks(struct drm_i915_private *dev_priv)
+-{
+- I915_WRITE(WM3_LP_ILK, I915_READ(WM3_LP_ILK) & ~WM1_LP_SR_EN);
+- I915_WRITE(WM2_LP_ILK, I915_READ(WM2_LP_ILK) & ~WM1_LP_SR_EN);
+- I915_WRITE(WM1_LP_ILK, I915_READ(WM1_LP_ILK) & ~WM1_LP_SR_EN);
+-
+- /*
+- * Don't touch WM1S_LP_EN here.
+- * Doing so could cause underruns.
+- */
+-}
+-
+ static void ironlake_init_clock_gating(struct drm_i915_private *dev_priv)
+ {
+ uint32_t dspclk_gate = ILK_VRHUNIT_CLOCK_GATE_DISABLE;
+@@ -8004,8 +8010,6 @@ static void ironlake_init_clock_gating(s
+ (I915_READ(DISP_ARB_CTL) |
+ DISP_FBC_WM_DIS));
+
+- ilk_init_lp_watermarks(dev_priv);
+-
+ /*
+ * Based on the document from hardware guys the following bits
+ * should be set unconditionally in order to enable FBC.
+@@ -8118,8 +8122,6 @@ static void gen6_init_clock_gating(struc
+ I915_WRITE(GEN6_GT_MODE,
+ _MASKED_FIELD(GEN6_WIZ_HASHING_MASK, GEN6_WIZ_HASHING_16x4));
+
+- ilk_init_lp_watermarks(dev_priv);
+-
+ I915_WRITE(CACHE_MODE_0,
+ _MASKED_BIT_DISABLE(CM0_STC_EVICT_DISABLE_LRA_SNB));
+
+@@ -8293,8 +8295,6 @@ static void broadwell_init_clock_gating(
+ {
+ enum pipe pipe;
+
+- ilk_init_lp_watermarks(dev_priv);
+-
+ /* WaSwitchSolVfFArbitrationPriority:bdw */
+ I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL);
+
+@@ -8349,8 +8349,6 @@ static void broadwell_init_clock_gating(
+
+ static void haswell_init_clock_gating(struct drm_i915_private *dev_priv)
+ {
+- ilk_init_lp_watermarks(dev_priv);
+-
+ /* L3 caching of data atomics doesn't work -- disable it. */
+ I915_WRITE(HSW_SCRATCH1, HSW_SCRATCH1_L3_DATA_ATOMICS_DISABLE);
+ I915_WRITE(HSW_ROW_CHICKEN3,
+@@ -8394,10 +8392,6 @@ static void haswell_init_clock_gating(st
+ /* WaSwitchSolVfFArbitrationPriority:hsw */
+ I915_WRITE(GAM_ECOCHK, I915_READ(GAM_ECOCHK) | HSW_ECOCHK_ARB_PRIO_SOL);
+
+- /* WaRsPkgCStateDisplayPMReq:hsw */
+- I915_WRITE(CHICKEN_PAR1_1,
+- I915_READ(CHICKEN_PAR1_1) | FORCE_ARB_IDLE_PLANES);
+-
+ lpt_init_clock_gating(dev_priv);
+ }
+
+@@ -8405,8 +8399,6 @@ static void ivybridge_init_clock_gating(
+ {
+ uint32_t snpcr;
+
+- ilk_init_lp_watermarks(dev_priv);
+-
+ I915_WRITE(ILK_DSPCLK_GATE_D, ILK_VRHUNIT_CLOCK_GATE_DISABLE);
+
+ /* WaDisableEarlyCull:ivb */
--- /dev/null
+From 4636bda86aa1f34f45c629477476a0dcfa04e597 Mon Sep 17 00:00:00 2001
+From: Kenneth Graunke <kenneth@whitecape.org>
+Date: Fri, 5 Jan 2018 00:59:05 -0800
+Subject: drm/i915: Whitelist SLICE_COMMON_ECO_CHICKEN1 on Geminilake.
+
+From: Kenneth Graunke <kenneth@whitecape.org>
+
+commit 4636bda86aa1f34f45c629477476a0dcfa04e597 upstream.
+
+Geminilake requires the 3D driver to select whether barriers are
+intended for compute shaders, or tessellation control shaders, by
+whacking a "Barrier Mode" bit in SLICE_COMMON_ECO_CHICKEN1 when
+switching pipelines. Failure to do this properly can result in GPU
+hangs.
+
+Unfortunately, this means it needs to switch mid-batch, so only
+userspace can properly set it. To facilitate this, the kernel needs
+to whitelist the register.
+
+The workarounds page currently tags this as applying to Broxton only,
+but that doesn't make sense. The documentation for the register it
+references says the bit userspace is supposed to toggle only exists on
+Geminilake. Empirically, the Mesa patch to toggle this bit appears to
+fix intermittent GPU hangs in tessellation control shader barrier tests
+on Geminilake; we haven't seen those hangs on Broxton.
+
+v2: Mention WA #0862 in the comment (it doesn't have a name).
+
+Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
+Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20180105085905.9298-1-kenneth@whitecape.org
+(cherry picked from commit ab062639edb0412daf6de540725276b9a5d217f9)
+Signed-off-by: Jani Nikula <jani.nikula@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/i915/i915_reg.h | 2 ++
+ drivers/gpu/drm/i915/intel_engine_cs.c | 5 +++++
+ 2 files changed, 7 insertions(+)
+
+--- a/drivers/gpu/drm/i915/i915_reg.h
++++ b/drivers/gpu/drm/i915/i915_reg.h
+@@ -6987,6 +6987,8 @@ enum {
+ #define GEN9_SLICE_COMMON_ECO_CHICKEN0 _MMIO(0x7308)
+ #define DISABLE_PIXEL_MASK_CAMMING (1<<14)
+
++#define GEN9_SLICE_COMMON_ECO_CHICKEN1 _MMIO(0x731c)
++
+ #define GEN7_L3SQCREG1 _MMIO(0xB010)
+ #define VLV_B0_WA_L3SQCREG1_VALUE 0x00D30000
+
+--- a/drivers/gpu/drm/i915/intel_engine_cs.c
++++ b/drivers/gpu/drm/i915/intel_engine_cs.c
+@@ -1125,6 +1125,11 @@ static int glk_init_workarounds(struct i
+ if (ret)
+ return ret;
+
++ /* WA #0862: Userspace has to set "Barrier Mode" to avoid hangs. */
++ ret = wa_ring_whitelist_reg(engine, GEN9_SLICE_COMMON_ECO_CHICKEN1);
++ if (ret)
++ return ret;
++
+ /* WaToEnableHwFixForPushConstHWBug:glk */
+ WA_SET_BIT_MASKED(COMMON_SLICE_CHICKEN2,
+ GEN8_SBE_DISABLE_REPLAY_BUF_OPTIMIZATION);
--- /dev/null
+From 98648ae6ef6bdcdcb88c46cad963906ab452e96d Mon Sep 17 00:00:00 2001
+From: Thomas Hellstrom <thellstrom@vmware.com>
+Date: Tue, 9 Jan 2018 15:33:42 +0100
+Subject: drm/vmwgfx: Don't cache framebuffer maps
+
+From: Thomas Hellstrom <thellstrom@vmware.com>
+
+commit 98648ae6ef6bdcdcb88c46cad963906ab452e96d upstream.
+
+Buffer objects need to be either pinned or reserved while a map is active,
+that's not the case here, so avoid caching the framebuffer map.
+This will cause increasing mapping activity mainly when we don't do
+page flipping.
+
+This fixes occasional garbage filled screens when the framebuffer has been
+evicted after the map.
+
+Since in-kernel mapping of whole buffer objects is error-prone on 32-bit
+architectures and also quite inefficient, we will revisit this later.
+
+Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
+Reviewed-by: Sinclair Yeh <syeh@vmware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 6 -----
+ drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 2 -
+ drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 41 ++++++++++-------------------------
+ 3 files changed, 13 insertions(+), 36 deletions(-)
+
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+@@ -697,7 +697,6 @@ vmw_du_plane_duplicate_state(struct drm_
+ vps->pinned = 0;
+
+ /* Mapping is managed by prepare_fb/cleanup_fb */
+- memset(&vps->guest_map, 0, sizeof(vps->guest_map));
+ memset(&vps->host_map, 0, sizeof(vps->host_map));
+ vps->cpp = 0;
+
+@@ -760,11 +759,6 @@ vmw_du_plane_destroy_state(struct drm_pl
+
+
+ /* Should have been freed by cleanup_fb */
+- if (vps->guest_map.virtual) {
+- DRM_ERROR("Guest mapping not freed\n");
+- ttm_bo_kunmap(&vps->guest_map);
+- }
+-
+ if (vps->host_map.virtual) {
+ DRM_ERROR("Host mapping not freed\n");
+ ttm_bo_kunmap(&vps->host_map);
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+@@ -175,7 +175,7 @@ struct vmw_plane_state {
+ int pinned;
+
+ /* For CPU Blit */
+- struct ttm_bo_kmap_obj host_map, guest_map;
++ struct ttm_bo_kmap_obj host_map;
+ unsigned int cpp;
+ };
+
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+@@ -114,7 +114,7 @@ struct vmw_screen_target_display_unit {
+ bool defined;
+
+ /* For CPU Blit */
+- struct ttm_bo_kmap_obj host_map, guest_map;
++ struct ttm_bo_kmap_obj host_map;
+ unsigned int cpp;
+ };
+
+@@ -695,7 +695,8 @@ static void vmw_stdu_dmabuf_cpu_commit(s
+ s32 src_pitch, dst_pitch;
+ u8 *src, *dst;
+ bool not_used;
+-
++ struct ttm_bo_kmap_obj guest_map;
++ int ret;
+
+ if (!dirty->num_hits)
+ return;
+@@ -706,6 +707,13 @@ static void vmw_stdu_dmabuf_cpu_commit(s
+ if (width == 0 || height == 0)
+ return;
+
++ ret = ttm_bo_kmap(&ddirty->buf->base, 0, ddirty->buf->base.num_pages,
++ &guest_map);
++ if (ret) {
++ DRM_ERROR("Failed mapping framebuffer for blit: %d\n",
++ ret);
++ goto out_cleanup;
++ }
+
+ /* Assume we are blitting from Host (display_srf) to Guest (dmabuf) */
+ src_pitch = stdu->display_srf->base_size.width * stdu->cpp;
+@@ -713,7 +721,7 @@ static void vmw_stdu_dmabuf_cpu_commit(s
+ src += ddirty->top * src_pitch + ddirty->left * stdu->cpp;
+
+ dst_pitch = ddirty->pitch;
+- dst = ttm_kmap_obj_virtual(&stdu->guest_map, ¬_used);
++ dst = ttm_kmap_obj_virtual(&guest_map, ¬_used);
+ dst += ddirty->fb_top * dst_pitch + ddirty->fb_left * stdu->cpp;
+
+
+@@ -772,6 +780,7 @@ static void vmw_stdu_dmabuf_cpu_commit(s
+ vmw_fifo_commit(dev_priv, sizeof(*cmd));
+ }
+
++ ttm_bo_kunmap(&guest_map);
+ out_cleanup:
+ ddirty->left = ddirty->top = ddirty->fb_left = ddirty->fb_top = S32_MAX;
+ ddirty->right = ddirty->bottom = S32_MIN;
+@@ -1109,9 +1118,6 @@ vmw_stdu_primary_plane_cleanup_fb(struct
+ {
+ struct vmw_plane_state *vps = vmw_plane_state_to_vps(old_state);
+
+- if (vps->guest_map.virtual)
+- ttm_bo_kunmap(&vps->guest_map);
+-
+ if (vps->host_map.virtual)
+ ttm_bo_kunmap(&vps->host_map);
+
+@@ -1277,33 +1283,11 @@ vmw_stdu_primary_plane_prepare_fb(struct
+ */
+ if (vps->content_fb_type == SEPARATE_DMA &&
+ !(dev_priv->capabilities & SVGA_CAP_3D)) {
+-
+- struct vmw_framebuffer_dmabuf *new_vfbd;
+-
+- new_vfbd = vmw_framebuffer_to_vfbd(new_fb);
+-
+- ret = ttm_bo_reserve(&new_vfbd->buffer->base, false, false,
+- NULL);
+- if (ret)
+- goto out_srf_unpin;
+-
+- ret = ttm_bo_kmap(&new_vfbd->buffer->base, 0,
+- new_vfbd->buffer->base.num_pages,
+- &vps->guest_map);
+-
+- ttm_bo_unreserve(&new_vfbd->buffer->base);
+-
+- if (ret) {
+- DRM_ERROR("Failed to map content buffer to CPU\n");
+- goto out_srf_unpin;
+- }
+-
+ ret = ttm_bo_kmap(&vps->surf->res.backup->base, 0,
+ vps->surf->res.backup->base.num_pages,
+ &vps->host_map);
+ if (ret) {
+ DRM_ERROR("Failed to map display buffer to CPU\n");
+- ttm_bo_kunmap(&vps->guest_map);
+ goto out_srf_unpin;
+ }
+
+@@ -1350,7 +1334,6 @@ vmw_stdu_primary_plane_atomic_update(str
+ stdu->display_srf = vps->surf;
+ stdu->content_fb_type = vps->content_fb_type;
+ stdu->cpp = vps->cpp;
+- memcpy(&stdu->guest_map, &vps->guest_map, sizeof(vps->guest_map));
+ memcpy(&stdu->host_map, &vps->host_map, sizeof(vps->host_map));
+
+ if (!stdu->defined)
--- /dev/null
+From 0d9cac0ca0429830c40fe1a4e50e60f6221fd7b6 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@oracle.com>
+Date: Wed, 10 Jan 2018 12:40:04 +0300
+Subject: drm/vmwgfx: Potential off by one in vmw_view_add()
+
+From: Dan Carpenter <dan.carpenter@oracle.com>
+
+commit 0d9cac0ca0429830c40fe1a4e50e60f6221fd7b6 upstream.
+
+The vmw_view_cmd_to_type() function returns vmw_view_max (3) on error.
+It's one element beyond the end of the vmw_view_cotables[] table.
+
+My read on this is that it's possible to hit this failure. header->id
+comes from vmw_cmd_check() and it's a user controlled number between
+1040 and 1225 so we can hit that error. But I don't have the hardware
+to test this code.
+
+Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
+Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
+Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+@@ -2731,6 +2731,8 @@ static int vmw_cmd_dx_view_define(struct
+ }
+
+ view_type = vmw_view_cmd_to_type(header->id);
++ if (view_type == vmw_view_max)
++ return -EINVAL;
+ cmd = container_of(header, typeof(*cmd), header);
+ ret = vmw_cmd_res_check(dev_priv, sw_context, vmw_res_surface,
+ user_surface_converter,
--- /dev/null
+From 943309d4aad6732b905f3f500e6e17e33c211494 Mon Sep 17 00:00:00 2001
+From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Date: Thu, 4 Jan 2018 09:19:13 +0200
+Subject: iwlwifi: pcie: fix DMA memory mapping / unmapping
+
+From: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+
+commit 943309d4aad6732b905f3f500e6e17e33c211494 upstream.
+
+22000 devices (previously referenced as A000) can support
+short transmit queues. This means that we have less DMA
+descriptors (TFD) for those shorter queues.
+Previous devices must still have 256 TFDs for each queue
+even if those 256 TFDs point to fewer buffers.
+
+When I introduced support for the short queues for 22000
+I broke older devices by assuming that they can also have
+less TFDs in their queues. This led to several problems:
+
+1) the payload of the commands weren't unmapped properly
+ which caused the SWIOTLB to complain at some point.
+2) the hardware could get confused and we get hardware
+ crashes.
+
+The corresponding bugzilla entries are:
+
+https://bugzilla.kernel.org/show_bug.cgi?id=198201
+https://bugzilla.kernel.org/show_bug.cgi?id=198265
+
+Fixes: 4ecab5616023 ("iwlwifi: pcie: support short Tx queues for A000 device family")
+Reviewed-by: Sharon, Sara <sara.sharon@intel.com>
+Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
+Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/net/wireless/intel/iwlwifi/pcie/internal.h | 10 +++++++---
+ drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c | 11 +++--------
+ drivers/net/wireless/intel/iwlwifi/pcie/tx.c | 8 ++++----
+ 3 files changed, 14 insertions(+), 15 deletions(-)
+
+--- a/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
++++ b/drivers/net/wireless/intel/iwlwifi/pcie/internal.h
+@@ -666,11 +666,15 @@ static inline u8 iwl_pcie_get_cmd_index(
+ return index & (q->n_window - 1);
+ }
+
+-static inline void *iwl_pcie_get_tfd(struct iwl_trans_pcie *trans_pcie,
++static inline void *iwl_pcie_get_tfd(struct iwl_trans *trans,
+ struct iwl_txq *txq, int idx)
+ {
+- return txq->tfds + trans_pcie->tfd_size * iwl_pcie_get_cmd_index(txq,
+- idx);
++ struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
++
++ if (trans->cfg->use_tfh)
++ idx = iwl_pcie_get_cmd_index(txq, idx);
++
++ return txq->tfds + trans_pcie->tfd_size * idx;
+ }
+
+ static inline void iwl_enable_rfkill_int(struct iwl_trans *trans)
+--- a/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c
++++ b/drivers/net/wireless/intel/iwlwifi/pcie/tx-gen2.c
+@@ -171,8 +171,6 @@ static void iwl_pcie_gen2_tfd_unmap(stru
+
+ static void iwl_pcie_gen2_free_tfd(struct iwl_trans *trans, struct iwl_txq *txq)
+ {
+- struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
+-
+ /* rd_ptr is bounded by TFD_QUEUE_SIZE_MAX and
+ * idx is bounded by n_window
+ */
+@@ -181,7 +179,7 @@ static void iwl_pcie_gen2_free_tfd(struc
+ lockdep_assert_held(&txq->lock);
+
+ iwl_pcie_gen2_tfd_unmap(trans, &txq->entries[idx].meta,
+- iwl_pcie_get_tfd(trans_pcie, txq, idx));
++ iwl_pcie_get_tfd(trans, txq, idx));
+
+ /* free SKB */
+ if (txq->entries) {
+@@ -367,11 +365,9 @@ struct iwl_tfh_tfd *iwl_pcie_gen2_build_
+ struct sk_buff *skb,
+ struct iwl_cmd_meta *out_meta)
+ {
+- struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
+ struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
+ int idx = iwl_pcie_get_cmd_index(txq, txq->write_ptr);
+- struct iwl_tfh_tfd *tfd =
+- iwl_pcie_get_tfd(trans_pcie, txq, idx);
++ struct iwl_tfh_tfd *tfd = iwl_pcie_get_tfd(trans, txq, idx);
+ dma_addr_t tb_phys;
+ bool amsdu;
+ int i, len, tb1_len, tb2_len, hdr_len;
+@@ -568,8 +564,7 @@ static int iwl_pcie_gen2_enqueue_hcmd(st
+ u8 group_id = iwl_cmd_groupid(cmd->id);
+ const u8 *cmddata[IWL_MAX_CMD_TBS_PER_TFD];
+ u16 cmdlen[IWL_MAX_CMD_TBS_PER_TFD];
+- struct iwl_tfh_tfd *tfd =
+- iwl_pcie_get_tfd(trans_pcie, txq, txq->write_ptr);
++ struct iwl_tfh_tfd *tfd = iwl_pcie_get_tfd(trans, txq, txq->write_ptr);
+
+ memset(tfd, 0, sizeof(*tfd));
+
+--- a/drivers/net/wireless/intel/iwlwifi/pcie/tx.c
++++ b/drivers/net/wireless/intel/iwlwifi/pcie/tx.c
+@@ -373,7 +373,7 @@ static void iwl_pcie_tfd_unmap(struct iw
+ {
+ struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
+ int i, num_tbs;
+- void *tfd = iwl_pcie_get_tfd(trans_pcie, txq, index);
++ void *tfd = iwl_pcie_get_tfd(trans, txq, index);
+
+ /* Sanity check on number of chunks */
+ num_tbs = iwl_pcie_tfd_get_num_tbs(trans, tfd);
+@@ -1999,7 +1999,7 @@ static int iwl_fill_data_tbs(struct iwl_
+ }
+
+ trace_iwlwifi_dev_tx(trans->dev, skb,
+- iwl_pcie_get_tfd(trans_pcie, txq, txq->write_ptr),
++ iwl_pcie_get_tfd(trans, txq, txq->write_ptr),
+ trans_pcie->tfd_size,
+ &dev_cmd->hdr, IWL_FIRST_TB_SIZE + tb1_len,
+ hdr_len);
+@@ -2073,7 +2073,7 @@ static int iwl_fill_data_tbs_amsdu(struc
+ IEEE80211_CCMP_HDR_LEN : 0;
+
+ trace_iwlwifi_dev_tx(trans->dev, skb,
+- iwl_pcie_get_tfd(trans_pcie, txq, txq->write_ptr),
++ iwl_pcie_get_tfd(trans, txq, txq->write_ptr),
+ trans_pcie->tfd_size,
+ &dev_cmd->hdr, IWL_FIRST_TB_SIZE + tb1_len, 0);
+
+@@ -2406,7 +2406,7 @@ int iwl_trans_pcie_tx(struct iwl_trans *
+ memcpy(&txq->first_tb_bufs[txq->write_ptr], &dev_cmd->hdr,
+ IWL_FIRST_TB_SIZE);
+
+- tfd = iwl_pcie_get_tfd(trans_pcie, txq, txq->write_ptr);
++ tfd = iwl_pcie_get_tfd(trans, txq, txq->write_ptr);
+ /* Set up entry for this TFD in Tx byte-count array */
+ iwl_pcie_txq_update_byte_cnt_tbl(trans, txq, le16_to_cpu(tx_cmd->len),
+ iwl_pcie_tfd_get_num_tbs(trans, tfd));
--- /dev/null
+From ecba8297aafd50db6ae867e90844eead1611ef1c Mon Sep 17 00:00:00 2001
+From: David Gibson <david@gibson.dropbear.id.au>
+Date: Wed, 10 Jan 2018 17:04:39 +1100
+Subject: KVM: PPC: Book3S HV: Always flush TLB in kvmppc_alloc_reset_hpt()
+
+From: David Gibson <david@gibson.dropbear.id.au>
+
+commit ecba8297aafd50db6ae867e90844eead1611ef1c upstream.
+
+The KVM_PPC_ALLOCATE_HTAB ioctl(), implemented by kvmppc_alloc_reset_hpt()
+is supposed to completely clear and reset a guest's Hashed Page Table (HPT)
+allocating or re-allocating it if necessary.
+
+In the case where an HPT of the right size already exists and it just
+zeroes it, it forces a TLB flush on all guest CPUs, to remove any stale TLB
+entries loaded from the old HPT.
+
+However, that situation can arise when the HPT is resizing as well - or
+even when switching from an RPT to HPT - so those cases need a TLB flush as
+well.
+
+So, move the TLB flush to trigger in all cases except for errors.
+
+Fixes: f98a8bf9ee20 ("KVM: PPC: Book3S HV: Allow KVM_PPC_ALLOCATE_HTAB ioctl() to change HPT size")
+Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kvm/book3s_64_mmu_hv.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
++++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
+@@ -165,8 +165,6 @@ long kvmppc_alloc_reset_hpt(struct kvm *
+ * Reset all the reverse-mapping chains for all memslots
+ */
+ kvmppc_rmap_reset(kvm);
+- /* Ensure that each vcpu will flush its TLB on next entry. */
+- cpumask_setall(&kvm->arch.need_tlb_flush);
+ err = 0;
+ goto out;
+ }
+@@ -182,6 +180,10 @@ long kvmppc_alloc_reset_hpt(struct kvm *
+ kvmppc_set_hpt(kvm, &info);
+
+ out:
++ if (err == 0)
++ /* Ensure that each vcpu will flush its TLB on next entry. */
++ cpumask_setall(&kvm->arch.need_tlb_flush);
++
+ mutex_unlock(&kvm->lock);
+ return err;
+ }
--- /dev/null
+From 3073774e638ef18d222465fe92bfc8fccb90d288 Mon Sep 17 00:00:00 2001
+From: Serhii Popovych <spopovyc@redhat.com>
+Date: Mon, 4 Dec 2017 09:36:41 -0500
+Subject: KVM: PPC: Book3S HV: Drop prepare_done from struct kvm_resize_hpt
+
+From: Serhii Popovych <spopovyc@redhat.com>
+
+commit 3073774e638ef18d222465fe92bfc8fccb90d288 upstream.
+
+Currently the kvm_resize_hpt structure has two fields relevant to the
+state of an ongoing resize: 'prepare_done', which indicates whether
+the worker thread has completed or not, and 'error' which indicates
+whether it was successful or not.
+
+Since the success/failure isn't known until completion, this is
+confusingly redundant. This patch consolidates the information into
+just the 'error' value: -EBUSY indicates the worked is still in
+progress, other negative values indicate (completed) failure, 0
+indicates successful completion.
+
+As a bonus this reduces size of struct kvm_resize_hpt by
+__alignof__(struct kvm_hpt_info) and saves few bytes of code.
+
+While there correct comment in struct kvm_resize_hpt which references
+a non-existent semaphore (leftover from an early draft).
+
+Assert with WARN_ON() in case of HPT allocation thread work runs more
+than once for resize request or resize_hpt_allocate() returns -EBUSY
+that is treated specially.
+
+Change comparison against zero to make checkpatch.pl happy.
+
+Signed-off-by: Serhii Popovych <spopovyc@redhat.com>
+[dwg: Changed BUG_ON()s to WARN_ON()s and altered commit message for
+ clarity]
+Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kvm/book3s_64_mmu_hv.c | 44 ++++++++++++++++++++++--------------
+ 1 file changed, 27 insertions(+), 17 deletions(-)
+
+--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
++++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
+@@ -65,11 +65,17 @@ struct kvm_resize_hpt {
+ u32 order;
+
+ /* These fields protected by kvm->lock */
++
++ /* Possible values and their usage:
++ * <0 an error occurred during allocation,
++ * -EBUSY allocation is in the progress,
++ * 0 allocation made successfuly.
++ */
+ int error;
+- bool prepare_done;
+
+- /* Private to the work thread, until prepare_done is true,
+- * then protected by kvm->resize_hpt_sem */
++ /* Private to the work thread, until error != -EBUSY,
++ * then protected by kvm->lock.
++ */
+ struct kvm_hpt_info hpt;
+ };
+
+@@ -1444,15 +1450,23 @@ static void resize_hpt_prepare_work(stru
+ struct kvm *kvm = resize->kvm;
+ int err;
+
++ if (WARN_ON(resize->error != -EBUSY))
++ return;
++
+ resize_hpt_debug(resize, "resize_hpt_prepare_work(): order = %d\n",
+ resize->order);
+
+ err = resize_hpt_allocate(resize);
+
++ /* We have strict assumption about -EBUSY
++ * when preparing for HPT resize.
++ */
++ if (WARN_ON(err == -EBUSY))
++ err = -EINPROGRESS;
++
+ mutex_lock(&kvm->lock);
+
+ resize->error = err;
+- resize->prepare_done = true;
+
+ mutex_unlock(&kvm->lock);
+ }
+@@ -1477,14 +1491,12 @@ long kvm_vm_ioctl_resize_hpt_prepare(str
+
+ if (resize) {
+ if (resize->order == shift) {
+- /* Suitable resize in progress */
+- if (resize->prepare_done) {
+- ret = resize->error;
+- if (ret != 0)
+- resize_hpt_release(kvm, resize);
+- } else {
++ /* Suitable resize in progress? */
++ ret = resize->error;
++ if (ret == -EBUSY)
+ ret = 100; /* estimated time in ms */
+- }
++ else if (ret)
++ resize_hpt_release(kvm, resize);
+
+ goto out;
+ }
+@@ -1504,6 +1516,8 @@ long kvm_vm_ioctl_resize_hpt_prepare(str
+ ret = -ENOMEM;
+ goto out;
+ }
++
++ resize->error = -EBUSY;
+ resize->order = shift;
+ resize->kvm = kvm;
+ INIT_WORK(&resize->work, resize_hpt_prepare_work);
+@@ -1558,16 +1572,12 @@ long kvm_vm_ioctl_resize_hpt_commit(stru
+ if (!resize || (resize->order != shift))
+ goto out;
+
+- ret = -EBUSY;
+- if (!resize->prepare_done)
+- goto out;
+-
+ ret = resize->error;
+- if (ret != 0)
++ if (ret)
+ goto out;
+
+ ret = resize_hpt_rehash(resize);
+- if (ret != 0)
++ if (ret)
+ goto out;
+
+ resize_hpt_pivot(resize);
--- /dev/null
+From 4ed11aeefda439c76ddae3ceebcfa4fad111f149 Mon Sep 17 00:00:00 2001
+From: Serhii Popovych <spopovyc@redhat.com>
+Date: Mon, 4 Dec 2017 09:36:42 -0500
+Subject: KVM: PPC: Book3S HV: Fix use after free in case of multiple resize requests
+
+From: Serhii Popovych <spopovyc@redhat.com>
+
+commit 4ed11aeefda439c76ddae3ceebcfa4fad111f149 upstream.
+
+When serving multiple resize requests following could happen:
+
+ CPU0 CPU1
+ ---- ----
+ kvm_vm_ioctl_resize_hpt_prepare(1);
+ -> schedule_work()
+ /* system_rq might be busy: delay */
+ kvm_vm_ioctl_resize_hpt_prepare(2);
+ mutex_lock();
+ if (resize) {
+ ...
+ release_hpt_resize();
+ }
+ ... resize_hpt_prepare_work()
+ -> schedule_work() {
+ mutex_unlock() /* resize->kvm could be wrong */
+ struct kvm *kvm = resize->kvm;
+
+ mutex_lock(&kvm->lock); <<<< UAF
+ ...
+ }
+
+i.e. a second resize request with different order could be started by
+kvm_vm_ioctl_resize_hpt_prepare(), causing the previous request to be
+free()d when there's still an active worker thread which will try to
+access it. This leads to a use after free in point marked with UAF on
+the diagram above.
+
+To prevent this from happening, instead of unconditionally releasing a
+pre-existing resize structure from the prepare ioctl(), we check if
+the existing structure has an in-progress worker. We do that by
+checking if the resize->error == -EBUSY, which is safe because the
+resize->error field is protected by the kvm->lock. If there is an
+active worker, instead of releasing, we mark the structure as stale by
+unlinking it from kvm_struct.
+
+In the worker thread we check for a stale structure (with kvm->lock
+held), and in that case abort, releasing the stale structure ourself.
+We make the check both before and the actual allocation. Strictly,
+only the check afterwards is needed, the check before is an
+optimization: if the structure happens to become stale before the
+worker thread is dispatched, rather than during the allocation, it
+means we can avoid allocating then immediately freeing a potentially
+substantial amount of memory.
+
+This fixes following or similar host kernel crash message:
+
+[ 635.277361] Unable to handle kernel paging request for data at address 0x00000000
+[ 635.277438] Faulting instruction address: 0xc00000000052f568
+[ 635.277446] Oops: Kernel access of bad area, sig: 11 [#1]
+[ 635.277451] SMP NR_CPUS=2048 NUMA PowerNV
+[ 635.277470] Modules linked in: xt_CHECKSUM iptable_mangle ipt_MASQUERADE
+nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4
+nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 tun bridge stp llc
+ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter nfsv3 nfs_acl nfs
+lockd grace fscache kvm_hv kvm rpcrdma sunrpc ib_isert iscsi_target_mod ib_iser libiscsi
+scsi_transport_iscsi ib_srpt target_core_mod ext4 ib_srp scsi_transport_srp
+ib_ipoib mbcache jbd2 rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm ocrdma(T)
+ib_core ses enclosure scsi_transport_sas sg shpchp leds_powernv ibmpowernv i2c_opal
+i2c_core powernv_rng ipmi_powernv ipmi_devintf ipmi_msghandler ip_tables xfs
+libcrc32c sr_mod sd_mod cdrom lpfc nvme_fc(T) nvme_fabrics nvme_core ipr nvmet_fc(T)
+tg3 nvmet libata be2net crc_t10dif crct10dif_generic scsi_transport_fc ptp scsi_tgt
+pps_core crct10dif_common dm_mirror dm_region_hash dm_log dm_mod
+[ 635.278687] CPU: 40 PID: 749 Comm: kworker/40:1 Tainted: G
+------------ T 3.10.0.bz1510771+ #1
+[ 635.278782] Workqueue: events resize_hpt_prepare_work [kvm_hv]
+[ 635.278851] task: c0000007e6840000 ti: c0000007e9180000 task.ti: c0000007e9180000
+[ 635.278919] NIP: c00000000052f568 LR: c0000000009ea310 CTR: c0000000009ea4f0
+[ 635.278988] REGS: c0000007e91837f0 TRAP: 0300 Tainted: G
+------------ T (3.10.0.bz1510771+)
+[ 635.279077] MSR: 9000000100009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 24002022 XER:
+00000000
+[ 635.279248] CFAR: c000000000009368 DAR: 0000000000000000 DSISR: 40000000 SOFTE: 1
+GPR00: c0000000009ea310 c0000007e9183a70 c000000001250b00 c0000007e9183b10
+GPR04: 0000000000000000 0000000000000000 c0000007e9183650 0000000000000000
+GPR08: c0000007ffff7b80 00000000ffffffff 0000000080000028 d00000000d2529a0
+GPR12: 0000000000002200 c000000007b56800 c000000000120028 c0000007f135bb40
+GPR16: 0000000000000000 c000000005c1e018 c000000005c1e018 0000000000000000
+GPR20: 0000000000000001 c0000000011bf778 0000000000000001 fffffffffffffef7
+GPR24: 0000000000000000 c000000f1e262e50 0000000000000002 c0000007e9180000
+GPR28: c000000f1e262e4c c000000f1e262e50 0000000000000000 c0000007e9183b10
+[ 635.280149] NIP [c00000000052f568] __list_add+0x38/0x110
+[ 635.280197] LR [c0000000009ea310] __mutex_lock_slowpath+0xe0/0x2c0
+[ 635.280253] Call Trace:
+[ 635.280277] [c0000007e9183af0] [c0000000009ea310] __mutex_lock_slowpath+0xe0/0x2c0
+[ 635.280356] [c0000007e9183b70] [c0000000009ea554] mutex_lock+0x64/0x70
+[ 635.280426] [c0000007e9183ba0] [d00000000d24da04]
+resize_hpt_prepare_work+0xe4/0x1c0 [kvm_hv]
+[ 635.280507] [c0000007e9183c40] [c000000000113c0c] process_one_work+0x1dc/0x680
+[ 635.280587] [c0000007e9183ce0] [c000000000114250] worker_thread+0x1a0/0x520
+[ 635.280655] [c0000007e9183d80] [c00000000012010c] kthread+0xec/0x100
+[ 635.280724] [c0000007e9183e30] [c00000000000a4b8] ret_from_kernel_thread+0x5c/0xa4
+[ 635.280814] Instruction dump:
+[ 635.280880] 7c0802a6 fba1ffe8 fbc1fff0 7cbd2b78 fbe1fff8 7c9e2378 7c7f1b78
+f8010010
+[ 635.281099] f821ff81 e8a50008 7fa52040 40de00b8 <e8be0000> 7fbd2840 40de008c
+7fbff040
+[ 635.281324] ---[ end trace b628b73449719b9d ]---
+
+Fixes: b5baa6877315 ("KVM: PPC: Book3S HV: KVM-HV HPT resizing implementation")
+Signed-off-by: Serhii Popovych <spopovyc@redhat.com>
+[dwg: Replaced BUG_ON()s with WARN_ONs() and reworded commit message
+ for clarity]
+Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kvm/book3s_64_mmu_hv.c | 54 ++++++++++++++++++++++++------------
+ 1 file changed, 37 insertions(+), 17 deletions(-)
+
+--- a/arch/powerpc/kvm/book3s_64_mmu_hv.c
++++ b/arch/powerpc/kvm/book3s_64_mmu_hv.c
+@@ -1430,16 +1430,20 @@ static void resize_hpt_pivot(struct kvm_
+
+ static void resize_hpt_release(struct kvm *kvm, struct kvm_resize_hpt *resize)
+ {
+- BUG_ON(kvm->arch.resize_hpt != resize);
++ if (WARN_ON(!mutex_is_locked(&kvm->lock)))
++ return;
+
+ if (!resize)
+ return;
+
+- if (resize->hpt.virt)
+- kvmppc_free_hpt(&resize->hpt);
++ if (resize->error != -EBUSY) {
++ if (resize->hpt.virt)
++ kvmppc_free_hpt(&resize->hpt);
++ kfree(resize);
++ }
+
+- kvm->arch.resize_hpt = NULL;
+- kfree(resize);
++ if (kvm->arch.resize_hpt == resize)
++ kvm->arch.resize_hpt = NULL;
+ }
+
+ static void resize_hpt_prepare_work(struct work_struct *work)
+@@ -1448,26 +1452,42 @@ static void resize_hpt_prepare_work(stru
+ struct kvm_resize_hpt,
+ work);
+ struct kvm *kvm = resize->kvm;
+- int err;
++ int err = 0;
+
+ if (WARN_ON(resize->error != -EBUSY))
+ return;
+
+- resize_hpt_debug(resize, "resize_hpt_prepare_work(): order = %d\n",
+- resize->order);
+-
+- err = resize_hpt_allocate(resize);
+-
+- /* We have strict assumption about -EBUSY
+- * when preparing for HPT resize.
+- */
+- if (WARN_ON(err == -EBUSY))
+- err = -EINPROGRESS;
+-
+ mutex_lock(&kvm->lock);
+
++ /* Request is still current? */
++ if (kvm->arch.resize_hpt == resize) {
++ /* We may request large allocations here:
++ * do not sleep with kvm->lock held for a while.
++ */
++ mutex_unlock(&kvm->lock);
++
++ resize_hpt_debug(resize, "resize_hpt_prepare_work(): order = %d\n",
++ resize->order);
++
++ err = resize_hpt_allocate(resize);
++
++ /* We have strict assumption about -EBUSY
++ * when preparing for HPT resize.
++ */
++ if (WARN_ON(err == -EBUSY))
++ err = -EINPROGRESS;
++
++ mutex_lock(&kvm->lock);
++ /* It is possible that kvm->arch.resize_hpt != resize
++ * after we grab kvm->lock again.
++ */
++ }
++
+ resize->error = err;
+
++ if (kvm->arch.resize_hpt != resize)
++ resize_hpt_release(kvm, resize);
++
+ mutex_unlock(&kvm->lock);
+ }
+
--- /dev/null
+From 6c7d47c33ed323f14f2a3b8de925e831dbaa4e69 Mon Sep 17 00:00:00 2001
+From: Alexey Kardashevskiy <aik@ozlabs.ru>
+Date: Wed, 22 Nov 2017 14:42:21 +1100
+Subject: KVM: PPC: Book3S PR: Fix WIMG handling under pHyp
+
+From: Alexey Kardashevskiy <aik@ozlabs.ru>
+
+commit 6c7d47c33ed323f14f2a3b8de925e831dbaa4e69 upstream.
+
+Commit 96df226 ("KVM: PPC: Book3S PR: Preserve storage control bits")
+added code to preserve WIMG bits but it missed 2 special cases:
+- a magic page in kvmppc_mmu_book3s_64_xlate() and
+- guest real mode in kvmppc_handle_pagefault().
+
+For these ptes, WIMG was 0 and pHyp failed on these causing a guest to
+stop in the very beginning at NIP=0x100 (due to bd9166ffe "KVM: PPC:
+Book3S PR: Exit KVM on failed mapping").
+
+According to LoPAPR v1.1 14.5.4.1.2 H_ENTER:
+
+ The hypervisor checks that the WIMG bits within the PTE are appropriate
+ for the physical page number else H_Parameter return. (For System Memory
+ pages WIMG=0010, or, 1110 if the SAO option is enabled, and for IO pages
+ WIMG=01**.)
+
+This hence initializes WIMG to non-zero value HPTE_R_M (0x10), as expected
+by pHyp.
+
+[paulus@ozlabs.org - fix compile for 32-bit]
+
+Fixes: 96df226 "KVM: PPC: Book3S PR: Preserve storage control bits"
+Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
+Tested-by: Ruediger Oertel <ro@suse.de>
+Reviewed-by: Greg Kurz <groug@kaod.org>
+Tested-by: Greg Kurz <groug@kaod.org>
+Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/powerpc/kvm/book3s_64_mmu.c | 1 +
+ arch/powerpc/kvm/book3s_pr.c | 2 ++
+ 2 files changed, 3 insertions(+)
+
+--- a/arch/powerpc/kvm/book3s_64_mmu.c
++++ b/arch/powerpc/kvm/book3s_64_mmu.c
+@@ -235,6 +235,7 @@ static int kvmppc_mmu_book3s_64_xlate(st
+ gpte->may_read = true;
+ gpte->may_write = true;
+ gpte->page_size = MMU_PAGE_4K;
++ gpte->wimg = HPTE_R_M;
+
+ return 0;
+ }
+--- a/arch/powerpc/kvm/book3s_pr.c
++++ b/arch/powerpc/kvm/book3s_pr.c
+@@ -60,6 +60,7 @@ static void kvmppc_giveup_fac(struct kvm
+ #define MSR_USER32 MSR_USER
+ #define MSR_USER64 MSR_USER
+ #define HW_PAGE_SIZE PAGE_SIZE
++#define HPTE_R_M _PAGE_COHERENT
+ #endif
+
+ static bool kvmppc_is_split_real(struct kvm_vcpu *vcpu)
+@@ -557,6 +558,7 @@ int kvmppc_handle_pagefault(struct kvm_r
+ pte.eaddr = eaddr;
+ pte.vpage = eaddr >> 12;
+ pte.page_size = MMU_PAGE_64K;
++ pte.wimg = HPTE_R_M;
+ }
+
+ switch (kvmppc_get_msr(vcpu) & (MSR_DR|MSR_IR)) {
--- /dev/null
+From 75f139aaf896d6fdeec2e468ddfa4b2fe469bf40 Mon Sep 17 00:00:00 2001
+From: Andrew Honig <ahonig@google.com>
+Date: Wed, 10 Jan 2018 10:12:03 -0800
+Subject: KVM: x86: Add memory barrier on vmcs field lookup
+
+From: Andrew Honig <ahonig@google.com>
+
+commit 75f139aaf896d6fdeec2e468ddfa4b2fe469bf40 upstream.
+
+This adds a memory barrier when performing a lookup into
+the vmcs_field_to_offset_table. This is related to
+CVE-2017-5753.
+
+Signed-off-by: Andrew Honig <ahonig@google.com>
+Reviewed-by: Jim Mattson <jmattson@google.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kvm/vmx.c | 12 ++++++++++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kvm/vmx.c
++++ b/arch/x86/kvm/vmx.c
+@@ -888,8 +888,16 @@ static inline short vmcs_field_to_offset
+ {
+ BUILD_BUG_ON(ARRAY_SIZE(vmcs_field_to_offset_table) > SHRT_MAX);
+
+- if (field >= ARRAY_SIZE(vmcs_field_to_offset_table) ||
+- vmcs_field_to_offset_table[field] == 0)
++ if (field >= ARRAY_SIZE(vmcs_field_to_offset_table))
++ return -ENOENT;
++
++ /*
++ * FIXME: Mitigation for CVE-2017-5753. To be replaced with a
++ * generic mechanism.
++ */
++ asm("lfence");
++
++ if (vmcs_field_to_offset_table[field] == 0)
+ return -ENOENT;
+
+ return vmcs_field_to_offset_table[field];
--- /dev/null
+From 967a6a07e95c58eb9c1581d22a1d9c2d1929843f Mon Sep 17 00:00:00 2001
+From: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
+Date: Wed, 13 Dec 2017 11:33:00 +0900
+Subject: mmc: renesas_sdhi: Add MODULE_LICENSE
+
+From: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
+
+commit 967a6a07e95c58eb9c1581d22a1d9c2d1929843f upstream.
+
+The following error occurs when loading renesas_sdhi_core.c module,
+so add MODULE_LICENSE("GPL v2").
+
+ renesas_sdhi_core: module license 'unspecified' taints kernel.
+
+Signed-off-by: Masaharu Hayakawa <masaharu.hayakawa.ry@renesas.com>
+Fixes: 9d08428afb72 ("mmc: renesas-sdhi: make renesas_sdhi_sys_dmac main module file")
+[Shimoda: Added Fixes tag and Cc to the stable ML]
+Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
+Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
+Acked-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
+Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/mmc/host/renesas_sdhi_core.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+--- a/drivers/mmc/host/renesas_sdhi_core.c
++++ b/drivers/mmc/host/renesas_sdhi_core.c
+@@ -24,6 +24,7 @@
+ #include <linux/kernel.h>
+ #include <linux/clk.h>
+ #include <linux/slab.h>
++#include <linux/module.h>
+ #include <linux/of_device.h>
+ #include <linux/platform_device.h>
+ #include <linux/mmc/host.h>
+@@ -667,3 +668,5 @@ int renesas_sdhi_remove(struct platform_
+ return 0;
+ }
+ EXPORT_SYMBOL_GPL(renesas_sdhi_remove);
++
++MODULE_LICENSE("GPL v2");
--- /dev/null
+From edd8ca8015800b354453b891d38960f3a474b7e4 Mon Sep 17 00:00:00 2001
+From: Florian Margaine <florian@platform.sh>
+Date: Wed, 13 Dec 2017 16:43:59 +0100
+Subject: rbd: reacquire lock should update lock owner client id
+
+From: Florian Margaine <florian@platform.sh>
+
+commit edd8ca8015800b354453b891d38960f3a474b7e4 upstream.
+
+Otherwise, future operations on this RBD using exclusive-lock are
+going to require the lock from a non-existent client id.
+
+Fixes: 14bb211d324d ("rbd: support updating the lock cookie without releasing the lock")
+Link: http://tracker.ceph.com/issues/19929
+Signed-off-by: Florian Margaine <florian@platform.sh>
+[idryomov@gmail.com: rbd_set_owner_cid() call, __rbd_lock() helper]
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/block/rbd.c | 16 +++++++++++-----
+ 1 file changed, 11 insertions(+), 5 deletions(-)
+
+--- a/drivers/block/rbd.c
++++ b/drivers/block/rbd.c
+@@ -3074,13 +3074,21 @@ static void format_lock_cookie(struct rb
+ mutex_unlock(&rbd_dev->watch_mutex);
+ }
+
++static void __rbd_lock(struct rbd_device *rbd_dev, const char *cookie)
++{
++ struct rbd_client_id cid = rbd_get_cid(rbd_dev);
++
++ strcpy(rbd_dev->lock_cookie, cookie);
++ rbd_set_owner_cid(rbd_dev, &cid);
++ queue_work(rbd_dev->task_wq, &rbd_dev->acquired_lock_work);
++}
++
+ /*
+ * lock_rwsem must be held for write
+ */
+ static int rbd_lock(struct rbd_device *rbd_dev)
+ {
+ struct ceph_osd_client *osdc = &rbd_dev->rbd_client->client->osdc;
+- struct rbd_client_id cid = rbd_get_cid(rbd_dev);
+ char cookie[32];
+ int ret;
+
+@@ -3095,9 +3103,7 @@ static int rbd_lock(struct rbd_device *r
+ return ret;
+
+ rbd_dev->lock_state = RBD_LOCK_STATE_LOCKED;
+- strcpy(rbd_dev->lock_cookie, cookie);
+- rbd_set_owner_cid(rbd_dev, &cid);
+- queue_work(rbd_dev->task_wq, &rbd_dev->acquired_lock_work);
++ __rbd_lock(rbd_dev, cookie);
+ return 0;
+ }
+
+@@ -3883,7 +3889,7 @@ static void rbd_reacquire_lock(struct rb
+ queue_delayed_work(rbd_dev->task_wq,
+ &rbd_dev->lock_dwork, 0);
+ } else {
+- strcpy(rbd_dev->lock_cookie, cookie);
++ __rbd_lock(rbd_dev, cookie);
+ }
+ }
+
--- /dev/null
+From 21acdf45f4958135940f0b4767185cf911d4b010 Mon Sep 17 00:00:00 2001
+From: Ilya Dryomov <idryomov@gmail.com>
+Date: Thu, 21 Dec 2017 15:35:11 +0100
+Subject: rbd: set max_segments to USHRT_MAX
+
+From: Ilya Dryomov <idryomov@gmail.com>
+
+commit 21acdf45f4958135940f0b4767185cf911d4b010 upstream.
+
+Commit d3834fefcfe5 ("rbd: bump queue_max_segments") bumped
+max_segments (unsigned short) to max_hw_sectors (unsigned int).
+max_hw_sectors is set to the number of 512-byte sectors in an object
+and overflows unsigned short for 32M (largest possible) objects, making
+the block layer resort to handing us single segment (i.e. single page
+or even smaller) bios in that case.
+
+Fixes: d3834fefcfe5 ("rbd: bump queue_max_segments")
+Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
+Reviewed-by: Alex Elder <elder@linaro.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ drivers/block/rbd.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/block/rbd.c
++++ b/drivers/block/rbd.c
+@@ -4421,7 +4421,7 @@ static int rbd_init_disk(struct rbd_devi
+ segment_size = rbd_obj_bytes(&rbd_dev->header);
+ blk_queue_max_hw_sectors(q, segment_size / SECTOR_SIZE);
+ q->limits.max_sectors = queue_max_hw_sectors(q);
+- blk_queue_max_segments(q, segment_size / SECTOR_SIZE);
++ blk_queue_max_segments(q, USHRT_MAX);
+ blk_queue_max_segment_size(q, segment_size);
+ blk_queue_io_min(q, segment_size);
+ blk_queue_io_opt(q, segment_size);
sfp-fix-sfp-bus-oops-when-removing-socket-upstream.patch
revert-revert-xfrm-fix-stack-out-of-bounds-read-in-xfrm_state_find.patch
membarrier-disable-preemption-when-calling-smp_call_function_many.patch
+crypto-algapi-fix-null-dereference-in-crypto_remove_spawns.patch
+mmc-renesas_sdhi-add-module_license.patch
+rbd-reacquire-lock-should-update-lock-owner-client-id.patch
+rbd-set-max_segments-to-ushrt_max.patch
+iwlwifi-pcie-fix-dma-memory-mapping-unmapping.patch
+x86-microcode-intel-extend-bdw-late-loading-with-a-revision-check.patch
+kvm-x86-add-memory-barrier-on-vmcs-field-lookup.patch
+kvm-ppc-book3s-pr-fix-wimg-handling-under-phyp.patch
+kvm-ppc-book3s-hv-drop-prepare_done-from-struct-kvm_resize_hpt.patch
+kvm-ppc-book3s-hv-fix-use-after-free-in-case-of-multiple-resize-requests.patch
+kvm-ppc-book3s-hv-always-flush-tlb-in-kvmppc_alloc_reset_hpt.patch
+drm-vmwgfx-don-t-cache-framebuffer-maps.patch
+drm-vmwgfx-potential-off-by-one-in-vmw_view_add.patch
+drm-i915-gvt-clear-the-shadow-page-table-entry-after-post-sync.patch
+drm-i915-whitelist-slice_common_eco_chicken1-on-geminilake.patch
+drm-i915-move-init_clock_gating-back-to-where-it-was.patch
+drm-i915-fix-init_clock_gating-for-resume.patch
--- /dev/null
+From b94b7373317164402ff7728d10f7023127a02b60 Mon Sep 17 00:00:00 2001
+From: Jia Zhang <qianyue.zj@alibaba-inc.com>
+Date: Mon, 1 Jan 2018 10:04:47 +0800
+Subject: x86/microcode/intel: Extend BDW late-loading with a revision check
+
+From: Jia Zhang <qianyue.zj@alibaba-inc.com>
+
+commit b94b7373317164402ff7728d10f7023127a02b60 upstream.
+
+Instead of blacklisting all model 79 CPUs when attempting a late
+microcode loading, limit that only to CPUs with microcode revisions <
+0x0b000021 because only on those late loading may cause a system hang.
+
+For such processors either:
+
+a) a BIOS update which might contain a newer microcode revision
+
+or
+
+b) the early microcode loading method
+
+should be considered.
+
+Processors with revisions 0x0b000021 or higher will not experience such
+hangs.
+
+For more details, see erratum BDF90 in document #334165 (Intel Xeon
+Processor E7-8800/4800 v4 Product Family Specification Update) from
+September 2017.
+
+[ bp: Heavily massage commit message and pr_* statements. ]
+
+Fixes: 723f2828a98c ("x86/microcode/intel: Disable late loading on model 79")
+Signed-off-by: Jia Zhang <qianyue.zj@alibaba-inc.com>
+Signed-off-by: Borislav Petkov <bp@suse.de>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Acked-by: Tony Luck <tony.luck@intel.com>
+Cc: x86-ml <x86@kernel.org>
+Link: http://lkml.kernel.org/r/1514772287-92959-1-git-send-email-qianyue.zj@alibaba-inc.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+
+---
+ arch/x86/kernel/cpu/microcode/intel.c | 13 +++++++++++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/cpu/microcode/intel.c
++++ b/arch/x86/kernel/cpu/microcode/intel.c
+@@ -910,8 +910,17 @@ static bool is_blacklisted(unsigned int
+ {
+ struct cpuinfo_x86 *c = &cpu_data(cpu);
+
+- if (c->x86 == 6 && c->x86_model == INTEL_FAM6_BROADWELL_X) {
+- pr_err_once("late loading on model 79 is disabled.\n");
++ /*
++ * Late loading on model 79 with microcode revision less than 0x0b000021
++ * may result in a system hang. This behavior is documented in item
++ * BDF90, #334165 (Intel Xeon Processor E7-8800/4800 v4 Product Family).
++ */
++ if (c->x86 == 6 &&
++ c->x86_model == INTEL_FAM6_BROADWELL_X &&
++ c->x86_mask == 0x01 &&
++ c->microcode < 0x0b000021) {
++ pr_err_once("Erratum BDF90: late loading with revision < 0x0b000021 (0x%x) disabled.\n", c->microcode);
++ pr_err_once("Please consider either early loading through initrd/built-in or a potential BIOS update.\n");
+ return true;
+ }
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
