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@chris-wilson.co.uk Cc: Alex Deucher alexdeucher@gmail.com Cc: Christian König christian.koenig@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