[Intel-gfx] [PATCH 04/11] drm/i915: fixup active list locking in object_unbind

Daniel Vetter daniel at ffwll.ch
Mon Feb 1 15:29:42 CET 2010


On Mon, Feb 01, 2010 at 01:22:35PM +0000, Chris Wilson wrote:
> On Mon,  1 Feb 2010 13:59:19 +0100, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> > All other accesses take this spinlock, so do this here, too.
> 
> Can we just kill this spinlock? Please... It only gives a false sense of
> security wrt to /debug/ so why bother with the pretence. Given that we now
> have hang-check, struct_mutex livelocks are a thing of the past and we can
> start correctly taking the struct_mutex for /debug/. If you really want to
> prevent a hang on the mutex, when reading /debug/:

Uups, that's the reason d'etre for this thing. Anyway, locking in drm in
general looks quite fishy. I'm convinced that there are tons of ugly races
between normal batchbuffer execution and any of modesetting, device
init/teardown and suspend/resume. Most of the stuff is nicely papered over
by the abuse of the bkl in drm (at least as long as kmalloc doesn't sleep
...).

I'm tossing around ideas in my brain to fix this mess, but haven't yet
found a decent solution. I want to stroll around in radeon a little bit,
too, first - I hate reinventing a slightly different wheel for every
driver.

>   if (!mutex_trylock (&dev->struct_mutex))
>      eturn -EBUSY;
> -ickle
> 
> P.S. Note that there are move places that actually need to hold this
> spinlock...

Just drop this patch until we can fix drm locking for real.

-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48



More information about the Intel-gfx mailing list