Re: [PATCH v2] drm: make DRM_UNLOCKED ioctls with their own mutex

[Daniel Vetter <daniel@ffwll.ch>]

On Fri, Oct 28, 2011 at 05:43:28PM -0400, Ilija Hadzic wrote:
> drm_getclient, drm_getstats and drm_getmap (with a few minor
> adjustments) do not need global mutex, so fix that and
> make the said ioctls DRM_UNLOCKED. Details:
> 
>   drm_getclient: the only thing that should be protected here
>   is dev->filelist and that is already protected everywhere with
>   dev->struct_mutex.
> 
>   drm_getstats: there is no need for any mutex here because the
>   loop runs through quasi-static (set at load time only)
>   data, and the actual count access is done with atomic_read()
> 
>   drm_getmap already uses dev->struct_mutex to protect
>   dev->maplist, which also used to protect the same structure
>   everywhere else except at three places:
>   * drm_getsarea, which doesn't grab *any* mutex before
>     touching dev->maplist (so no drm_global_mutex doesn't help
>     here either; different issue for a different patch).
>     However, drivers seem to call it only at
>     initialization time so it probably doesn't matter
>   * drm_master_destroy, which is called from drm_master_put,
>     which in turn is protected with dev->struct_mutex
>     everywhere else in drm module, so we are good here too.
>   * drm_getsareactx, which releases the dev->struct_mutex
>     too early, but this patch includes the fix for that.
> 
> v2: * incorporate comments received from Daniel Vetter
>     * include the (long) explanation above to make it clear what
>       we are doing (and why), also at Daniel Vetter's request
>     * tighten up mutex grab/release locations to only
>       encompass real critical sections, rather than some
>       random code around them
> 
> Signed-off-by: Ilija Hadzic <ihadzic@research.bell-labs.com>

Quite a load of stuff to check for this, i.e. next time around maybe split
it up into one patch for each of the three functions changed (and move the
locking bugfix in drm_getsareactx into its own patch).

Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
-- 
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48