diff options
author | Justin M. Forbes <jforbes@fedoraproject.org> | 2017-10-12 10:40:29 -0500 |
---|---|---|
committer | Justin M. Forbes <jforbes@fedoraproject.org> | 2017-10-12 10:40:29 -0500 |
commit | 4ae8c94a386c255765627b1790118e684a9d30ce (patch) | |
tree | 8b9ed29458a72560fa837df57936535a247427d5 | |
parent | f43f87d5aa78e40012190a818b5f781f7cea4d3c (diff) | |
download | kernel-4ae8c94a386c255765627b1790118e684a9d30ce.tar.gz kernel-4ae8c94a386c255765627b1790118e684a9d30ce.tar.xz kernel-4ae8c94a386c255765627b1790118e684a9d30ce.zip |
Linux v4.13.6
-rw-r--r-- | HID-rmi-Make-sure-the-HID-device-is-opened-on-resume.patch | 74 | ||||
-rw-r--r-- | arm64-ensure-ready-for-userspace.patch | 79 | ||||
-rw-r--r-- | drm-i915-boost-GPU-clocks-if-we-miss-the-pageflip.patch | 238 | ||||
-rw-r--r-- | kernel.spec | 11 | ||||
-rw-r--r-- | sources | 2 |
5 files changed, 247 insertions, 157 deletions
diff --git a/HID-rmi-Make-sure-the-HID-device-is-opened-on-resume.patch b/HID-rmi-Make-sure-the-HID-device-is-opened-on-resume.patch deleted file mode 100644 index d7d626972..000000000 --- a/HID-rmi-Make-sure-the-HID-device-is-opened-on-resume.patch +++ /dev/null @@ -1,74 +0,0 @@ -From patchwork Sun Jul 23 01:15:09 2017 -Content-Type: text/plain; charset="utf-8" -MIME-Version: 1.0 -Content-Transfer-Encoding: 7bit -Subject: HID: rmi: Make sure the HID device is opened on resume -From: Lyude <lyude@redhat.com> -X-Patchwork-Id: 9858267 -Message-Id: <20170723011509.23651-1-lyude@redhat.com> -To: linux-input@vger.kernel.org -Cc: Lyude <lyude@redhat.com>, Andrew Duggan <aduggan@synaptics.com>, - stable@vger.kernel.org, Jiri Kosina <jikos@kernel.org>, - Benjamin Tissoires <benjamin.tissoires@redhat.com>, - linux-kernel@vger.kernel.org -Date: Sat, 22 Jul 2017 21:15:09 -0400 - -So it looks like that suspend/resume has actually always been broken on -hid-rmi. The fact it worked was a rather silly coincidence that was -relying on the HID device to already be opened upon resume. This means -that so long as anything was reading the /dev/input/eventX node for for -an RMI device, it would suspend and resume correctly. As well, if -nothing happened to be keeping the HID device away it would shut off, -then the RMI driver would get confused on resume when it stopped -responding and explode. - -So, call hid_hw_open() in rmi_post_resume() so we make sure that the -device is alive before we try talking to it. - -This fixes RMI device suspend/resume over HID. - -Signed-off-by: Lyude <lyude@redhat.com> -Cc: Andrew Duggan <aduggan@synaptics.com> -Cc: stable@vger.kernel.org ---- - drivers/hid/hid-rmi.c | 15 +++++++++++---- - 1 file changed, 11 insertions(+), 4 deletions(-) - -diff --git a/drivers/hid/hid-rmi.c b/drivers/hid/hid-rmi.c -index 5b40c2614599..e7d124f9a27f 100644 ---- a/drivers/hid/hid-rmi.c -+++ b/drivers/hid/hid-rmi.c -@@ -431,22 +431,29 @@ static int rmi_post_resume(struct hid_device *hdev) - { - struct rmi_data *data = hid_get_drvdata(hdev); - struct rmi_device *rmi_dev = data->xport.rmi_dev; -- int ret; -+ int ret = 0; - - if (!(data->device_flags & RMI_DEVICE)) - return 0; - -- ret = rmi_reset_attn_mode(hdev); -+ /* Make sure the HID device is ready to receive events */ -+ ret = hid_hw_open(hdev); - if (ret) - return ret; - -+ ret = rmi_reset_attn_mode(hdev); -+ if (ret) -+ goto out; -+ - ret = rmi_driver_resume(rmi_dev, false); - if (ret) { - hid_warn(hdev, "Failed to resume device: %d\n", ret); -- return ret; -+ goto out; - } - -- return 0; -+out: -+ hid_hw_close(hdev); -+ return ret; - } - #endif /* CONFIG_PM */ - diff --git a/arm64-ensure-ready-for-userspace.patch b/arm64-ensure-ready-for-userspace.patch deleted file mode 100644 index 2468e2271..000000000 --- a/arm64-ensure-ready-for-userspace.patch +++ /dev/null @@ -1,79 +0,0 @@ -From c0d8832e78cbfd4a64b7112e34920af4b0b0e60e Mon Sep 17 00:00:00 2001 -From: Suzuki K Poulose <suzuki.poulose@arm.com> -Date: Fri, 6 Oct 2017 14:16:52 +0100 -Subject: arm64: Ensure the instruction emulation is ready for userspace - -We trap and emulate some instructions (e.g, mrs, deprecated instructions) -for the userspace. However the handlers for these are registered as -late_initcalls and the userspace could be up and running from the initramfs -by that time (with populate_rootfs, which is a rootfs_initcall()). This -could cause problems for the early applications ending up in failure -like : - -[ 11.152061] modprobe[93]: undefined instruction: pc=0000ffff8ca48ff4 - -This patch promotes the specific calls to core_initcalls, which are -guaranteed to be completed before we hit userspace. - -Cc: stable@vger.kernel.org -Cc: Dave Martin <dave.martin@arm.com> -Cc: Matthias Brugger <mbrugger@suse.com> -Cc: James Morse <james.morse@arm.com> -Reported-by: Matwey V. Kornilov <matwey.kornilov@gmail.com> -Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> -Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> ---- - arch/arm64/kernel/armv8_deprecated.c | 2 +- - arch/arm64/kernel/cpufeature.c | 2 +- - 2 files changed, 2 insertions(+), 2 deletions(-) - -diff --git a/arch/arm64/kernel/armv8_deprecated.c b/arch/arm64/kernel/armv8_deprecated.c -index f0e6d71..d06fbe4 100644 ---- a/arch/arm64/kernel/armv8_deprecated.c -+++ b/arch/arm64/kernel/armv8_deprecated.c -@@ -649,4 +649,4 @@ static int __init armv8_deprecated_init(void) - return 0; - } - --late_initcall(armv8_deprecated_init); -+core_initcall(armv8_deprecated_init); -diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c -index cd52d36..21e2c95 100644 ---- a/arch/arm64/kernel/cpufeature.c -+++ b/arch/arm64/kernel/cpufeature.c -@@ -1307,4 +1307,4 @@ static int __init enable_mrs_emulation(void) - return 0; - } - --late_initcall(enable_mrs_emulation); -+core_initcall(enable_mrs_emulation); -From ae2e972dae3cea795e9f8f94eb1601213c2d49f0 Mon Sep 17 00:00:00 2001 -From: Suzuki K Poulose <suzuki.poulose@arm.com> -Date: Fri, 6 Oct 2017 14:16:53 +0100 -Subject: arm64: Ensure fpsimd support is ready before userspace is active - -We register the pm/hotplug callbacks for FPSIMD as late_initcall, -which happens after the userspace is active (from initramfs via -populate_rootfs, a rootfs_initcall). Make sure we are ready even -before the userspace could potentially use it, by promoting to -a core_initcall. - -Cc: Will Deacon <will.deacon@arm.com> -Cc: Mark Rutland <mark.rutland@arm.com> -Cc: Dave Martin <dave.martin@arm.com> -Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com> -Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> ---- - arch/arm64/kernel/fpsimd.c | 2 +- - 1 file changed, 1 insertion(+), 1 deletion(-) - -diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c -index f444f37..5d547de 100644 ---- a/arch/arm64/kernel/fpsimd.c -+++ b/arch/arm64/kernel/fpsimd.c -@@ -444,4 +444,4 @@ static int __init fpsimd_init(void) - - return 0; - } --late_initcall(fpsimd_init); -+core_initcall(fpsimd_init); diff --git a/drm-i915-boost-GPU-clocks-if-we-miss-the-pageflip.patch b/drm-i915-boost-GPU-clocks-if-we-miss-the-pageflip.patch new file mode 100644 index 000000000..0bd0e7cef --- /dev/null +++ b/drm-i915-boost-GPU-clocks-if-we-miss-the-pageflip.patch @@ -0,0 +1,238 @@ +From 333e2a813cdfb86ff286ece6f13bec371aa03d7b Mon Sep 17 00:00:00 2001 +From: Chris Wilson <chris@chris-wilson.co.uk> +Date: Thu, 17 Aug 2017 13:37:06 +0100 +Subject: [PATCH] drm/i915: Boost GPU clocks if we miss the pageflip's vblank +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +If we miss the current vblank because the gpu was busy, that may cause a +jitter as the frame rate temporarily drops. We try to limit the impact +of this by then boosting the GPU clock to deliver the frame as quickly +as possible. Originally done in commit 6ad790c0f5ac ("drm/i915: Boost GPU +frequency if we detect outstanding pageflips") but was never forward +ported to atomic and finally dropped in commit fd3a40242e87 ("drm/i915: +Rip out legacy page_flip completion/irq handling"). + +One of the most typical use-cases for this is a mostly idle desktop. +Rendering one frame of the desktop's frontbuffer can easily be +accomplished by the GPU running at low frequency, but often exceeds +the time budget of the desktop compositor. The result is that animations +such as opening the menu, doing a fullscreen switch, or even just trying +to move a window around are slow and jerky. We need to respond within a +frame to give the best impression of a smooth UX, as a compromise we +instead respond if that first frame misses its goal. The result should +be a near-imperceivable initial delay and a smooth animation even +starting from idle. The cost, as ever, is that we spend more power than +is strictly necessary as we overestimate the required GPU frequency and +then try to ramp down. + +This of course is reactionary, too little, too late; nevertheless it is +surprisingly effective. + +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102199 +Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> +Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> +Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> +Cc: Daniel Vetter <daniel.vetter@intel.com> +Link: https://patchwork.freedesktop.org/patch/msgid/20170817123706.6777-1-chris@chris-wilson.co.uk +Tested-by: Lyude Paul <lyude@redhat.com> +Reviewed-by: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> +--- + drivers/gpu/drm/i915/i915_gem.c | 10 +++--- + drivers/gpu/drm/i915/intel_display.c | 63 ++++++++++++++++++++++++++++++++++++ + drivers/gpu/drm/i915/intel_pm.c | 14 ++++---- + 3 files changed, 77 insertions(+), 10 deletions(-) + +diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c +index 969bac8404f1..7d409b29d75a 100644 +--- a/drivers/gpu/drm/i915/i915_gem.c ++++ b/drivers/gpu/drm/i915/i915_gem.c +@@ -355,6 +355,7 @@ i915_gem_object_wait_fence(struct dma_fence *fence, + long timeout, + struct intel_rps_client *rps) + { ++ unsigned long irq_flags; + struct drm_i915_gem_request *rq; + + BUILD_BUG_ON(I915_WAIT_INTERRUPTIBLE != 0x1); +@@ -410,9 +411,9 @@ i915_gem_object_wait_fence(struct dma_fence *fence, + * Compensate by giving the synchronous client credit for + * a waitboost next time. + */ +- spin_lock(&rq->i915->rps.client_lock); ++ spin_lock_irqsave(&rq->i915->rps.client_lock, irq_flags); + list_del_init(&rps->link); +- spin_unlock(&rq->i915->rps.client_lock); ++ spin_unlock_irqrestore(&rq->i915->rps.client_lock, irq_flags); + } + + return timeout; +@@ -5029,6 +5030,7 @@ void i915_gem_release(struct drm_device *dev, struct drm_file *file) + { + struct drm_i915_file_private *file_priv = file->driver_priv; + struct drm_i915_gem_request *request; ++ unsigned long flags; + + /* Clean up our request list when the client is going away, so that + * later retire_requests won't dereference our soon-to-be-gone +@@ -5040,9 +5042,9 @@ void i915_gem_release(struct drm_device *dev, struct drm_file *file) + spin_unlock(&file_priv->mm.lock); + + if (!list_empty(&file_priv->rps.link)) { +- spin_lock(&to_i915(dev)->rps.client_lock); ++ spin_lock_irqsave(&to_i915(dev)->rps.client_lock, flags); + list_del(&file_priv->rps.link); +- spin_unlock(&to_i915(dev)->rps.client_lock); ++ spin_unlock_irqrestore(&to_i915(dev)->rps.client_lock, flags); + } + } + +diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c +index 022125082649..875eb7aec2f1 100644 +--- a/drivers/gpu/drm/i915/intel_display.c ++++ b/drivers/gpu/drm/i915/intel_display.c +@@ -13301,6 +13301,58 @@ static const struct drm_crtc_funcs intel_crtc_funcs = { + .set_crc_source = intel_crtc_set_crc_source, + }; + ++struct wait_rps_boost { ++ struct wait_queue_entry wait; ++ ++ struct drm_crtc *crtc; ++ struct drm_i915_gem_request *request; ++}; ++ ++static int do_rps_boost(struct wait_queue_entry *_wait, ++ unsigned mode, int sync, void *key) ++{ ++ struct wait_rps_boost *wait = container_of(_wait, typeof(*wait), wait); ++ struct drm_i915_gem_request *rq = wait->request; ++ ++ gen6_rps_boost(rq->i915, NULL, rq->emitted_jiffies); ++ i915_gem_request_put(rq); ++ ++ drm_crtc_vblank_put(wait->crtc); ++ ++ list_del(&wait->wait.entry); ++ kfree(wait); ++ return 1; ++} ++ ++static void add_rps_boost_after_vblank(struct drm_crtc *crtc, ++ struct dma_fence *fence) ++{ ++ struct wait_rps_boost *wait; ++ ++ if (!dma_fence_is_i915(fence)) ++ return; ++ ++ if (INTEL_GEN(to_i915(crtc->dev)) < 6) ++ return; ++ ++ if (drm_crtc_vblank_get(crtc)) ++ return; ++ ++ wait = kmalloc(sizeof(*wait), GFP_KERNEL); ++ if (!wait) { ++ drm_crtc_vblank_put(crtc); ++ return; ++ } ++ ++ wait->request = to_request(dma_fence_get(fence)); ++ wait->crtc = crtc; ++ ++ wait->wait.func = do_rps_boost; ++ wait->wait.flags = 0; ++ ++ add_wait_queue(drm_crtc_vblank_waitqueue(crtc), &wait->wait); ++} ++ + /** + * intel_prepare_plane_fb - Prepare fb for usage on plane + * @plane: drm plane to prepare for +@@ -13392,6 +13444,8 @@ intel_prepare_plane_fb(struct drm_plane *plane, + return 0; + + if (!new_state->fence) { /* implicit fencing */ ++ struct dma_fence *fence; ++ + ret = i915_sw_fence_await_reservation(&intel_state->commit_ready, + obj->resv, NULL, + false, I915_FENCE_TIMEOUT, +@@ -13399,7 +13453,16 @@ intel_prepare_plane_fb(struct drm_plane *plane, + if (ret < 0) + return ret; + ++ fence = reservation_object_get_excl_rcu(obj->resv); ++ if (fence) { ++ add_rps_boost_after_vblank(new_state->crtc, fence); ++ dma_fence_put(fence); ++ } ++ + i915_gem_object_wait_priority(obj, 0, I915_PRIORITY_DISPLAY); ++ ++ } else { ++ add_rps_boost_after_vblank(new_state->crtc, new_state->fence); + } + + return 0; +diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c +index 40b224b44d1b..b0ee9c4d33f4 100644 +--- a/drivers/gpu/drm/i915/intel_pm.c ++++ b/drivers/gpu/drm/i915/intel_pm.c +@@ -6108,6 +6108,7 @@ void gen6_rps_busy(struct drm_i915_private *dev_priv) + + void gen6_rps_idle(struct drm_i915_private *dev_priv) + { ++ unsigned long flags; + /* Flush our bottom-half so that it does not race with us + * setting the idle frequency and so that it is bounded by + * our rpm wakeref. And then disable the interrupts to stop any +@@ -6127,16 +6128,17 @@ void gen6_rps_idle(struct drm_i915_private *dev_priv) + } + mutex_unlock(&dev_priv->rps.hw_lock); + +- spin_lock(&dev_priv->rps.client_lock); ++ spin_lock_irqsave(&dev_priv->rps.client_lock, flags); + while (!list_empty(&dev_priv->rps.clients)) + list_del_init(dev_priv->rps.clients.next); +- spin_unlock(&dev_priv->rps.client_lock); ++ spin_unlock_irqrestore(&dev_priv->rps.client_lock, flags); + } + + void gen6_rps_boost(struct drm_i915_private *dev_priv, + struct intel_rps_client *rps, + unsigned long submitted) + { ++ unsigned long flags; + /* This is intentionally racy! We peek at the state here, then + * validate inside the RPS worker. + */ +@@ -6151,14 +6153,14 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv, + if (rps && time_after(jiffies, submitted + DRM_I915_THROTTLE_JIFFIES)) + rps = NULL; + +- spin_lock(&dev_priv->rps.client_lock); ++ spin_lock_irqsave(&dev_priv->rps.client_lock, flags); + if (rps == NULL || list_empty(&rps->link)) { +- spin_lock_irq(&dev_priv->irq_lock); ++ spin_lock(&dev_priv->irq_lock); + if (dev_priv->rps.interrupts_enabled) { + dev_priv->rps.client_boost = true; + schedule_work(&dev_priv->rps.work); + } +- spin_unlock_irq(&dev_priv->irq_lock); ++ spin_unlock(&dev_priv->irq_lock); + + if (rps != NULL) { + list_add(&rps->link, &dev_priv->rps.clients); +@@ -6166,7 +6168,7 @@ void gen6_rps_boost(struct drm_i915_private *dev_priv, + } else + dev_priv->rps.boosts++; + } +- spin_unlock(&dev_priv->rps.client_lock); ++ spin_unlock_irqrestore(&dev_priv->rps.client_lock, flags); + } + + int intel_set_rps(struct drm_i915_private *dev_priv, u8 val) diff --git a/kernel.spec b/kernel.spec index 48362faf3..0ccca855e 100644 --- a/kernel.spec +++ b/kernel.spec @@ -54,7 +54,7 @@ Summary: The Linux kernel %if 0%{?released_kernel} # Do we have a -stable update to apply? -%define stable_update 5 +%define stable_update 6 # Set rpm version accordingly %if 0%{?stable_update} %define stablerev %{stable_update} @@ -655,7 +655,6 @@ Patch335: arm64-cavium-fixes.patch # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c0d8832e78cbfd4a64b7112e34920af4b0b0e60e # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ae2e972dae3cea795e9f8f94eb1601213c2d49f0 -Patch350: arm64-ensure-ready-for-userspace.patch # 400 - IBM (ppc/s390x) patches @@ -690,7 +689,6 @@ Patch619: pci-mark-amd-stoney-gpu-ats-as-broken.patch Patch622: qxl-fixes.patch # rhbz 1431375 -Patch623: HID-rmi-Make-sure-the-HID-device-is-opened-on-resume.patch Patch624: input-rmi4-remove-the-need-for-artifical-IRQ.patch # rhbz 1432684 @@ -704,6 +702,9 @@ Patch629: 0001-platform-x86-peaq-wmi-Add-DMI-check-before-binding-t.patch # rhbz 1482648 Patch630: Input-synaptics---Disable-kernel-tracking-on-SMBus-devices.patch +# Headed upstream +Patch631: drm-i915-boost-GPU-clocks-if-we-miss-the-pageflip.patch + # END OF PATCH DEFINITIONS %endif @@ -2258,6 +2259,10 @@ fi # # %changelog +* Thu Oct 12 2017 Justin M. Forbes <jforbes@fedoraproject.org> - 4.13.6-300 +- Linux v4.13.6 +- Fixes CVE-2017-1000255 (rhbz 1498067 1500335) + * Thu Oct 12 2017 Peter Robinson <pbrobinson@fedoraproject.org> - Fixes for Cavium ThunderX plaforms @@ -1,3 +1,3 @@ SHA512 (linux-4.13.tar.xz) = a557c2f0303ae618910b7106ff63d9978afddf470f03cb72aa748213e099a0ecd5f3119aea6cbd7b61df30ca6ef3ec57044d524b7babbaabddf8b08b8bafa7d2 SHA512 (perf-man-4.13.tar.gz) = 9bcc2cd8e56ec583ed2d8e0b0c88e7a94035a1915e40b3177bb02d6c0f10ddd4df9b097b1f5af59efc624226b613e240ddba8ddc2156f3682f992d5455fc5c03 -SHA512 (patch-4.13.5.xz) = de55b07e52e88e3bc5af54c619933a81f535393f20712f38000bffa77ded22c7a16e70e43c28daf576bcc6cd3ad39387b8e1f430e3d22222f572113d2345df48 +SHA512 (patch-4.13.6.xz) = 40e111f3969b622f982bfb75f8c35aa59d9989a627a4511d8e0090b0c7bbcafcc90567434f5166ef2d17831f0beddb52762107e523414523e1877f67f66ca3f7 |