This is a note to let you know that I've just added the patch titled
drm/i915: Re-register PMIC bus access notifier on runtime resume
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-i915-re-register-pmic-bus-access-notifier-on-runtime-resume.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 294cf1af8cf2eb0d1eced377fdfb9a2d3f0e8b42 Mon Sep 17 00:00:00 2001
From: Hans de Goede <j.w.r.degoede(a)gmail.com>
Date: Tue, 14 Nov 2017 14:55:17 +0100
Subject: drm/i915: Re-register PMIC bus access notifier on runtime resume
From: Hans de Goede <j.w.r.degoede(a)gmail.com>
commit 294cf1af8cf2eb0d1eced377fdfb9a2d3f0e8b42 upstream.
intel_uncore_suspend() unregisters the uncore code's PMIC bus access
notifier and gets called on both normal and runtime suspend.
intel_uncore_resume_early() re-registers the notifier, but only on
normal resume. Add a new intel_uncore_runtime_resume() function which
only re-registers the notifier and call that on runtime resume.
Reported-by: Imre Deak <imre.deak(a)intel.com>
Reviewed-by: Imre Deak <imre.deak(a)intel.com>
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171114135518.15981-2-hdegoe…
(cherry picked from commit bedf4d79c3654921839b62246b0965ddb308b201)
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/i915_drv.c | 2 ++
drivers/gpu/drm/i915/intel_uncore.c | 6 ++++++
drivers/gpu/drm/i915/intel_uncore.h | 1 +
3 files changed, 9 insertions(+)
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2591,6 +2591,8 @@ static int intel_runtime_resume(struct d
ret = vlv_resume_prepare(dev_priv, true);
}
+ intel_uncore_runtime_resume(dev_priv);
+
/*
* No point of rolling back things in case of an error, as the best
* we can do is to hope that things will still work (and disable RPM).
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -434,6 +434,12 @@ void intel_uncore_resume_early(struct dr
i915_check_and_clear_faults(dev_priv);
}
+void intel_uncore_runtime_resume(struct drm_i915_private *dev_priv)
+{
+ iosf_mbi_register_pmic_bus_access_notifier(
+ &dev_priv->uncore.pmic_bus_access_nb);
+}
+
void intel_uncore_sanitize(struct drm_i915_private *dev_priv)
{
i915.enable_rc6 = sanitize_rc6_option(dev_priv, i915.enable_rc6);
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -121,6 +121,7 @@ bool intel_uncore_arm_unclaimed_mmio_det
void intel_uncore_fini(struct drm_i915_private *dev_priv);
void intel_uncore_suspend(struct drm_i915_private *dev_priv);
void intel_uncore_resume_early(struct drm_i915_private *dev_priv);
+void intel_uncore_runtime_resume(struct drm_i915_private *dev_priv);
u64 intel_uncore_edram_size(struct drm_i915_private *dev_priv);
void assert_forcewakes_inactive(struct drm_i915_private *dev_priv);
Patches currently in stable-queue which might be from j.w.r.degoede(a)gmail.com are
queue-4.14/drm-i915-re-register-pmic-bus-access-notifier-on-runtime-resume.patch
queue-4.14/drm-i915-fix-false-positive-assert_rpm_wakelock_held-in-i915_pmic_bus_access_notifier-v2.patch
This is a note to let you know that I've just added the patch titled
drm/i915: Prevent zero length "index" write
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-i915-prevent-zero-length-index-write.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 56350fb8978bbf4aafe08f21234e161dd128b417 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com>
Date: Thu, 23 Nov 2017 21:41:57 +0200
Subject: drm/i915: Prevent zero length "index" write
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
commit 56350fb8978bbf4aafe08f21234e161dd128b417 upstream.
The hardware always writes one or two bytes in the index portion of
an indexed transfer. Make sure the message we send as the index
doesn't have a zero length.
Cc: Daniel Kurtz <djkurtz(a)chromium.org>
Cc: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: Sean Paul <seanpaul(a)chromium.org>
Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions")
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-3-ville.…
Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk>
(cherry picked from commit bb9e0d4bca50f429152e74a459160b41f3d60fb2)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_i2c.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -439,7 +439,8 @@ gmbus_is_index_read(struct i2c_msg *msgs
{
return (i + 1 < num &&
msgs[i].addr == msgs[i + 1].addr &&
- !(msgs[i].flags & I2C_M_RD) && msgs[i].len <= 2 &&
+ !(msgs[i].flags & I2C_M_RD) &&
+ (msgs[i].len == 1 || msgs[i].len == 2) &&
(msgs[i + 1].flags & I2C_M_RD));
}
Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are
queue-4.14/drm-i915-prevent-zero-length-index-write.patch
queue-4.14/drm-edid-don-t-send-non-zero-yq-in-avi-infoframe-for-hdmi-1.x-sinks.patch
queue-4.14/drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch
queue-4.14/drm-vblank-fix-flip-event-vblank-count.patch
queue-4.14/drm-vblank-tune-drm_crtc_accurate_vblank_count-warn-down-to-a-debug.patch
This is a note to let you know that I've just added the patch titled
drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-i915-gvt-correct-addr_4k-2m-1g_mask-definition.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From b721b65af4eb46df6a1d9e34b14003225e403565 Mon Sep 17 00:00:00 2001
From: Xiong Zhang <xiong.y.zhang(a)intel.com>
Date: Tue, 28 Nov 2017 07:29:54 +0800
Subject: drm/i915/gvt: Correct ADDR_4K/2M/1G_MASK definition
From: Xiong Zhang <xiong.y.zhang(a)intel.com>
commit b721b65af4eb46df6a1d9e34b14003225e403565 upstream.
For ADDR_4K_MASK, bit[45..12] should be 1, all other bits
should be 0. The current definition wrongly set bit[46] as 1
also. This path fixes this.
v2: Add commit message, fixes and cc stable.(Zhenyu)
Fixes: 2707e4446688("drm/i915/gvt: vGPU graphics memory virtualization")
Signed-off-by: Xiong Zhang <xiong.y.zhang(a)intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/gvt/gtt.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/gpu/drm/i915/gvt/gtt.c
+++ b/drivers/gpu/drm/i915/gvt/gtt.c
@@ -311,9 +311,9 @@ static inline int gtt_set_entry64(void *
#define GTT_HAW 46
-#define ADDR_1G_MASK (((1UL << (GTT_HAW - 30 + 1)) - 1) << 30)
-#define ADDR_2M_MASK (((1UL << (GTT_HAW - 21 + 1)) - 1) << 21)
-#define ADDR_4K_MASK (((1UL << (GTT_HAW - 12 + 1)) - 1) << 12)
+#define ADDR_1G_MASK (((1UL << (GTT_HAW - 30)) - 1) << 30)
+#define ADDR_2M_MASK (((1UL << (GTT_HAW - 21)) - 1) << 21)
+#define ADDR_4K_MASK (((1UL << (GTT_HAW - 12)) - 1) << 12)
static unsigned long gen8_gtt_get_pfn(struct intel_gvt_gtt_entry *e)
{
Patches currently in stable-queue which might be from xiong.y.zhang(a)intel.com are
queue-4.14/drm-i915-gvt-correct-addr_4k-2m-1g_mask-definition.patch
This is a note to let you know that I've just added the patch titled
drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-i915-fix-false-positive-assert_rpm_wakelock_held-in-i915_pmic_bus_access_notifier-v2.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From f4359cedfb43b934f38c50d1604db21333abe57b Mon Sep 17 00:00:00 2001
From: Hans de Goede <j.w.r.degoede(a)gmail.com>
Date: Fri, 10 Nov 2017 16:03:01 +0100
Subject: drm/i915: Fix false-positive assert_rpm_wakelock_held in i915_pmic_bus_access_notifier v2
From: Hans de Goede <j.w.r.degoede(a)gmail.com>
commit f4359cedfb43b934f38c50d1604db21333abe57b upstream.
assert_rpm_wakelock_held is triggered from i915_pmic_bus_access_notifier
even though it gets unregistered on (runtime) suspend, this is caused
by a race happening under the following circumstances:
intel_runtime_pm_put does:
atomic_dec(&dev_priv->pm.wakeref_count);
pm_runtime_mark_last_busy(kdev);
pm_runtime_put_autosuspend(kdev);
And pm_runtime_put_autosuspend calls intel_runtime_suspend from
a workqueue, so there is ample of time between the atomic_dec() and
intel_runtime_suspend() unregistering the notifier. If the notifier
gets called in this windowd assert_rpm_wakelock_held falsely triggers
(at this point we're not runtime-suspended yet).
This commit adds disable_rpm_wakeref_asserts and
enable_rpm_wakeref_asserts calls around the
intel_uncore_forcewake_get(FORCEWAKE_ALL) call in
i915_pmic_bus_access_notifier fixing the false-positive WARN_ON.
Changes in v2:
-Reword comment explaining why disabling the wakeref asserts is
ok and necessary
Reported-by: FKr <bugs-freedesktop(a)ubermail.me>
Reviewed-by: Imre Deak <imre.deak(a)intel.com>
Signed-off-by: Hans de Goede <hdegoede(a)redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171110150301.9601-2-hdegoed…
(cherry picked from commit ce30560c80dead91e98a03d90fb8791e57a9b69d)
Signed-off-by: Jani Nikula <jani.nikula(a)intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_uncore.c | 7 +++++++
1 file changed, 7 insertions(+)
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1171,8 +1171,15 @@ static int i915_pmic_bus_access_notifier
* bus, which will be busy after this notification, leading to:
* "render: timed out waiting for forcewake ack request."
* errors.
+ *
+ * The notifier is unregistered during intel_runtime_suspend(),
+ * so it's ok to access the HW here without holding a RPM
+ * wake reference -> disable wakeref asserts for the time of
+ * the access.
*/
+ disable_rpm_wakeref_asserts(dev_priv);
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+ enable_rpm_wakeref_asserts(dev_priv);
break;
case MBI_PMIC_BUS_ACCESS_END:
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
Patches currently in stable-queue which might be from j.w.r.degoede(a)gmail.com are
queue-4.14/drm-i915-re-register-pmic-bus-access-notifier-on-runtime-resume.patch
queue-4.14/drm-i915-fix-false-positive-assert_rpm_wakelock_held-in-i915_pmic_bus_access_notifier-v2.patch
This is a note to let you know that I've just added the patch titled
drm/i915/fbdev: Serialise early hotplug events with async fbdev config
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-i915-fbdev-serialise-early-hotplug-events-with-async-fbdev-config.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a45b30a6c5db631e2ba680304bd5edd0cd1f9643 Mon Sep 17 00:00:00 2001
From: Chris Wilson <chris(a)chris-wilson.co.uk>
Date: Sat, 25 Nov 2017 19:41:55 +0000
Subject: drm/i915/fbdev: Serialise early hotplug events with async fbdev config
From: Chris Wilson <chris(a)chris-wilson.co.uk>
commit a45b30a6c5db631e2ba680304bd5edd0cd1f9643 upstream.
As both the hotplug event and fbdev configuration run asynchronously, it
is possible for them to run concurrently. If configuration fails, we were
freeing the fbdev causing a use-after-free in the hotplug event.
<7>[ 3069.935211] [drm:intel_fb_initial_config [i915]] Not using firmware configuration
<7>[ 3069.935225] [drm:drm_setup_crtcs] looking for cmdline mode on connector 77
<7>[ 3069.935229] [drm:drm_setup_crtcs] looking for preferred mode on connector 77 0
<7>[ 3069.935233] [drm:drm_setup_crtcs] found mode 3200x1800
<7>[ 3069.935236] [drm:drm_setup_crtcs] picking CRTCs for 8192x8192 config
<7>[ 3069.935253] [drm:drm_setup_crtcs] desired mode 3200x1800 set on crtc 43 (0,0)
<7>[ 3069.935323] [drm:intelfb_create [i915]] no BIOS fb, allocating a new one
<4>[ 3069.967737] general protection fault: 0000 [#1] PREEMPT SMP
<0>[ 3069.977453] ---------------------------------
<4>[ 3069.977457] Modules linked in: i915(+) vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm r8169 mei_me mii prime_numbers mei i2c_hid pinctrl_geminilake pinctrl_intel [last unloaded: i915]
<4>[ 3069.977492] CPU: 1 PID: 15414 Comm: kworker/1:0 Tainted: G U 4.14.0-CI-CI_DRM_3388+ #1
<4>[ 3069.977497] Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0062.B30.1708222146 08/22/2017
<4>[ 3069.977508] Workqueue: events output_poll_execute
<4>[ 3069.977512] task: ffff880177734e40 task.stack: ffffc90001fe4000
<4>[ 3069.977519] RIP: 0010:__lock_acquire+0x109/0x1b60
<4>[ 3069.977523] RSP: 0018:ffffc90001fe7bb0 EFLAGS: 00010002
<4>[ 3069.977526] RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000282 RCX: 0000000000000000
<4>[ 3069.977530] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff880170d4efd0
<4>[ 3069.977534] RBP: ffffc90001fe7c70 R08: 0000000000000001 R09: 0000000000000000
<4>[ 3069.977538] R10: 0000000000000000 R11: ffffffff81899609 R12: ffff880170d4efd0
<4>[ 3069.977542] R13: ffff880177734e40 R14: 0000000000000001 R15: 0000000000000000
<4>[ 3069.977547] FS: 0000000000000000(0000) GS:ffff88017fc80000(0000) knlGS:0000000000000000
<4>[ 3069.977551] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[ 3069.977555] CR2: 00007f7e8b7bcf04 CR3: 0000000003e0f000 CR4: 00000000003406e0
<4>[ 3069.977559] Call Trace:
<4>[ 3069.977565] ? mark_held_locks+0x64/0x90
<4>[ 3069.977571] ? _raw_spin_unlock_irq+0x24/0x50
<4>[ 3069.977575] ? _raw_spin_unlock_irq+0x24/0x50
<4>[ 3069.977579] ? trace_hardirqs_on_caller+0xde/0x1c0
<4>[ 3069.977583] ? _raw_spin_unlock_irq+0x2f/0x50
<4>[ 3069.977588] ? finish_task_switch+0xa5/0x210
<4>[ 3069.977592] ? lock_acquire+0xaf/0x200
<4>[ 3069.977596] lock_acquire+0xaf/0x200
<4>[ 3069.977600] ? __mutex_lock+0x5e9/0x9b0
<4>[ 3069.977604] _raw_spin_lock+0x2a/0x40
<4>[ 3069.977608] ? __mutex_lock+0x5e9/0x9b0
<4>[ 3069.977612] __mutex_lock+0x5e9/0x9b0
<4>[ 3069.977616] ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0
<4>[ 3069.977621] ? drm_fb_helper_hotplug_event.part.19+0x16/0xa0
<4>[ 3069.977625] drm_fb_helper_hotplug_event.part.19+0x16/0xa0
<4>[ 3069.977630] output_poll_execute+0x8d/0x180
<4>[ 3069.977635] process_one_work+0x22e/0x660
<4>[ 3069.977640] worker_thread+0x48/0x3a0
<4>[ 3069.977644] ? _raw_spin_unlock_irqrestore+0x4c/0x60
<4>[ 3069.977649] kthread+0x102/0x140
<4>[ 3069.977653] ? process_one_work+0x660/0x660
<4>[ 3069.977657] ? kthread_create_on_node+0x40/0x40
<4>[ 3069.977662] ret_from_fork+0x27/0x40
<4>[ 3069.977666] Code: 8d 62 f8 c3 49 81 3c 24 e0 fa 3c 82 41 be 00 00 00 00 45 0f 45 f0 83 fe 01 77 86 89 f0 49 8b 44 c4 08 48 85 c0 0f 84 76 ff ff ff <f0> ff 80 38 01 00 00 8b 1d 62 f9 e8 01 45 8b 85 b8 08 00 00 85
<1>[ 3069.977707] RIP: __lock_acquire+0x109/0x1b60 RSP: ffffc90001fe7bb0
<4>[ 3069.977712] ---[ end trace 4ad012eb3af62df7 ]---
In order to keep the dev_priv->ifbdev alive after failure, we have to
avoid the free and leave it empty until we unload the module (which is
less than ideal, but a necessary evil for simplicity). Then we can use
intel_fbdev_sync() to serialise the hotplug event with the configuration.
The serialisation between the two was removed in commit 934458c2c95d
("Revert "drm/i915: Fix races on fbdev""), but the use after free is much
older, commit 366e39b4d2c5 ("drm/i915: Tear down fbdev if initialization
fails")
Fixes: 366e39b4d2c5 ("drm/i915: Tear down fbdev if initialization fails")
Fixes: 934458c2c95d ("Revert "drm/i915: Fix races on fbdev"")
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Lukas Wunner <lukas(a)wunner.de>
Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Reviewed-by: Lukas Wunner <lukas(a)wunner.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20171125194155.355-1-chris@ch…
(cherry picked from commit ad88d7fc6c032ddfb32b8d496a070ab71de3a64f)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_fbdev.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -694,10 +694,8 @@ static void intel_fbdev_initial_config(v
/* Due to peculiar init order wrt to hpd handling this is separate. */
if (drm_fb_helper_initial_config(&ifbdev->helper,
- ifbdev->preferred_bpp)) {
+ ifbdev->preferred_bpp))
intel_fbdev_unregister(to_i915(ifbdev->helper.dev));
- intel_fbdev_fini(to_i915(ifbdev->helper.dev));
- }
}
void intel_fbdev_initial_config_async(struct drm_device *dev)
@@ -797,7 +795,11 @@ void intel_fbdev_output_poll_changed(str
{
struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
- if (ifbdev)
+ if (!ifbdev)
+ return;
+
+ intel_fbdev_sync(ifbdev);
+ if (ifbdev->vma)
drm_fb_helper_hotplug_event(&ifbdev->helper);
}
Patches currently in stable-queue which might be from chris(a)chris-wilson.co.uk are
queue-4.14/drm-i915-prevent-zero-length-index-write.patch
queue-4.14/drm-i915-fbdev-serialise-early-hotplug-events-with-async-fbdev-config.patch
queue-4.14/drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch
This is a note to let you know that I've just added the patch titled
x86/entry/64: Add missing irqflags tracing to native_load_gs_index()
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-entry-64-add-missing-irqflags-tracing-to-native_load_gs_index.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ca37e57bbe0cf1455ea3e84eb89ed04a132d59e1 Mon Sep 17 00:00:00 2001
From: Andy Lutomirski <luto(a)kernel.org>
Date: Wed, 22 Nov 2017 20:39:16 -0800
Subject: x86/entry/64: Add missing irqflags tracing to native_load_gs_index()
From: Andy Lutomirski <luto(a)kernel.org>
commit ca37e57bbe0cf1455ea3e84eb89ed04a132d59e1 upstream.
Running this code with IRQs enabled (where dummy_lock is a spinlock):
static void check_load_gs_index(void)
{
/* This will fail. */
load_gs_index(0xffff);
spin_lock(&dummy_lock);
spin_unlock(&dummy_lock);
}
Will generate a lockdep warning. The issue is that the actual write
to %gs would cause an exception with IRQs disabled, and the exception
handler would, as an inadvertent side effect, update irqflag tracing
to reflect the IRQs-off status. native_load_gs_index() would then
turn IRQs back on and return with irqflag tracing still thinking that
IRQs were off. The dummy lock-and-unlock causes lockdep to notice the
error and warn.
Fix it by adding the missing tracing.
Apparently nothing did this in a context where it mattered. I haven't
tried to find a code path that would actually exhibit the warning if
appropriately nasty user code were running.
I suspect that the security impact of this bug is very, very low --
production systems don't run with lockdep enabled, and the warning is
mostly harmless anyway.
Found during a quick audit of the entry code to try to track down an
unrelated bug that Ingo found in some still-in-development code.
Signed-off-by: Andy Lutomirski <luto(a)kernel.org>
Cc: Borislav Petkov <bpetkov(a)suse.de>
Cc: Brian Gerst <brgerst(a)gmail.com>
Cc: Dave Hansen <dave.hansen(a)intel.com>
Cc: Josh Poimboeuf <jpoimboe(a)redhat.com>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Link: http://lkml.kernel.org/r/e1aeb0e6ba8dd430ec36c8a35e63b429698b4132.151141191…
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/entry/entry_64.S | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -54,15 +54,19 @@ ENTRY(native_usergs_sysret64)
ENDPROC(native_usergs_sysret64)
#endif /* CONFIG_PARAVIRT */
-.macro TRACE_IRQS_IRETQ
+.macro TRACE_IRQS_FLAGS flags:req
#ifdef CONFIG_TRACE_IRQFLAGS
- bt $9, EFLAGS(%rsp) /* interrupts off? */
+ bt $9, \flags /* interrupts off? */
jnc 1f
TRACE_IRQS_ON
1:
#endif
.endm
+.macro TRACE_IRQS_IRETQ
+ TRACE_IRQS_FLAGS EFLAGS(%rsp)
+.endm
+
/*
* When dynamic function tracer is enabled it will add a breakpoint
* to all locations that it is about to modify, sync CPUs, update
@@ -868,11 +872,13 @@ idtentry simd_coprocessor_error do_simd
ENTRY(native_load_gs_index)
pushfq
DISABLE_INTERRUPTS(CLBR_ANY & ~CLBR_RDI)
+ TRACE_IRQS_OFF
SWAPGS
.Lgs_change:
movl %edi, %gs
2: ALTERNATIVE "", "mfence", X86_BUG_SWAPGS_FENCE
SWAPGS
+ TRACE_IRQS_FLAGS (%rsp)
popfq
ret
END(native_load_gs_index)
Patches currently in stable-queue which might be from luto(a)kernel.org are
queue-4.9/x86-entry-64-add-missing-irqflags-tracing-to-native_load_gs_index.patch
This is a note to let you know that I've just added the patch titled
drm/i915: Don't try indexed reads to alternate slave addresses
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch
and it can be found in the queue-4.14 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ae5c631e605a452a5a0e73205a92810c01ed954b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com>
Date: Thu, 23 Nov 2017 21:41:56 +0200
Subject: drm/i915: Don't try indexed reads to alternate slave addresses
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
commit ae5c631e605a452a5a0e73205a92810c01ed954b upstream.
We can only specify the one slave address to indexed reads/writes.
Make sure the messages we check are destined to the same slave
address before deciding to do an indexed transfer.
Cc: Daniel Kurtz <djkurtz(a)chromium.org>
Cc: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: Sean Paul <seanpaul(a)chromium.org>
Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions")
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-2-ville.…
Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk>
(cherry picked from commit c4deb62d7821672265b87952bcd1c808f3bf3e8f)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_i2c.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -438,6 +438,7 @@ static bool
gmbus_is_index_read(struct i2c_msg *msgs, int i, int num)
{
return (i + 1 < num &&
+ msgs[i].addr == msgs[i + 1].addr &&
!(msgs[i].flags & I2C_M_RD) && msgs[i].len <= 2 &&
(msgs[i + 1].flags & I2C_M_RD));
}
Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are
queue-4.14/drm-i915-prevent-zero-length-index-write.patch
queue-4.14/drm-edid-don-t-send-non-zero-yq-in-avi-infoframe-for-hdmi-1.x-sinks.patch
queue-4.14/drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch
queue-4.14/drm-vblank-fix-flip-event-vblank-count.patch
queue-4.14/drm-vblank-tune-drm_crtc_accurate_vblank_count-warn-down-to-a-debug.patch
This is a note to let you know that I've just added the patch titled
drm/i915: Prevent zero length "index" write
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-i915-prevent-zero-length-index-write.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 56350fb8978bbf4aafe08f21234e161dd128b417 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com>
Date: Thu, 23 Nov 2017 21:41:57 +0200
Subject: drm/i915: Prevent zero length "index" write
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
commit 56350fb8978bbf4aafe08f21234e161dd128b417 upstream.
The hardware always writes one or two bytes in the index portion of
an indexed transfer. Make sure the message we send as the index
doesn't have a zero length.
Cc: Daniel Kurtz <djkurtz(a)chromium.org>
Cc: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: Sean Paul <seanpaul(a)chromium.org>
Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions")
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-3-ville.…
Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk>
(cherry picked from commit bb9e0d4bca50f429152e74a459160b41f3d60fb2)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_i2c.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -395,7 +395,8 @@ gmbus_is_index_read(struct i2c_msg *msgs
{
return (i + 1 < num &&
msgs[i].addr == msgs[i + 1].addr &&
- !(msgs[i].flags & I2C_M_RD) && msgs[i].len <= 2 &&
+ !(msgs[i].flags & I2C_M_RD) &&
+ (msgs[i].len == 1 || msgs[i].len == 2) &&
(msgs[i + 1].flags & I2C_M_RD));
}
Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are
queue-3.18/drm-i915-prevent-zero-length-index-write.patch
queue-3.18/drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch
This is a note to let you know that I've just added the patch titled
drm/i915: Don't try indexed reads to alternate slave addresses
to the 3.18-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch
and it can be found in the queue-3.18 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From ae5c631e605a452a5a0e73205a92810c01ed954b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com>
Date: Thu, 23 Nov 2017 21:41:56 +0200
Subject: drm/i915: Don't try indexed reads to alternate slave addresses
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
commit ae5c631e605a452a5a0e73205a92810c01ed954b upstream.
We can only specify the one slave address to indexed reads/writes.
Make sure the messages we check are destined to the same slave
address before deciding to do an indexed transfer.
Cc: Daniel Kurtz <djkurtz(a)chromium.org>
Cc: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch>
Cc: Sean Paul <seanpaul(a)chromium.org>
Fixes: 56f9eac05489 ("drm/i915/intel_i2c: use INDEX cycles for i2c read transactions")
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171123194157.25367-2-ville.…
Reviewed-by: Chris Wilson <chris(a)chris-wilson.co.uk>
(cherry picked from commit c4deb62d7821672265b87952bcd1c808f3bf3e8f)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/gpu/drm/i915/intel_i2c.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -394,6 +394,7 @@ static bool
gmbus_is_index_read(struct i2c_msg *msgs, int i, int num)
{
return (i + 1 < num &&
+ msgs[i].addr == msgs[i + 1].addr &&
!(msgs[i].flags & I2C_M_RD) && msgs[i].len <= 2 &&
(msgs[i + 1].flags & I2C_M_RD));
}
Patches currently in stable-queue which might be from ville.syrjala(a)linux.intel.com are
queue-3.18/drm-i915-prevent-zero-length-index-write.patch
queue-3.18/drm-i915-don-t-try-indexed-reads-to-alternate-slave-addresses.patch
>From the shrinker paths, we want to relinquish the GPU and GGTT access to
the object, releasing the backing storage back to the system for
swapout. As a part of that process we would unpin the pages, marking
them for access by the CPU (for the swapout/swapin). However, if that
process was interrupted after unbind the vma, we missed a flush of the
inflight GGTT writes before we made that GTT space available again for
reuse, with the prospect that we would redirect them to another page.
The bug dates back to the introduction of multiple GGTT vma, but the
code itself dates to commit 02bef8f98d26 ("drm/i915: Unbind closed vma
for i915_gem_object_unbind()").
Fixes: 02bef8f98d26 ("drm/i915: Unbind closed vma for i915_gem_object_unbind()")
Fixes: c5ad54cf7dd8 ("drm/i915: Use partial view in mmap fault handler")
Signed-off-by: Chris Wilson <chris(a)chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen(a)linux.intel.com>
Cc: stable(a)vger.kernel.org
---
drivers/gpu/drm/i915/i915_gem.c | 9 +--------
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e083f242b8dc..80b78fb5daac 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -330,17 +330,10 @@ int i915_gem_object_unbind(struct drm_i915_gem_object *obj)
* must wait for all rendering to complete to the object (as unbinding
* must anyway), and retire the requests.
*/
- ret = i915_gem_object_wait(obj,
- I915_WAIT_INTERRUPTIBLE |
- I915_WAIT_LOCKED |
- I915_WAIT_ALL,
- MAX_SCHEDULE_TIMEOUT,
- NULL);
+ ret = i915_gem_object_set_to_cpu_domain(obj, false);
if (ret)
return ret;
- i915_gem_retire_requests(to_i915(obj->base.dev));
-
while ((vma = list_first_entry_or_null(&obj->vma_list,
struct i915_vma,
obj_link))) {
--
2.15.1