On Wed, Oct 28, 2020 at 5:45 PM Sam Ravnborg sam@ravnborg.org wrote:
Hi Daniel et al.
On Wed, Oct 28, 2020 at 05:06:00PM +0100, Daniel Vetter wrote:
So ever since syzbot discovered fbcon, we have solid proof that it's full of bugs. And often the solution is to just delete code and remove features, e.g. 50145474f6ef ("fbcon: remove soft scrollback code").
Now the problem is that most modern-ish drivers really only treat fbcon as an dumb kernel console until userspace takes over, and Oops printer for some emergencies. Looking at drm drivers and the basic vesa/efi fbdev drivers shows that only 3 drivers support any kind of acceleration:
- nouveau, seems to be enabled by default
- omapdrm, when a DMM remapper exists using remapper rewriting for y/xpanning
- gma500, but that is getting deleted now for the GTT remapper trick, and the accelerated copyarea never set the FBINFO_HWACCEL_COPYAREA flag, so unused (and could be deleted already I think).
No other driver supportes accelerated fbcon. And fbcon is the only user of this accel code (it's not exposed as uapi through ioctls), which means we could garbage collect fairly enormous amounts of code if we kill this.
Plus because syzbot only runs on virtual hardware, and none of the drivers for that have acceleration, we'd remove a huge gap in testing. And there's no other even remotely comprehensive testing aside from syzbot.
This patch here just disables the acceleration code by always redrawing when scrolling.
So far I follow you - and agree. Acked-by: Sam Ravnborg sam@ravnborg.org
The plan is that once this has been merged for well over a year in released kernels, we can start to go around and delete a lot of code.
Why wait one year? We deleted the scrollback code without any prior warning - which was fine. And acceleration support has less users so there should be no reason to wait.
So unless there are good arguments that I miss then we should just delete the acceleration code outright.
If you grep for FBINFO_HWACCEL and related stuff, we could delete like half the driver code, plus a ton of the related support code in fbcon and fbdev core. It's going to be a lot of work, and I don't want to do that and then have to back it out again. Compared to this the softscrollback removal was nothing. -Daniel