mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2025-01-06 13:55:08 +08:00
01ce605a7b
I've checked both implementations (radeon/nouveau) and they both grab the page array from ttm simply by dereferencing it and then wrapping it up with drm_prime_pages_to_sg in the callback and map it with dma_map_sg (in the helper). Only the grabbing of the underlying page array is anything we need to be concerned about, and either those pages are pinned independently, or we're screwed no matter what. And indeed, nouveau/radeon pin the backing storage in their attach/detach functions. Since I've created this patch cma prime support for dma_buf was added. drm_gem_cma_prime_get_sg_table only calls kzalloc and the creates&maps the sg table with dma_get_sgtable. It doesn't touch any gem object state otherwise. So the cma helpers also look safe. The only thing we might claim it does is prevent concurrent mapping of dma_buf attachments. But a) that's not allowed and b) the current code is racy already since it checks whether the sg mapping exists _before_ grabbing the lock. So the dev->struct_mutex locking here does absolutely nothing useful, but only distracts. Remove it. This should also help Maarten's work to eventually pin the backing storage more dynamically by preventing locking inversions around dev->struct_mutex. v2: Add analysis for recently added cma helper prime code. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com> Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@canonical.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com> |
||
---|---|---|
.. | ||
ast | ||
cirrus | ||
exynos | ||
gma500 | ||
i2c | ||
i810 | ||
i915 | ||
mga | ||
mgag200 | ||
nouveau | ||
omapdrm | ||
qxl | ||
r128 | ||
radeon | ||
rcar-du | ||
savage | ||
shmobile | ||
sis | ||
tdfx | ||
tilcdc | ||
ttm | ||
udl | ||
via | ||
vmwgfx | ||
ati_pcigart.c | ||
drm_agpsupport.c | ||
drm_auth.c | ||
drm_buffer.c | ||
drm_bufs.c | ||
drm_cache.c | ||
drm_context.c | ||
drm_crtc_helper.c | ||
drm_crtc.c | ||
drm_debugfs.c | ||
drm_dma.c | ||
drm_dp_helper.c | ||
drm_drv.c | ||
drm_edid_load.c | ||
drm_edid.c | ||
drm_encoder_slave.c | ||
drm_fb_cma_helper.c | ||
drm_fb_helper.c | ||
drm_flip_work.c | ||
drm_fops.c | ||
drm_gem_cma_helper.c | ||
drm_gem.c | ||
drm_global.c | ||
drm_hashtab.c | ||
drm_info.c | ||
drm_ioc32.c | ||
drm_ioctl.c | ||
drm_irq.c | ||
drm_lock.c | ||
drm_memory.c | ||
drm_mm.c | ||
drm_modes.c | ||
drm_pci.c | ||
drm_platform.c | ||
drm_prime.c | ||
drm_proc.c | ||
drm_rect.c | ||
drm_scatter.c | ||
drm_stub.c | ||
drm_sysfs.c | ||
drm_trace_points.c | ||
drm_trace.h | ||
drm_usb.c | ||
drm_vm.c | ||
drm_vma_manager.c | ||
Kconfig | ||
Makefile | ||
README.drm |
************************************************************ * For the very latest on DRI development, please see: * * http://dri.freedesktop.org/ * ************************************************************ The Direct Rendering Manager (drm) is a device-independent kernel-level device driver that provides support for the XFree86 Direct Rendering Infrastructure (DRI). The DRM supports the Direct Rendering Infrastructure (DRI) in four major ways: 1. The DRM provides synchronized access to the graphics hardware via the use of an optimized two-tiered lock. 2. The DRM enforces the DRI security policy for access to the graphics hardware by only allowing authenticated X11 clients access to restricted regions of memory. 3. The DRM provides a generic DMA engine, complete with multiple queues and the ability to detect the need for an OpenGL context switch. 4. The DRM is extensible via the use of small device-specific modules that rely extensively on the API exported by the DRM module. Documentation on the DRI is available from: http://dri.freedesktop.org/wiki/Documentation http://sourceforge.net/project/showfiles.php?group_id=387 http://dri.sourceforge.net/doc/ For specific information about kernel-level support, see: The Direct Rendering Manager, Kernel Support for the Direct Rendering Infrastructure http://dri.sourceforge.net/doc/drm_low_level.html Hardware Locking for the Direct Rendering Infrastructure http://dri.sourceforge.net/doc/hardware_locking_low_level.html A Security Analysis of the Direct Rendering Infrastructure http://dri.sourceforge.net/doc/security_low_level.html