search for: object_name_lock

...diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h index c455ef404ca6..950167ede98a 100644 --- a/include/drm/drm_device.h +++ b/include/drm/drm_device.h @@ -299,22 +299,8 @@ struct drm_device { /** @mode_config: Current mode config */ struct drm_mode_config mode_config; - /** @object_name_lock: GEM information */ - struct mutex object_name_lock; - - /** @object_name_idr: GEM information */ - struct idr object_name_idr; - - /** @vma_offset_manager: GEM information */ - struct drm_vma_offset_manager *vma_offset_manager; - - /** - * @max_segment: - * - * Max size for scatter list segment...

...>funcs->open() callbacks, and also with a common failure mode >> being -ENOMEM from drm_vma_node_allow. >> >> We can make sure none of this can happen by allocating a handle last, >> although with a downside that more of the function now runs under the >> dev->object_name_lock. >> >> Looking into the individual drivers open() hooks, we have >> amdgpu_gem_object_open which seems like it could have a potential >> security >> issue without this change. >> >> A couple drivers like qxl_gem_object_open and vmw_gem_object_open >>...

...>funcs->open() callbacks, and also with a common failure mode >> being -ENOMEM from drm_vma_node_allow. >> >> We can make sure none of this can happen by allocating a handle last, >> although with a downside that more of the function now runs under the >> dev->object_name_lock. >> >> Looking into the individual drivers open() hooks, we have >> amdgpu_gem_object_open which seems like it could have a potential >> security >> issue without this change. >> >> A couple drivers like qxl_gem_object_open and vmw_gem_object_open >>...

...e individual drivers are doing in their obj->funcs->open() callbacks, and also with a common failure mode being -ENOMEM from drm_vma_node_allow. We can make sure none of this can happen by allocating a handle last, although with a downside that more of the function now runs under the dev->object_name_lock. Looking into the individual drivers open() hooks, we have amdgpu_gem_object_open which seems like it could have a potential security issue without this change. A couple drivers like qxl_gem_object_open and vmw_gem_object_open implement no-op hooks so no impact for them. A bunch of other require...

...e individual drivers are doing in their obj->funcs->open() callbacks, and also with a common failure mode being -ENOMEM from drm_vma_node_allow. We can make sure none of this can happen by allocating a handle last, although with a downside that more of the function now runs under the dev->object_name_lock. Looking into the individual drivers open() hooks, we have amdgpu_gem_object_open which seems like it could have a potential security issue without this change. A couple drivers like qxl_gem_object_open and vmw_gem_object_open implement no-op hooks so no impact for them. A bunch of other require...

...with a common failure mode >>>> being -ENOMEM from drm_vma_node_allow. >>>> >>>> We can make sure none of this can happen by allocating a handle last, >>>> although with a downside that more of the function now runs under the >>>> dev->object_name_lock. >>>> >>>> Looking into the individual drivers open() hooks, we have >>>> amdgpu_gem_object_open which seems like it could have a potential >>>> security >>>> issue without this change. >>>> >>>> A couple drivers l...

...with a common failure mode >>>> being -ENOMEM from drm_vma_node_allow. >>>> >>>> We can make sure none of this can happen by allocating a handle last, >>>> although with a downside that more of the function now runs under the >>>> dev->object_name_lock. >>>> >>>> Looking into the individual drivers open() hooks, we have >>>> amdgpu_gem_object_open which seems like it could have a potential >>>> security >>>> issue without this change. >>>> >>>> A couple drivers l...

...callbacks, and also with a common failure mode >>> being -ENOMEM from drm_vma_node_allow. >>> >>> We can make sure none of this can happen by allocating a handle last, >>> although with a downside that more of the function now runs under the >>> dev->object_name_lock. >>> >>> Looking into the individual drivers open() hooks, we have >>> amdgpu_gem_object_open which seems like it could have a potential >>> security >>> issue without this change. >>> >>> A couple drivers like qxl_gem_object_open and...

...g in > their obj->funcs->open() callbacks, and also with a common failure mode > being -ENOMEM from drm_vma_node_allow. > > We can make sure none of this can happen by allocating a handle last, > although with a downside that more of the function now runs under the > dev->object_name_lock. > > Looking into the individual drivers open() hooks, we have > amdgpu_gem_object_open which seems like it could have a potential security > issue without this change. > > A couple drivers like qxl_gem_object_open and vmw_gem_object_open > implement no-op hooks so no impact fo...

...g in > their obj->funcs->open() callbacks, and also with a common failure mode > being -ENOMEM from drm_vma_node_allow. > > We can make sure none of this can happen by allocating a handle last, > although with a downside that more of the function now runs under the > dev->object_name_lock. > > Looking into the individual drivers open() hooks, we have > amdgpu_gem_object_open which seems like it could have a potential security > issue without this change. > > A couple drivers like qxl_gem_object_open and vmw_gem_object_open > implement no-op hooks so no impact fo...

Add max_segment argument to drm_prime_pages_to_sg(). When set pass it through to the __sg_alloc_table_from_pages() call, otherwise use SCATTERLIST_MAX_SEGMENT. Also add max_segment field to drm driver and pass it to drm_prime_pages_to_sg() calls in drivers and helpers. v2: place max_segment in drm driver not gem object. Signed-off-by: Gerd Hoffmann <kraxel at redhat.com> ---