lkml.org 
[lkml]   [2011]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [Intel-gfx] [PATCH] drm/i915: Hold struct_mutex during hotplug processing
Date
On Wed, 27 Jul 2011 09:03:31 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Wed, 27 Jul 2011 02:21:24 -0700
> Keith Packard <keithp@keithp.com> wrote:
>
> > On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> >
> > > I'd like to amend my reviewed by and say the lock shouldn't be held
> > > around the call to the drm helper function. It queues some work that
> > > also takes the mode config lock, which will break. So you can drop it
> > > before that... Previously I had only checked our internal driver
> > > callbacks but missed that the lock was held across the helper too.
> >
> > So the work may get executed immediately rather than being run later at
> > some point?
>
> It sure looks that way... but I don't remember any rule about work
> queue items having inter dependencies like this.

Sounds fine; I've stuck a fixup that moves the mutex_unlock:

if (encoder->hot_plug)
encoder->hot_plug(encoder);

+ mutex_unlock(&mode_config->mutex);
+
/* Just fire off a uevent and let userspace tell us what to do */
drm_helper_hpd_irq_event(dev);
-
- mutex_unlock(&mode_config->mutex);
}

--
keith.packard@intel.com
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2011-07-29 00:53    [W:0.048 / U:0.324 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site