On Fri, Jan 24, 2020 at 08:41:48PM +0000, Chris Wilson wrote:
> For largely legacy reasons, a global mutex (drm_global_mutex) is taken
> around open/close of the drm_device, including serialising the filp
> release. For drivers with their own fine grained locking, such global
> coordination is a hindrance, albeit off the common hot paths.
> 
> References: 7a2c65dd32b1 ("drm: Release filp before global lock")
> Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk>
> Cc: Alex Deucher <alexdeuc...@gmail.com>
> Cc: Christian König <christian.koe...@amd.com>

At least on the open side the global mutex also prevents against the
backwards sequence of the ->load callback. Since it's all a huge mess I'm
kinda leaning towards one set of rules for optimized drm_global_mutex
locking, and not a shotgun approach. It's already one of the nastiest
locks we have :-/
-Daniel

> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 94e2fd758e01..9bce9cfa982e 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -1351,7 +1351,7 @@ static const struct file_operations 
> amdgpu_driver_kms_fops = {
>       .owner = THIS_MODULE,
>       .open = drm_open,
>       .flush = amdgpu_flush,
> -     .release = drm_release,
> +     .release = drm_release_noglobal,
>       .unlocked_ioctl = amdgpu_drm_ioctl,
>       .mmap = amdgpu_mmap,
>       .poll = drm_poll,
> -- 
> 2.25.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Reply via email to