[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <yun39hqc95z.fsf@aiko.keithp.com>
Date: Thu, 28 Jul 2011 15:50:00 -0700
From: Keith Packard <keithp@...thp.com>
To: Jesse Barnes <jbarnes@...tuousgeek.org>
Cc: Daniel Vetter <daniel@...ll.ch>, 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 Wed, 27 Jul 2011 09:03:31 -0700, Jesse Barnes <jbarnes@...tuousgeek.org> wrote:
> On Wed, 27 Jul 2011 02:21:24 -0700
> Keith Packard <keithp@...thp.com> wrote:
>
> > On Tue, 26 Jul 2011 12:12:25 -0700, Jesse Barnes <jbarnes@...tuousgeek.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@...el.com
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists