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 <chris@xxxxxxxxxxxxxxxxxx>
> Cc: Alex Deucher <alexdeucher@xxxxxxxxx>
> Cc: Christian König <christian.koenig@xxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxx
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel
