Bug 93251 - i915 is leaking frame buffers
Summary: i915 is leaking frame buffers
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium major
Assignee: Intel GFX Bugs mailing list
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-12-04 17:38 UTC by Tvrtko Ursulin
Modified: 2016-10-10 07:09 UTC (History)
1 user (show)

See Also:
i915 platform: ALL
i915 features: display/Other


Attachments

Description Tvrtko Ursulin 2015-12-04 17:38:00 UTC
(Since appealing to people directly does not seem to work, here is an Bugzilla entry so I've done my bit.)

Definitely when legacy fbcon is not enabled, maybe even leaks extra (non-primary) planes with it.

I ran igt/kms_rotation_crc on a system without legacy fbcon and it crashed. This left any planes it happened to be displaying stuck on screen.

For example kms_rotation_crc has crashed, and kernel still hangs onto the frame buffers:

# cat /sys/kernel/debug/dri/0/i915_gem_framebuffer 
user size: 128 x 128, depth 32, 32 bpp, modifier 0x0, refcount 2, obj ffff8800aa0486c0:  p g       64KiB 40 00 [ 0 0 0 0 ] 0 0 uncached dirty (pinned x 1) (display) (ggtt offset: 0281b000, size: 00010000, type: 0) (pf mappable) (frontbuffer: 0x002)
user size: 1920 x 1080, depth 24, 32 bpp, modifier 0x0, refcount 2, obj ffff8800aa049d40:  p g     8100KiB 41 00 [ 0 0 0 0 ] 0 0 uncached (pinned x 1) (display) (ggtt offset: 0282b000, size: 007e9000, type: 0) (p mappable) (frontbuffer: 0x001)
user size: 1920 x 1080, depth 24, 32 bpp, modifier 0x0, refcount 2, obj ffff8800aa048fc0:  p g     8100KiB 40 00 [ 0 0 0 0 ] 0 0 uncached dirty (pinned x 1) (display) (ggtt offset: 00819000, size: 007e9000, type: 0) (pf mappable) (frontbuffer: 0x004)

One consequence is that should the user start something which puts stuff on the primary plane, say igt/testdisplay, the sprite and cursor belonging to gone kms_rotation_crc will still be on screen. Even hiding the testdisplay output.

And it also makes subsequent CRC tests fail.

When I now start Xorg the desktop is hidden by the left over sprite plane.

Imagine a scenario with multiple displays and multiple planes and Xorg segfaults. Kernel will keep, number of displays times number of planes frame buffers around, pinned in memory, wasting resources.

Not to mention it keeps displaying potentially sensitive data on screen.

Someone will say it is an userspace problem, that something should enumerate all displays and all planes and clear them should a display server crash.  I disagree because that would mean changing all existing userspace programs which currently assume that when they start up nothing is on screen or on the extra planes.
Comment 1 Chris Wilson 2016-10-08 08:26:51 UTC
In theory, fixed (but only because vmgfx depended upon the behaviour, not because it represented an information leak, grr)


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.