August 2018 - Linux-stable-mirror

[PATCH v4 8/8] drm/nouveau: Call pm_runtime_get_noresume() from hpd handlers

by Lyude Paul

We can't and don't need to try resuming the device from our hotplug handlers, but hotplug events are generally something we'd like to keep the device awake for whenever possible. So, grab a PM ref safely in our hotplug handlers using pm_runtime_get_noresume() and mark the device as busy once we're finished. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org Cc: Lukas Wunner <lukas(a)wunner.de> Cc: Karol Herbst <karolherbst(a)gmail.com> --- drivers/gpu/drm/nouveau/nouveau_connector.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index 8409c3f2c3a1..5a8e8c1ad647 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -1152,6 +1152,11 @@ nouveau_connector_hotplug(struct nvif_notify *notify) const char *name = connector->name; struct nouveau_encoder *nv_encoder; + /* Resuming the device here isn't possible; but the suspend PM ops + * will wait for us to finish our work before disabling us so this + * should be enough + */ + pm_runtime_get_noresume(drm->dev->dev); nv_connector->hpd_task = current; if (rep->mask & NVIF_NOTIFY_CONN_V0_IRQ) { @@ -1171,6 +1176,9 @@ nouveau_connector_hotplug(struct nvif_notify *notify) } nv_connector->hpd_task = NULL; + + pm_runtime_mark_last_busy(drm->dev->dev); + pm_runtime_put_autosuspend(drm->dev->dev); return NVIF_NOTIFY_KEEP; } -- 2.17.1

6 years, 4 months

1
0
0 0

[PATCH v4 6/8] drm/nouveau: Respond to HPDs by probing one conn at a time

by Lyude Paul

There isn't actually any reason we need to call drm_hpd_irq_event() from our hotplug handler, as we already know which connector the hotplug event was fired for. We're also going to need to avoid probing all connectors needlessly from hotplug handlers anyway so that we can track when nouveau_connector_detect() is being called from the context of it's connector's hotplug handler in order to fix the next deadlocking issue. This is (slightly) faster anyway! Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org Cc: Lukas Wunner <lukas(a)wunner.de> Cc: Karol Herbst <karolherbst(a)gmail.com> --- drivers/gpu/drm/nouveau/nouveau_connector.c | 28 ++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index 010d6db14cba..9714e09f17db 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -1114,6 +1114,32 @@ nouveau_connector_funcs_lvds = { .atomic_get_property = nouveau_conn_atomic_get_property, }; +static void +nouveau_connector_hotplug_probe(struct nouveau_connector *nv_conn) +{ + struct drm_modeset_acquire_ctx ctx; + struct drm_connector *conn = &nv_conn->base; + enum drm_connector_status old_status; + struct drm_device *dev = conn->dev; + bool changed; + + mutex_lock(&dev->mode_config.mutex); + + drm_modeset_acquire_init(&ctx, 0); + drm_modeset_lock(&dev->mode_config.connection_mutex, &ctx); + + old_status = conn->status; + conn->status = drm_helper_probe_detect(conn, &ctx, true); + changed = old_status != conn->status; + + drm_modeset_drop_locks(&ctx); + drm_modeset_acquire_fini(&ctx); + mutex_unlock(&dev->mode_config.mutex); + + if (changed) + drm_kms_helper_hotplug_event(dev); +} + static int nouveau_connector_hotplug(struct nvif_notify *notify) { @@ -1138,7 +1164,7 @@ nouveau_connector_hotplug(struct nvif_notify *notify) nv50_mstm_remove(nv_encoder->dp.mstm); } - drm_helper_hpd_irq_event(connector->dev); + nouveau_connector_hotplug_probe(nv_connector); } return NVIF_NOTIFY_KEEP; -- 2.17.1

6 years, 4 months

1
0
0 0

[PATCH v4 5/8] drm/nouveau: Use pm_runtime_get_noresume() in connector_detect()

by Lyude Paul

It's true we can't resume the device from poll workers in nouveau_connector_detect(). We can however, prevent the autosuspend timer from elapsing immediately if it hasn't already without risking any sort of deadlock with the runtime suspend/resume operations. So do that instead of entirely avoiding grabbing a power reference. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org Cc: Lukas Wunner <lukas(a)wunner.de> Cc: Karol Herbst <karolherbst(a)gmail.com> --- drivers/gpu/drm/nouveau/nouveau_connector.c | 20 +++++++++++--------- 1 file changed, 11 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c index 2a45b4c2ceb0..010d6db14cba 100644 --- a/drivers/gpu/drm/nouveau/nouveau_connector.c +++ b/drivers/gpu/drm/nouveau/nouveau_connector.c @@ -572,12 +572,16 @@ nouveau_connector_detect(struct drm_connector *connector, bool force) nv_connector->edid = NULL; } - /* Outputs are only polled while runtime active, so acquiring a - * runtime PM ref here is unnecessary (and would deadlock upon - * runtime suspend because it waits for polling to finish). + /* Outputs are only polled while runtime active, so resuming the + * device here is unnecessary (and would deadlock upon runtime suspend + * because it waits for polling to finish). We do however, want to + * prevent the autosuspend timer from elapsing during this operation + * if possible. */ - if (!drm_kms_helper_is_poll_worker()) { - ret = pm_runtime_get_sync(connector->dev->dev); + if (drm_kms_helper_is_poll_worker()) { + pm_runtime_get_noresume(dev->dev); + } else { + ret = pm_runtime_get_sync(dev->dev); if (ret < 0 && ret != -EACCES) return conn_status; } @@ -655,10 +659,8 @@ nouveau_connector_detect(struct drm_connector *connector, bool force) out: - if (!drm_kms_helper_is_poll_worker()) { - pm_runtime_mark_last_busy(connector->dev->dev); - pm_runtime_put_autosuspend(connector->dev->dev); - } + pm_runtime_mark_last_busy(dev->dev); + pm_runtime_put_autosuspend(dev->dev); return conn_status; } -- 2.17.1

6 years, 4 months

1
0
0 0

[PATCH v4 4/8] drm/nouveau: Fix deadlock with fb_helper using new helpers

by Lyude Paul

This removes the potential of deadlocking with fb_helper entirely by preventing it from handling hotplugs during the runtime suspend process as early as possible in the suspend process. If it turns out this is not possible, due to some fb_helper action having been queued up before we got a time to disable hotplugging, we simply return -EBUSY so that the runtime PM core attempts autosuspending the device again once fb_helper isn't doing anything. This fixes one of the issues causing deadlocks on runtime suspend/resume with nouveau on my P50. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org Cc: Lukas Wunner <lukas(a)wunner.de> Cc: Karol Herbst <karolherbst(a)gmail.com> --- drivers/gpu/drm/nouveau/nouveau_drm.c | 8 ++++++++ drivers/gpu/drm/nouveau/nouveau_fbcon.c | 1 + 2 files changed, 9 insertions(+) diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c index ee2546db09c9..d47cb5b2af98 100644 --- a/drivers/gpu/drm/nouveau/nouveau_drm.c +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c @@ -836,6 +836,14 @@ nouveau_pmops_runtime_suspend(struct device *dev) return -EBUSY; } + /* There's no way for us to stop fb_helper work in reaction to + * hotplugs later in the RPM process. First off: we don't want to, + * fb_helper should be able to keep the GPU awake. Second off: it is + * capable of grabbing basically any lock in existence. + */ + if (!drm_fb_helper_suspend_hotplug(drm_dev->fb_helper)) + return -EBUSY; + nouveau_switcheroo_optimus_dsm(); ret = nouveau_do_suspend(drm_dev, true); pci_save_state(pdev); diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c b/drivers/gpu/drm/nouveau/nouveau_fbcon.c index 85c1f10bc2b6..963ba630fd04 100644 --- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c +++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c @@ -466,6 +466,7 @@ nouveau_fbcon_set_suspend_work(struct work_struct *work) console_unlock(); if (state == FBINFO_STATE_RUNNING) { + drm_fb_helper_resume_hotplug(drm->dev->fb_helper); pm_runtime_mark_last_busy(drm->dev->dev); pm_runtime_put_sync(drm->dev->dev); } -- 2.17.1

6 years, 4 months

1
0
0 0

[PATCH v4 3/8] drm/fb_helper: Introduce suspend/resume_hotplug()

by Lyude Paul

I'm sure I don't need to tell you that fb_helper's locking is a mess. That being said; fb_helper's locking mess can seriously complicate the runtime suspend/resume operations of drivers because it can invoke atomic commits and connector probing from anywhere that calls drm_fb_helper_hotplug_event(). Since most drivers use drm_fb_helper_output_poll_changed() as their output_poll_changed handler, this can happen in every single context that can fire off a hotplug event. An example: [ 246.669625] INFO: task kworker/4:0:37 blocked for more than 120 seconds. [ 246.673398] Not tainted 4.18.0-rc5Lyude-Test+ #2 [ 246.675271] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.676527] kworker/4:0 D 0 37 2 0x80000000 [ 246.677580] Workqueue: events output_poll_execute [drm_kms_helper] [ 246.678704] Call Trace: [ 246.679753] __schedule+0x322/0xaf0 [ 246.680916] schedule+0x33/0x90 [ 246.681924] schedule_preempt_disabled+0x15/0x20 [ 246.683023] __mutex_lock+0x569/0x9a0 [ 246.684035] ? kobject_uevent_env+0x117/0x7b0 [ 246.685132] ? drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper] [ 246.686179] mutex_lock_nested+0x1b/0x20 [ 246.687278] ? mutex_lock_nested+0x1b/0x20 [ 246.688307] drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper] [ 246.689420] drm_fb_helper_output_poll_changed+0x23/0x30 [drm_kms_helper] [ 246.690462] drm_kms_helper_hotplug_event+0x2a/0x30 [drm_kms_helper] [ 246.691570] output_poll_execute+0x198/0x1c0 [drm_kms_helper] [ 246.692611] process_one_work+0x231/0x620 [ 246.693725] worker_thread+0x214/0x3a0 [ 246.694756] kthread+0x12b/0x150 [ 246.695856] ? wq_pool_ids_show+0x140/0x140 [ 246.696888] ? kthread_create_worker_on_cpu+0x70/0x70 [ 246.697998] ret_from_fork+0x3a/0x50 [ 246.699034] INFO: task kworker/0:1:60 blocked for more than 120 seconds. [ 246.700153] Not tainted 4.18.0-rc5Lyude-Test+ #2 [ 246.701182] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.702278] kworker/0:1 D 0 60 2 0x80000000 [ 246.703293] Workqueue: pm pm_runtime_work [ 246.704393] Call Trace: [ 246.705403] __schedule+0x322/0xaf0 [ 246.706439] ? wait_for_completion+0x104/0x190 [ 246.707393] schedule+0x33/0x90 [ 246.708375] schedule_timeout+0x3a5/0x590 [ 246.709289] ? mark_held_locks+0x58/0x80 [ 246.710208] ? _raw_spin_unlock_irq+0x2c/0x40 [ 246.711222] ? wait_for_completion+0x104/0x190 [ 246.712134] ? trace_hardirqs_on_caller+0xf4/0x190 [ 246.713094] ? wait_for_completion+0x104/0x190 [ 246.713964] wait_for_completion+0x12c/0x190 [ 246.714895] ? wake_up_q+0x80/0x80 [ 246.715727] ? get_work_pool+0x90/0x90 [ 246.716649] flush_work+0x1c9/0x280 [ 246.717483] ? flush_workqueue_prep_pwqs+0x1b0/0x1b0 [ 246.718442] __cancel_work_timer+0x146/0x1d0 [ 246.719247] cancel_delayed_work_sync+0x13/0x20 [ 246.720043] drm_kms_helper_poll_disable+0x1f/0x30 [drm_kms_helper] [ 246.721123] nouveau_pmops_runtime_suspend+0x3d/0xb0 [nouveau] [ 246.721897] pci_pm_runtime_suspend+0x6b/0x190 [ 246.722825] ? pci_has_legacy_pm_support+0x70/0x70 [ 246.723737] __rpm_callback+0x7a/0x1d0 [ 246.724721] ? pci_has_legacy_pm_support+0x70/0x70 [ 246.725607] rpm_callback+0x24/0x80 [ 246.726553] ? pci_has_legacy_pm_support+0x70/0x70 [ 246.727376] rpm_suspend+0x142/0x6b0 [ 246.728185] pm_runtime_work+0x97/0xc0 [ 246.728938] process_one_work+0x231/0x620 [ 246.729796] worker_thread+0x44/0x3a0 [ 246.730614] kthread+0x12b/0x150 [ 246.731395] ? wq_pool_ids_show+0x140/0x140 [ 246.732202] ? kthread_create_worker_on_cpu+0x70/0x70 [ 246.732878] ret_from_fork+0x3a/0x50 [ 246.733768] INFO: task kworker/4:2:422 blocked for more than 120 seconds. [ 246.734587] Not tainted 4.18.0-rc5Lyude-Test+ #2 [ 246.735393] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 246.736113] kworker/4:2 D 0 422 2 0x80000080 [ 246.736789] Workqueue: events_long drm_dp_mst_link_probe_work [drm_kms_helper] [ 246.737665] Call Trace: [ 246.738490] __schedule+0x322/0xaf0 [ 246.739250] schedule+0x33/0x90 [ 246.739908] rpm_resume+0x19c/0x850 [ 246.740750] ? finish_wait+0x90/0x90 [ 246.741541] __pm_runtime_resume+0x4e/0x90 [ 246.742370] nv50_disp_atomic_commit+0x31/0x210 [nouveau] [ 246.743124] drm_atomic_commit+0x4a/0x50 [drm] [ 246.743775] restore_fbdev_mode_atomic+0x1c8/0x240 [drm_kms_helper] [ 246.744603] restore_fbdev_mode+0x31/0x140 [drm_kms_helper] [ 246.745373] drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xb0 [drm_kms_helper] [ 246.746220] drm_fb_helper_set_par+0x2d/0x50 [drm_kms_helper] [ 246.746884] drm_fb_helper_hotplug_event.part.28+0x96/0xb0 [drm_kms_helper] [ 246.747675] drm_fb_helper_output_poll_changed+0x23/0x30 [drm_kms_helper] [ 246.748544] drm_kms_helper_hotplug_event+0x2a/0x30 [drm_kms_helper] [ 246.749439] nv50_mstm_hotplug+0x15/0x20 [nouveau] [ 246.750111] drm_dp_send_link_address+0x177/0x1c0 [drm_kms_helper] [ 246.750764] drm_dp_check_and_send_link_address+0xa8/0xd0 [drm_kms_helper] [ 246.751602] drm_dp_mst_link_probe_work+0x51/0x90 [drm_kms_helper] [ 246.752314] process_one_work+0x231/0x620 [ 246.752979] worker_thread+0x44/0x3a0 [ 246.753838] kthread+0x12b/0x150 [ 246.754619] ? wq_pool_ids_show+0x140/0x140 [ 246.755386] ? kthread_create_worker_on_cpu+0x70/0x70 [ 246.756162] ret_from_fork+0x3a/0x50 [ 246.756847] Showing all locks held in the system: [ 246.758261] 3 locks held by kworker/4:0/37: [ 246.759016] #0: 00000000f8df4d2d ((wq_completion)"events"){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.759856] #1: 00000000e6065461 ((work_completion)(&(&dev->mode_config.output_poll_work)->work)){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.760670] #2: 00000000cb66735f (&helper->lock){+.+.}, at: drm_fb_helper_hotplug_event.part.28+0x20/0xb0 [drm_kms_helper] [ 246.761516] 2 locks held by kworker/0:1/60: [ 246.762274] #0: 00000000fff6be0f ((wq_completion)"pm"){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.762982] #1: 000000005ab44fb4 ((work_completion)(&dev->power.work)){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.763890] 1 lock held by khungtaskd/64: [ 246.764664] #0: 000000008cb8b5c3 (rcu_read_lock){....}, at: debug_show_all_locks+0x23/0x185 [ 246.765588] 5 locks held by kworker/4:2/422: [ 246.766440] #0: 00000000232f0959 ((wq_completion)"events_long"){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.767390] #1: 00000000bb59b134 ((work_completion)(&mgr->work)){+.+.}, at: process_one_work+0x1b3/0x620 [ 246.768154] #2: 00000000cb66735f (&helper->lock){+.+.}, at: drm_fb_helper_restore_fbdev_mode_unlocked+0x4c/0xb0 [drm_kms_helper] [ 246.768966] #3: 000000004c8f0b6b (crtc_ww_class_acquire){+.+.}, at: restore_fbdev_mode_atomic+0x4b/0x240 [drm_kms_helper] [ 246.769921] #4: 000000004c34a296 (crtc_ww_class_mutex){+.+.}, at: drm_modeset_backoff+0x8a/0x1b0 [drm] [ 246.770839] 1 lock held by dmesg/1038: [ 246.771739] 2 locks held by zsh/1172: [ 246.772650] #0: 00000000836d0438 (&tty->ldisc_sem){++++}, at: ldsem_down_read+0x37/0x40 [ 246.773680] #1: 000000001f4f4d48 (&ldata->atomic_read_lock){+.+.}, at: n_tty_read+0xc1/0x870 [ 246.775522] ============================================= Because of this, there's an unreasonable number of places that drm drivers would need to insert special handling to prevent trying to resume the device from all of these contexts that can deadlock. It's difficult even to try synchronizing with fb_helper in these contexts as well, since any of them could introduce a deadlock by waiting to acquire the top-level fb_helper mutex, while it's being held by another thread that might potentially call down to pm_runtime_get_sync(). Luckily-there's no actual reason we need to allow fb_helper to handle hotplugging at all when runtime suspending a device. If a hotplug happens during a runtime suspend operation, there's no reason the driver can't just re-enable fbcon's hotplug handling and bring it up to speed with hotplugging events it may have missed by calling drm_fb_helper_hotplug_event(). So, let's make this easy and just add helpers to handle disabling and enabling fb_helper connector probing() without having to potentially wait on fb_helper to finish it's work. This will let us fix the runtime suspend/resume deadlocks that we've been experiencing with nouveau, along with being able to fix some of the incorrect runtime PM core interaction that other DRM drivers currently perform to work around these issues. Changes since v3: - Actually check if fb_helper is NULL in both new helpers - Actually check drm_fbdev_emulation in both new helpers - Don't fire off a fb_helper hotplug unconditionally; only do it if the following conditions are true (as otherwise, calling this in the wrong spot will cause Bad Things to happen): - fb_helper hotplug handling was actually inhibited previously - fb_helper actually has a delayed hotplug pending - fb_helper is actually bound - fb_helper is actually initialized - Add __must_check to drm_fb_helper_suspend_hotplug(). There's no situation where a driver would actually want to use this without checking the return value, so enforce that - Rewrite and clarify the documentation for both helpers. - Make sure to return true in the drm_fb_helper_suspend_hotplug() stub that's provided in drm_fb_helper.h when CONFIG_DRM_FBDEV_EMULATION isn't enabled - Actually grab the toplevel fb_helper lock in drm_fb_helper_resume_hotplug(), since it's possible other activity (such as a hotplug) could be going on at the same time the driver calls drm_fb_helper_resume_hotplug(). We need this to check whether or not drm_fb_helper_hotplug_event() needs to be called anyway Signed-off-by: Lyude Paul <lyude(a)redhat.com> Cc: stable(a)vger.kernel.org Cc: Lukas Wunner <lukas(a)wunner.de> Cc: Karol Herbst <karolherbst(a)gmail.com> --- drivers/gpu/drm/drm_fb_helper.c | 123 +++++++++++++++++++++++++++++++- include/drm/drm_fb_helper.h | 22 ++++++ 2 files changed, 144 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 2ee1eaa66188..b5f1dee0c3a0 100644 --- a/drivers/gpu/drm/drm_fb_helper.c +++ b/drivers/gpu/drm/drm_fb_helper.c @@ -84,6 +84,11 @@ static DEFINE_MUTEX(kernel_fb_helper_lock); * For suspend/resume consider using drm_mode_config_helper_suspend() and * drm_mode_config_helper_resume() which takes care of fbdev as well. * + * For runtime suspend and runtime resume, drivers which need to disable + * normal hotplug handling should consider using + * drm_fb_helper_suspend_hotplug() and drm_fb_helper_resume_hotplug() to + * avoid deadlocking with fb_helper's hotplug handling. + * * All other functions exported by the fb helper library can be used to * implement the fbdev driver interface by the driver. * @@ -2733,6 +2738,118 @@ int drm_fb_helper_initial_config(struct drm_fb_helper *fb_helper, int bpp_sel) } EXPORT_SYMBOL(drm_fb_helper_initial_config); +/** + * drm_fb_helper_resume_hotplug - Uninhibit fb_helper hotplug handling + * @fb_helper: driver-allocated fbdev helper, can be NULL + * + * Uninhibit fb_helper's hotplug handling after it was previously inhibited by + * a call to drm_fb_helper_suspend_hotplug(). Unlike + * drm_fb_helper_suspend_hotplug(), this function will wait on + * fb_helper->lock. + * + * This helper will take care of handling any hotplug events that happened + * while fb_helper's hotplug handling was suspended. Since this possibly + * implies a call to drm_fb_helper_hotplug_event(), care must be taken when + * calling this function as it may initiate a modeset. + * + * Please note that this function is different from + * drm_fb_helper_set_suspend(). It does not resume fb_helper, it only allows + * fb_helper to probe connectors in response to changes to the device's + * connector configuration if this functionality was previously disabled by + * drm_fb_helper_suspend_hotplug(). Generally, a driver will only want to call + * this in it's runtime resume callbacks. + * + * Drivers calling drm_fb_helper_suspend_hotplug() must make sure to call this + * somewhere in their runtime resume callbacks. + * + * See also: drm_fb_helper_suspend_hotplug() + */ +void +drm_fb_helper_resume_hotplug(struct drm_fb_helper *fb_helper) +{ + bool changed; + + if (!drm_fbdev_emulation || !fb_helper) + return; + + mutex_lock(&fb_helper->lock); + + changed = !fb_helper->deferred_setup && + fb_helper->fb && + drm_fb_helper_is_bound(fb_helper) && + fb_helper->hotplug_suspended && + fb_helper->delayed_hotplug; + if (changed) + fb_helper->delayed_hotplug = false; + + fb_helper->hotplug_suspended = false; + + mutex_unlock(&fb_helper->lock); + + if (changed) + drm_fb_helper_hotplug_event(fb_helper); +} +EXPORT_SYMBOL(drm_fb_helper_resume_hotplug); + +/** + * drm_fb_helper_suspend_hotplug - Attempt to temporarily suspend fb_helper's + * hotplug handling + * @fb_helper: driver-allocated fbdev helper, can be NULL + * + * Temporarily inhibit fb_helper from responding to connector changes without + * blocking on fb_helper->lock, if possible. This can be called by a DRM + * driver early on in it's runtime suspend callback to both check whether or + * not fb_helper is still busy, and prevent hotplugs that might occur part-way + * through the runtime suspend process from being handled by fb_helper until + * drm_fb_helper_resume_hotplug() is called. This dramatically simplifies the + * runtime suspend process, as it eliminates the possibility that fb_helper + * might try to perform a modeset half way through the runtime suspend process + * in response to a connector hotplug, something which will almost certainly + * lead to deadlocking for drivers that need to disable normal hotplug + * handling in their runtime suspend handlers. + * + * Calls to this function should be put at the very start of a driver's + * runtime suspend operation if desired. The driver is then responsible for + * re-enabling fb_helper hotplug handling when normal hotplug detection + * becomes available on the device again by calling + * drm_fb_helper_resume_hotplug(). Usually, a driver will want to re-enable + * fb_helper hotplug handling once the hotplug detection capabilities of its + * devices have returned to normal (e.g. when the device is runtime resumed, + * or after the runtime suspend process was aborted for some reason). + * + * Please note that this function is different from + * drm_fb_helper_set_suspend(), in that it does not actually suspend + * fb_helper. It only prevents fb_helper from responding to connector hotplugs + * on it's own. Generally, a driver will only want to call this in its + * runtime suspend callback. + * + * See also: drm_fb_helper_resume_hotplug() + * + * RETURNS: + * True if hotplug handling was disabled successfully, or fb_helper wasn't + * actually initialized/enabled yet. False if grabbing &fb_helper->lock would + * have meant blocking on fb_helper. When this function returns false, this + * usually implies means that fb_helper is still busy doing something such as + * probing connectors or performing a modeset. Drivers should treat this the + * same way they would any other activity on the device, and abort the runtime + * suspend process as early as possible in response. + */ +bool __must_check +drm_fb_helper_suspend_hotplug(struct drm_fb_helper *fb_helper) +{ + if (!drm_fbdev_emulation || !fb_helper) + return true; + + if (!mutex_trylock(&fb_helper->lock)) + return false; + + fb_helper->hotplug_suspended = true; + mutex_unlock(&fb_helper->lock); + + return true; +} +EXPORT_SYMBOL(drm_fb_helper_suspend_hotplug); + /** * drm_fb_helper_hotplug_event - respond to a hotplug notification by * probing all the outputs attached to the fb @@ -2751,6 +2868,9 @@ EXPORT_SYMBOL(drm_fb_helper_initial_config); * for a race-free fbcon setup and will make sure that the fbdev emulation will * not miss any hotplug events. * + * See also: drm_fb_helper_suspend_hotplug() + * See also: drm_fb_helper_resume_hotplug() + * * RETURNS: * 0 on success and a non-zero error code otherwise. */ @@ -2768,7 +2888,8 @@ int drm_fb_helper_hotplug_event(struct drm_fb_helper *fb_helper) return err; } - if (!fb_helper->fb || !drm_fb_helper_is_bound(fb_helper)) { + if (!fb_helper->fb || !drm_fb_helper_is_bound(fb_helper) || + fb_helper->hotplug_suspended) { fb_helper->delayed_hotplug = true; mutex_unlock(&fb_helper->lock); return err; diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h index b069433e7fc1..9c6e4ceff3af 100644 --- a/include/drm/drm_fb_helper.h +++ b/include/drm/drm_fb_helper.h @@ -232,6 +232,14 @@ struct drm_fb_helper { * See also: @deferred_setup */ int preferred_bpp; + + /** + * @hotplug_suspended: + * + * Whether or not we can currently handle hotplug events, or if we + * need to wait for the DRM device to uninhibit us. + */ + bool hotplug_suspended; }; /** @@ -330,6 +338,11 @@ void drm_fb_helper_fbdev_teardown(struct drm_device *dev); void drm_fb_helper_lastclose(struct drm_device *dev); void drm_fb_helper_output_poll_changed(struct drm_device *dev); + +void drm_fb_helper_resume_hotplug(struct drm_fb_helper *fb_helper); +bool __must_check +drm_fb_helper_suspend_hotplug(struct drm_fb_helper *fb_helper); + #else static inline void drm_fb_helper_prepare(struct drm_device *dev, struct drm_fb_helper *helper, @@ -564,6 +577,15 @@ static inline void drm_fb_helper_output_poll_changed(struct drm_device *dev) { } +static inline void +drm_fb_helper_resume_hotplug(struct drm_fb_helper *fb_helper) +{ +} +static inline bool __must_check +drm_fb_helper_suspend_hotplug(struct drm_fb_helper *fb_helper) +{ + return true; +} #endif static inline int -- 2.17.1

6 years, 4 months

1
0
0 0

Re: [PATCH] pinctrl: freescale: off by one in imx1_pinconf_group_dbg_show()

by Uwe Kleine-König

Hello, On Mon, Jul 30, 2018 at 05:43:43PM +0200, Linus Walleij wrote: > On Fri, Jul 13, 2018 at 4:55 PM Dan Carpenter <dan.carpenter(a)oracle.com> wrote: > > > The info->groups[] array is allocated in imx1_pinctrl_parse_dt(). It > > has info->ngroups elements. Thus the > here should be >= to prevent > > reading one element beyond the end of the array. > > > > Fixes: 30612cd90005 ("pinctrl: imx1 core driver") > > Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> > > Patch applied. > > I am not tagging for stable as it is debug code and does not > affect end users. Not sure this is a valid reason. Distro kernels usually enable debugfs. I'd say an out-of-bounds access that can only be triggered by root should still be fixed. I won't argue but added stable to the addressees of this mail to at least raise awareness. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König | Industrial Linux Solutions | http://www.pengutronix.de/ |

6 years, 4 months

2
1
0 0

[PATCH v2] drm/amd/display: Report non-DP display as disconnected without EDID

by Harry Wentland

[Why] Some boards seem to have a problem where HPD is high on HDMI even though no display is connected. We don't want to report these as connected. DP spec still requires us to report DP displays as connected when HPD is high but we can't read the EDID in order to go to fail-safe mode. [How] If connector_signal is not DP abort detection if we can't retrieve the EDID. Bugzilla: https://bugs.freedesktop.org/107390 Bugzilla: https://bugs.freedesktop.org/106846 Cc: stable(a)vger.kernel.org Signed-off-by: Harry Wentland <harry.wentland(a)amd.com> Acked-by: Alex Deucher <alexander.deucher(a)amd.com> v2: Add Bugzilla and stable --- drivers/gpu/drm/amd/display/dc/core/dc_link.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link.c b/drivers/gpu/drm/amd/display/dc/core/dc_link.c index b180197a41e2..84f0fd15be4c 100644 --- a/drivers/gpu/drm/amd/display/dc/core/dc_link.c +++ b/drivers/gpu/drm/amd/display/dc/core/dc_link.c @@ -744,6 +744,17 @@ bool dc_link_detect(struct dc_link *link, enum dc_detect_reason reason) break; case EDID_NO_RESPONSE: DC_LOG_ERROR("No EDID read.\n"); + + /* + * Abort detection for non-DP connectors if we have + * no EDID + * + * DP needs to report as connected if HDP is high + * even if we have no EDID in order to go to + * fail-safe mode + */ + if (!dc_is_dp_signal(link->connector_signal)) + return false; default: break; } -- 2.17.1

6 years, 4 months

2
1
0 0

request to include on 4.14.y: a4c447533a18ee86e07232d6344ba12b1f9c5077

by Eduardo Valentin

Greg, This is a straight forward cherry-pick. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… Thanks. -- All the best, Eduardo Valentin

6 years, 4 months

2
3
0 0

Re: [PATCH] HID: Bluetooth: hidp: buffer overflow in hidp_process_report

by Mark Salyzyn

On 08/01/2018 09:37 AM, Greg KH wrote: > On Tue, Jul 31, 2018 at 03:02:13PM -0700, Mark Salyzyn wrote: >> CVE-2018-9363 >> >> The buffer length is unsigned at all layers, but gets cast to int and >> checked in hidp_process_report and can lead to a buffer overflow. >> Switch len parameter to unsigned int to resolve issue. >> >> This affects 3.18 and newer kernels. >> >> Signed-off-by: Mark Salyzyn <salyzyn(a)android.com> >> Fixes: a4b1b5877b514b276f0f31efe02388a9c2836728 ("HID: Bluetooth: hidp: make sure input buffers are big enough") >> Cc: Marcel Holtmann <marcel(a)holtmann.org> >> Cc: Johan Hedberg <johan.hedberg(a)gmail.com> >> Cc: "David S. Miller" <davem(a)davemloft.net> >> Cc: Kees Cook <keescook(a)chromium.org> >> Cc: Benjamin Tissoires <benjamin.tissoires(a)redhat.com> >> Cc: linux-bluetooth(a)vger.kernel.org >> Cc: netdev(a)vger.kernel.org >> Cc: linux-kernel(a)vger.kernel.org >> Cc: security(a)kernel.org >> Cc: kernel-team(a)android.com > Nit, you only need to bother security@ if you do not have a fix and need > to figure out one. Thanks, I thought anything with a CVE was to go there according to netdev FAQ (dropped security from response list). > Also, you forgot to cc: stable(a)vger.kernel.org to be included in older > kernel releases :( netdev FAQ said to _not_ copy stable, I am so confused ;-{ (added stable to response list b/c patch is now taken into bluetooth-next) > thanks, > > greg k-h

6 years, 4 months

2
1
0 0

Re: [PATCH v2] arch/x86: Fix boot_cpu_data.microcode version output

by Oleksandr Natalenko

Hi. > I tested this on AMD Ryzen & Intel Broadwell system and dumped the > boot_cpu_data before and after a microcode update. On the Intel > system I also did a fatal MCE using mce-inject to confirm the output > from the mce handling code. > > P. > > ---8<--- > > On systems where a runtime microcode update has occurred the microcode > version output in a MCE log record is wrong because > boot_cpu_data.microcode is not updated during runtime. > > Update boot_cpu_data.microcode when the BSP's microcode is updated. > > Fixes: fa94d0c6e0f3 ("x86/MCE: Save microcode revision in machine check > records") > Suggested-by: Borislav Petkov <bp(a)alien8.com> > Signed-off-by: Prarit Bhargava <prarit(a)redhat.com> > Cc: stable(a)vger.kernel.org > Cc: sironi(a)amazon.de > Cc: tony.luck(a)intel.com > --- > Changes in v2: Use mc_amd->hdr.patch_id on AMD > > arch/x86/kernel/cpu/microcode/amd.c | 4 ++++ > arch/x86/kernel/cpu/microcode/intel.c | 4 ++++ > 2 files changed, 8 insertions(+) > > diff --git a/arch/x86/kernel/cpu/microcode/amd.c > b/arch/x86/kernel/cpu/microcode/amd.c > index 0624957aa068..63b072377ba4 100644 > --- a/arch/x86/kernel/cpu/microcode/amd.c > +++ b/arch/x86/kernel/cpu/microcode/amd.c > @@ -537,6 +537,10 @@ static enum ucode_state apply_microcode_amd(int > cpu) > uci->cpu_sig.rev = mc_amd->hdr.patch_id; > c->microcode = mc_amd->hdr.patch_id; > > + /* Update boot_cpu_data's revision too, if we're on the BSP: */ > + if (c->cpu_index == boot_cpu_data.cpu_index) > + boot_cpu_data.microcode = mc_amd->hdr.patch_id; > + > return UCODE_UPDATED; > } > > diff --git a/arch/x86/kernel/cpu/microcode/intel.c > b/arch/x86/kernel/cpu/microcode/intel.c > index 97ccf4c3b45b..256d336cbc04 100644 > --- a/arch/x86/kernel/cpu/microcode/intel.c > +++ b/arch/x86/kernel/cpu/microcode/intel.c > @@ -851,6 +851,10 @@ static enum ucode_state apply_microcode_intel(int > cpu) > uci->cpu_sig.rev = rev; > c->microcode = rev; > > + /* Update boot_cpu_data's revision too, if we're on the BSP: */ > + if (c->cpu_index == boot_cpu_data.cpu_index) > + boot_cpu_data.microcode = rev; > + > return UCODE_UPDATED; > } > > -- > 2.17.0 After this patch, do we preserve an original microcode version somewhere? If no, why? Sometimes it is useful while debugging another crash because of faulty microcode. Thanks. -- Oleksandr Natalenko (post-factum)

6 years, 4 months

2
2
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2018