diff options
author | Dave Airlie <airlied@redhat.com> | 2013-01-24 16:12:41 +1000 |
---|---|---|
committer | Dave Airlie <airlied@redhat.com> | 2013-02-07 12:37:19 +1000 |
commit | ae1287865f5361fa138d4d3b1b6277908b54eac9 (patch) | |
tree | 22a6b13cd030d5f0fe06ce85bbe8b40a2a519d59 /include/linux/vt_kern.h | |
parent | 2a2483072393b27f4336ab068a1f48ca19ff1c1e (diff) | |
download | linux-ae1287865f5361fa138d4d3b1b6277908b54eac9.tar.gz linux-ae1287865f5361fa138d4d3b1b6277908b54eac9.tar.bz2 linux-ae1287865f5361fa138d4d3b1b6277908b54eac9.zip |
fbcon: don't lose the console font across generic->chip driver switch
If grub2 loads efifb/vesafb, then when systemd starts it can set the console
font on that framebuffer device, however when we then load the native KMS
driver, the first thing it does is tear down the generic framebuffer driver.
The thing is the generic code is doing the right thing, it frees the font
because otherwise it would leak memory. However we can assume that if you
are removing the generic firmware driver (vesa/efi/offb), that a new driver
*should* be loading soon after, so we effectively leak the font.
However the old code left a dangling pointer in vc->vc_font.data and we
can now reuse that dangling pointer to load the font into the new
driver, now that we aren't freeing it.
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=892340
Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: stable@vger.kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
Diffstat (limited to 'include/linux/vt_kern.h')
0 files changed, 0 insertions, 0 deletions