From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Kroah-Hartman Subject: Re: [PATCH] fbcon: Disable accelerated scrolling Date: Wed, 28 Oct 2020 17:57:37 +0100 Message-ID: <20201028165737.GB2792004@kroah.com> References: <20201028160600.3752105-1-daniel.vetter@ffwll.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20201028160600.3752105-1-daniel.vetter-/w4YWyX8dFk@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nouveau-bounces-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org Sender: "Nouveau" To: Daniel Vetter Cc: Jiri Slaby , Bartlomiej Zolnierkiewicz , Tetsuo Handa , nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org, "Gustavo A. R. Silva" , DRI Development , Peter Rosin , George Kennedy , Tomi Valkeinen , Ben Skeggs , Daniel Vetter , Nathan Chancellor , Linus Torvalds , Peilin Ye List-Id: nouveau.vger.kernel.org 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. 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. > > Cc: Bartlomiej Zolnierkiewicz > Cc: Greg Kroah-Hartman > Cc: Linus Torvalds > Cc: Ben Skeggs > Cc: nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org > Cc: Tomi Valkeinen > Cc: Daniel Vetter > Cc: Jiri Slaby > Cc: "Gustavo A. R. Silva" > Cc: Tetsuo Handa > Cc: Peilin Ye > Cc: George Kennedy > Cc: Nathan Chancellor > Cc: Peter Rosin > Signed-off-by: Daniel Vetter > --- > drivers/video/fbdev/core/fbcon.c | 38 ++++++-------------------------- > 1 file changed, 7 insertions(+), 31 deletions(-) Nice! But I'm with Sam, delete early :) Reviewed-by: Greg Kroah-Hartman