From patchwork Thu Mar 25 16:53:30 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chase Douglas X-Patchwork-Id: 48545 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from chlorine.canonical.com (chlorine.canonical.com [91.189.94.204]) by ozlabs.org (Postfix) with ESMTP id 384E6B7CEE for ; Fri, 26 Mar 2010 03:53:42 +1100 (EST) Received: from localhost ([127.0.0.1] helo=chlorine.canonical.com) by chlorine.canonical.com with esmtp (Exim 4.69) (envelope-from ) id 1NuqJM-0008HQ-EO; Thu, 25 Mar 2010 16:53:36 +0000 Received: from adelie.canonical.com ([91.189.90.139]) by chlorine.canonical.com with esmtp (Exim 4.69) (envelope-from ) id 1NuqJK-0008HL-RR for kernel-team@lists.ubuntu.com; Thu, 25 Mar 2010 16:53:34 +0000 Received: from hutte.canonical.com ([91.189.90.181]) by adelie.canonical.com with esmtp (Exim 4.69 #1 (Debian)) id 1NuqJK-0004pm-LQ for ; Thu, 25 Mar 2010 16:53:34 +0000 Received: from cpe-98-31-46-159.woh.res.rr.com ([98.31.46.159] helo=canonical.com) by hutte.canonical.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1NuqJK-0005wG-54 for kernel-team@lists.ubuntu.com; Thu, 25 Mar 2010 16:53:34 +0000 From: Chase Douglas To: kernel-team@lists.ubuntu.com Subject: [PATCH] UBUNTU: SAUCE: Don't register vga16fb framebuffer if other framebuffers are present Date: Thu, 25 Mar 2010 12:53:30 -0400 Message-Id: <1269536010-2488-1-git-send-email-chase.douglas@canonical.com> X-Mailer: git-send-email 1.7.0 X-BeenThere: kernel-team@lists.ubuntu.com X-Mailman-Version: 2.1.9 Precedence: list List-Id: Kernel team discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: kernel-team-bounces@lists.ubuntu.com Errors-To: kernel-team-bounces@lists.ubuntu.com Using the vga16fb framebuffer is not safe when other framebuffers are present. This fixes the case where the vga16fb module is loaded after a better framebuffer is loaded (since vga16fb is by definition the worst-case framebuffer). There does not appear to be any locking around the num_registered_fb, so this is a hack at best. However, in Lucid we build vga16fb as a module. Modules are loaded serially, so this should be ok for Lucid. In M, we will transition to efifb and drop vga16fb, so this is a one time hack. This prevents sudo lshw from corrupting /dev/fb0 by writing to vga16fb through /dev/fb1. BugLink: http://bugs.launchpad.net/bugs/527369 Signed-off-by: Chase Douglas --- drivers/video/vga16fb.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/video/vga16fb.c b/drivers/video/vga16fb.c index efde41d..b1d62ef 100644 --- a/drivers/video/vga16fb.c +++ b/drivers/video/vga16fb.c @@ -1355,7 +1355,7 @@ static int __init vga16fb_probe(struct platform_device *dev) vga16fb_update_fix(info); - if (register_framebuffer(info) < 0) { + if (num_registered_fb > 0 || register_framebuffer(info) < 0) { printk(KERN_ERR "vga16fb: unable to register framebuffer\n"); ret = -EINVAL; goto err_check_var;