search for: amdgpu_gem_object_open

...pu/amdgpu_drv.c > @@ -1505,19 +1505,13 @@ static struct drm_driver kms_driver = { > .lastclose = amdgpu_driver_lastclose_kms, > .irq_handler = amdgpu_irq_handler, > .ioctls = amdgpu_ioctls_kms, > - .gem_free_object_unlocked = amdgpu_gem_object_free, > - .gem_open_object = amdgpu_gem_object_open, > - .gem_close_object = amdgpu_gem_object_close, > .dumb_create = amdgpu_mode_dumb_create, > .dumb_map_offset = amdgpu_mode_dumb_mmap, > .fops = &amdgpu_driver_kms_fops, > > .prime_handle_to_fd = drm_gem_prime_handle_to_fd, > .prime_fd_to_handle = drm_gem...

....c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -1505,19 +1505,13 @@ static struct drm_driver kms_driver = { .lastclose = amdgpu_driver_lastclose_kms, .irq_handler = amdgpu_irq_handler, .ioctls = amdgpu_ioctls_kms, - .gem_free_object_unlocked = amdgpu_gem_object_free, - .gem_open_object = amdgpu_gem_object_open, - .gem_close_object = amdgpu_gem_object_close, .dumb_create = amdgpu_mode_dumb_create, .dumb_map_offset = amdgpu_mode_dumb_mmap, .fops = &amdgpu_driver_kms_fops, .prime_handle_to_fd = drm_gem_prime_handle_to_fd, .prime_fd_to_handle = drm_gem_prime_fd_to_handle, - .gem_prime_export...

...pu/amdgpu_drv.c > @@ -1468,19 +1468,13 @@ static struct drm_driver kms_driver = { > .lastclose = amdgpu_driver_lastclose_kms, > .irq_handler = amdgpu_irq_handler, > .ioctls = amdgpu_ioctls_kms, > - .gem_free_object_unlocked = amdgpu_gem_object_free, > - .gem_open_object = amdgpu_gem_object_open, > - .gem_close_object = amdgpu_gem_object_close, > .dumb_create = amdgpu_mode_dumb_create, > .dumb_map_offset = amdgpu_mode_dumb_mmap, > .fops = &amdgpu_driver_kms_fops, > > .prime_handle_to_fd = drm_gem_prime_handle_to_fd, > .prime_fd_to_handle = drm_gem...

....c +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c @@ -1468,19 +1468,13 @@ static struct drm_driver kms_driver = { .lastclose = amdgpu_driver_lastclose_kms, .irq_handler = amdgpu_irq_handler, .ioctls = amdgpu_ioctls_kms, - .gem_free_object_unlocked = amdgpu_gem_object_free, - .gem_open_object = amdgpu_gem_object_open, - .gem_close_object = amdgpu_gem_object_close, .dumb_create = amdgpu_mode_dumb_create, .dumb_map_offset = amdgpu_mode_dumb_mmap, .fops = &amdgpu_driver_kms_fops, .prime_handle_to_fd = drm_gem_prime_handle_to_fd, .prime_fd_to_handle = drm_gem_prime_fd_to_handle, - .gem_prime_export...

...468,13 @@ static struct drm_driver kms_driver = { >> ????? .lastclose = amdgpu_driver_lastclose_kms, >> ????? .irq_handler = amdgpu_irq_handler, >> ????? .ioctls = amdgpu_ioctls_kms, >> -??? .gem_free_object_unlocked = amdgpu_gem_object_free, >> -??? .gem_open_object = amdgpu_gem_object_open, >> -??? .gem_close_object = amdgpu_gem_object_close, >> ????? .dumb_create = amdgpu_mode_dumb_create, >> ????? .dumb_map_offset = amdgpu_mode_dumb_mmap, >> ????? .fops = &amdgpu_driver_kms_fops, >> ? ????? .prime_handle_to_fd = drm_gem_prime_handle_to_fd, >>...

...ke 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. >>>> >&g...

...ke 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. >>>> >&g...

...nd 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 a deeper look by individual owners to asses for impact. Those are lima_gem_object_...

...nd 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 a deeper look by individual owners to asses for impact. Those are lima_gem_object_...

..._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 a deeper look by ind...

..._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 a deeper look by ind...

...; 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 a deeper look by individual owners to asses for > i...

...; 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 a deeper look by individual owners to asses for > i...

...t;>> 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...

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Patches #1 to #16 and #18 to #19 convert DRM drivers to GEM object functions, one by one. Each patch moves existing callbacks from struct drm_driver to

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Version 3 of this patchset mostly fixes drm_gem_prime_handle_to_fd and updates i.MX's dcss driver. The driver was missing from earlier versions and

The GEM and PRIME related callbacks in struct drm_driver are deprecated in favor of GEM object functions in struct drm_gem_object_funcs. This patchset converts the remaining drivers to object functions and removes most of the obsolete interfaces. Patches #1 to #18 convert DRM drivers to GEM object functions, one by one. Each patch moves existing callbacks from struct drm_driver to an instance of

...3,6 +33,7 @@ #include <drm/amdgpu_drm.h> #include <drm/drm_debugfs.h> +#include <drm/drm_gem_ttm_helper.h> #include "amdgpu.h" #include "amdgpu_display.h" @@ -220,8 +221,8 @@ static const struct drm_gem_object_funcs amdgpu_gem_object_funcs = { .open = amdgpu_gem_object_open, .close = amdgpu_gem_object_close, .export = amdgpu_gem_prime_export, - .vmap = amdgpu_gem_prime_vmap, - .vunmap = amdgpu_gem_prime_vunmap, + .vmap = drm_gem_ttm_vmap, + .vunmap = drm_gem_ttm_vunmap, }; /* diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h b/drivers/gpu/drm/amd/amdgpu/...

...drm.h> > #include <drm/drm_debugfs.h> > +#include <drm/drm_gem_ttm_helper.h> > > #include "amdgpu.h" > #include "amdgpu_display.h" > @@ -220,8 +221,8 @@ static const struct drm_gem_object_funcs amdgpu_gem_object_funcs = { > .open = amdgpu_gem_object_open, > .close = amdgpu_gem_object_close, > .export = amdgpu_gem_prime_export, > - .vmap = amdgpu_gem_prime_vmap, > - .vunmap = amdgpu_gem_prime_vunmap, > + .vmap = drm_gem_ttm_vmap, > + .vunmap = drm_gem_ttm_vunmap, > }; > > /* > diff --git a/drivers/gpu/drm/a...

DRM's fbdev console uses regular load and store operations to update framebuffer memory. The bochs driver on sparc64 requires the use of I/O-specific load and store operations. We have a workaround, but need a long-term solution to the problem. This patchset changes GEM's vmap/vunmap interfaces to forward pointers of type struct dma_buf_map and updates the generic fbdev emulation to use