[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20110729102512.GB2697@phenom.ffwll.local>
Date: Fri, 29 Jul 2011 12:25:12 +0200
From: Daniel Vetter <daniel@...ll.ch>
To: Keith Packard <keithp@...thp.com>
Cc: Jesse Barnes <jbarnes@...tuousgeek.org>,
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 Thu, Jul 28, 2011 at 03:50:00PM -0700, Keith Packard wrote:
> 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:
> > > 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.
I've checked the workqueue code and haven't found it to run a work
immediately, it's always queued. Further this problem is very easy to
diagnose: Even without lockdep the scheduler will notice the stuck task
after about 120s and the backtrace should make matters extremely clear. On
the other hand if somebody adds some nice state clobbering in the drm
helper, we have a very hard bug to track down.
Generally modesetting isn't perf critical, so I vote for more locking,
just in case.
-Daniel
--
Daniel Vetter
Mail: daniel@...ll.ch
Mobile: +41 (0)79 365 57 48
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists