summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/radeon/radeon_device.c
diff options
context:
space:
mode:
authorChris Wilson <chris@chris-wilson.co.uk>2020-01-24 15:56:26 +0300
committerChris Wilson <chris@chris-wilson.co.uk>2020-01-24 20:41:34 +0300
commit7a2c65dd32b1cfa8bae55250dfdfe3d049e2f336 (patch)
tree0e99dbcc57f63cf27809945e3efd0d12af08112f /drivers/gpu/drm/radeon/radeon_device.c
parentc2d4290ba0fff0aad5bc491af18adfbc88bf1c8c (diff)
downloadlinux-7a2c65dd32b1cfa8bae55250dfdfe3d049e2f336.tar.xz
drm: Release filp before global lock
The file is not part of the global drm resource and can be released prior to take the global mutex to drop the open_count (and potentially close) the drm device. As the global mutex is indeed global, not only within the device but across devices, a slow file release mechanism can bottleneck the entire system. However, inside drm_close_helper() there are a number of dev->driver callbacks that take the drm_device as the first parameter... Worryingly some of those callbacks may be (implicitly) depending on the global mutex. v2: Drop the debug message for the open-count, it's included with the drm_file_free() debug message -- and for good measure make that up as reading outside of the mutex. v3: Separate the calling of the filp cleanup outside of drm_global_mutex into a new drm_release_noglobal() hook, so that we can phase the transition. drm/savage relies on the global mutex, and there may be more, so be cautious. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Thomas Hellström (VMware) <thomas_os@shipmail.org> Reviewed-by: Thomas Hellström (VMware) <thomas_os@shipmail.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200124125627.125042-1-chris@chris-wilson.co.uk
Diffstat (limited to 'drivers/gpu/drm/radeon/radeon_device.c')
0 files changed, 0 insertions, 0 deletions