On Wednesday, January 14, 2009 10:56 am Eric Anholt wrote:
> On Wed, 2009-01-14 at 10:48 -0800, Jesse Barnes wrote:
> > >From fc3b2a31f1d2274bcf98929d5f3a5aeaee1baf4d Mon Sep 17 00:00:00 2001
> >
> > From: Jesse Barnes <jbar...@virtuousgeek.org>
> > Date: Wed, 14 Jan 2009 10:38:13 -0800
> > Subject: [PATCH] drm: create mode_config idr lock
> >
> > Create a separate mode_config IDR lock for simplicity. The core DRM
> > config structures (connector, mode, etc. lists) are still protected by
> > the mode_config mutex, but the CRTC IDR (used for the various identifier
> > IDs) is now protected by the mode_config idr_mutex. Simplifies the
> > locking a bit and removes a warning.
>
> So, I don't see any refcounting on these objects. What's keeping them
> alive over the time that the consumer of these APIs uses an object
> returned by drm_mode_object_find()?
In many cases, probably nothing. In most cases though, the mode_config lock
should protect against changes to the various output & mode lists though.
Either way we need to think harder about this. Dave suggested maybe moving
to kobjects here, which would at least keep your ID valid (even if operations
on it failed) until you let it go...
> > @@ -239,16 +239,20 @@ again:
> > static void drm_mode_object_put(struct drm_device *dev,
> > struct drm_mode_object *object)
> > {
> > + mutex_lock(&dev->mode_config.idr_mutex);
> > idr_remove(&dev->mode_config.crtc_idr, object->id);
> > + mutex_unlock(&dev->mode_config.idr_mutex);
> > }
>
> Fix the doc on this function
Yeah, need to do another documentation pass and fix this up (among others).
--
Jesse Barnes, Intel Open Source Technology Center
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
