summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorDave Airlie <airlied@redhat.com>2013-01-24 16:12:41 +1000
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2013-02-28 06:59:05 -0800
commit62a3dcc78d04dcd84276eaa7a40dec1066054532 (patch)
treeb4aada491b65d9ea400cffdf69dedd9c0424dd12 /include
parent0bbdba111a75875890290150333c07f2d79b160a (diff)
downloadlinux-3.10-62a3dcc78d04dcd84276eaa7a40dec1066054532.tar.gz
linux-3.10-62a3dcc78d04dcd84276eaa7a40dec1066054532.tar.bz2
linux-3.10-62a3dcc78d04dcd84276eaa7a40dec1066054532.zip
fbcon: don't lose the console font across generic->chip driver switch
commit ae1287865f5361fa138d4d3b1b6277908b54eac9 upstream. 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 Signed-off-by: Dave Airlie <airlied@redhat.com> Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions