linux-kernel - Re: [Intel-gfx] [PATCH] drm/i915: Hold struct

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAObL_7EqL+1rhP=9go0EnCrVwWoZqgpVw0ZmLYa99vvFBJTmGQ@mail.gmail.com>
Date:	Mon, 25 Jul 2011 22:52:15 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	Jesse Barnes <jbarnes@...tuousgeek.org>
Cc:	Keith Packard <keithp@...thp.com>,
	Dave Airlie <airlied@...hat.com>,
	intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing

On Mon, Jul 25, 2011 at 1:37 PM, Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
> On Mon, 25 Jul 2011 10:10:29 -0700
> Keith Packard <keithp@...thp.com> wrote:
>
>> Hotplug detection is a mode setting operation and must hold the
>> struct_mutex or risk colliding with other mode setting operations.
>>
>> In particular, the display port hotplug function attempts to re-train
>> the link if the monitor is supposed to be running when plugged back
>> in. If that happens while mode setting is underway, the link will get
>> scrambled, leaving it in an inconsistent state.
>>
>> Signed-off-by: Keith Packard <keithp@...thp.com>
>> ---
>>  drivers/gpu/drm/i915/i915_irq.c |    3 +++
>>  1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
>> index 3b03f85..5fe8f28 100644
>> --- a/drivers/gpu/drm/i915/i915_irq.c
>> +++ b/drivers/gpu/drm/i915/i915_irq.c
>> @@ -306,12 +306,15 @@ static void i915_hotplug_work_func(struct work_struct *work)
>>       struct drm_mode_config *mode_config = &dev->mode_config;
>>       struct intel_encoder *encoder;
>>
>> +     mutex_lock(&dev_priv->dev->struct_mutex);
>>       DRM_DEBUG_KMS("running encoder hotplug functions\n");
>>
>>       list_for_each_entry(encoder, &mode_config->encoder_list, base.head)
>>               if (encoder->hot_plug)
>>                       encoder->hot_plug(encoder);
>>
>> +     mutex_unlock(&dev_priv->dev->struct_mutex);
>> +
>>       /* Just fire off a uevent and let userspace tell us what to do */
>>       drm_helper_hpd_irq_event(dev);
>>  }
>
> yay, sounds like this will fix Andrew's problem and probably lots of
> other random DP related failures.

Doesn't help :(

When I do 'xset dpms force off', one of two things happens.  Either
the display comes back all by itself or it never comes back until I
power cycle it.

If the display is generating a hotplug event after the dpms code drops
the link, then with "drm/i915/dp: remove DPMS mode tracking from DP"
applied the driver will try to bring the display back up.  Maybe my
display can't handle coming back up that quickly after being told to
go to sleep, or maybe there's another bug.

Is the original patch supposed to bring the display up if the user
unplugs it and re-plugs it?  If so, why?  And shouldn't a dpms off
command at least stick until a hotplug event reports that the display
isn't there?

--Andy

View attachment "dmesg_4.txt" of type "text/plain" (17876 bytes)

View attachment "i915_dpms_trace.patch" of type "text/x-patch" (1826 bytes)