forked from Minki/linux
83f45fc360
The current refcounting scheme is that the fb lookup idr also holds a
reference. This works out nicely bacause thus far we've always
explicitly cleaned up idr entries for framebuffers:
- Userspace fbs get removed in the rmfb ioctl or when the drm file
gets closed.
- Kernel fbs (for fbdev emulation) get cleaned up by the driver code
at module unload time.
But now i915 also reconstructs the bios fbs for a smooth transition.
And that fb is purely transitional and should get removed immmediately
once all crtcs stop using it. Of course if the i915 fbdev code decides
to reuse it as the main fbdev fb then it shouldn't be cleaned up, but
in that case the fbdev code will grab it's own reference.
The problem is now that we also want to register that takeover fb in
the idr, so that userspace can do a smooth transition (animated maybe
even!) itself. But currently we have no one who will clean up the idr
reference once that fb isn't useful any more, and so essentially leak
it.
Fix this by no longer holding a full fb reference for the idr, but
instead just have a weak reference using kref_get_unless_zero. But
that requires us to synchronize and clean up with the idr and fb_lock
in drm_framebuffer_free, so add that. It's a bit ugly that we have to
unconditionally grab the fb_lock, but without that someone might creep
through a race.
This leak was caught by the fb leak check in drm_mode_config_cleanup.
Originally the leak was introduced in
commit
|
||
---|---|---|
.. | ||
armada | ||
ast | ||
bochs | ||
bridge | ||
cirrus | ||
exynos | ||
gma500 | ||
i2c | ||
i810 | ||
i915 | ||
mga | ||
mgag200 | ||
msm | ||
nouveau | ||
omapdrm | ||
panel | ||
qxl | ||
r128 | ||
radeon | ||
rcar-du | ||
savage | ||
shmobile | ||
sis | ||
sti | ||
tdfx | ||
tegra | ||
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_internal.h | ||
drm_crtc.c | ||
drm_debugfs.c | ||
drm_dma.c | ||
drm_dp_helper.c | ||
drm_dp_mst_topology.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_mipi_dsi.c | ||
drm_mm.c | ||
drm_modes.c | ||
drm_modeset_lock.c | ||
drm_of.c | ||
drm_panel.c | ||
drm_pci.c | ||
drm_plane_helper.c | ||
drm_platform.c | ||
drm_prime.c | ||
drm_probe_helper.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