kernel.git/drivers/video/console/fbcon.c, branch linux-2.6.31.y

fbcon: only unbind from console if successfully registered

2009-10-05T16:31:36Z

commit 2ddce3fd0acbdc1be684fb5f919ae3d2e9518aac upstream. Attempting to unload a framebuffer module calls unregister_framebuffer() which in turn gets fbcon to release it. If fbcon has no framebuffers linked to a console, it will also unbind itself from the console driver. However, if fbcon never registered itself as a console driver, the unbind will fail causing the framebuffer device entry to persist. In most cases this failure will result in an oops when attempting to access the now non-existent device. This patch ensures that the fbcon unbind request will succeed even if a bind was never done. It tracks if a successful bind ever occurred & will only attempt to unbind if needed. If there never was a bind, it simply returns with no error. Signed-off-by: Ian Armstrong Cc: Krzysztof Helt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman

fbcon: don't use vc_resize() on initialization

2009-08-07T17:39:56Z

Catalin and kmemleak spotted a leak of a VC screen buffer in vc_allocate() due to the following chain of events: vc_allocate() visual_init(init=1) vc->vc_sw->con_init(init=1) fbcon_init() vc_resize() vc->screen_buf = kmalloc() vc->screen_buf = kmalloc() The common way for the VC drivers is to set the screen dimension parameters manually in the init case and only call vc_resize() for !init - which allocates a screen buffer according to the new dimensions. fbcon instead would do vc_resize() unconditionally and afterwards set the dimensions manually (again) for !init - i.e. completely upside down. The vc_resize() allocated buffer would then get lost by vc_allocate() allocating a fresh one. Use vc_resize() only for actual resizing to close the leak. Set the dimensions manually only in initialization mode to remove the redundant setting in resize mode. The kmemleak trace from Catalin: unreferenced object 0xde158000 (size 12288): comm "Xorg", pid 1439, jiffies 4294961016 hex dump (first 32 bytes): 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 . . . . . . . . 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00 . . . . . . . . backtrace: [] __save_stack_trace+0x17/0x1c [] create_object+0xcd/0x188 [] kmemleak_alloc+0x1b/0x3c [] __kmalloc+0xdb/0xe8 [] vc_do_resize+0x73/0x1e0 [] vc_resize+0x15/0x18 [] fbcon_init+0x1f9/0x2b8 [] visual_init+0x9f/0xdc [] vc_allocate+0x7f/0xfc [] con_open+0x17/0x80 [] tty_open+0x1f7/0x2e4 [] chrdev_open+0x101/0x118 [] __dentry_open+0x105/0x1cc [] nameidata_to_filp+0x2d/0x38 [] do_filp_open+0x2c1/0x54c [] do_sys_open+0x3b/0xb4 Reported-by: Catalin Marinas Signed-off-by: Johannes Weiner Tested-by: Catalin Marinas Cc: Pekka Enberg Cc: Krzysztof Helt Tested-by: Dave Young Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

fbdev: fix info->lock deadlock in fbcon_event_notify()

2009-04-13T22:04:28Z

fb_notifier_call_chain() is called with info->lock held, i.e. in do_fb_ioctl() => FBIOPUT_VSCREENINFO => fb_set_var() and the some notifier callbacks, like fbcon_event_notify(), try to re-acquire info->lock again. Remove the lock/unlock_fb_info() in all the framebuffer notifier callbacks' and be sure to always call fb_notifier_call_chain() with info->lock held. Reported-by: Pavel Roskin Reported-by: Eric Miao Signed-off-by: Andrea Righi Cc: Stefan Richter Cc: Krzysztof Helt Cc: Geert Uytterhoeven Cc: "Rafael J. Wysocki" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

fbmem: fix fb_info->lock and mm->mmap_sem circular locking dependency

2009-04-01T15:59:29Z

Fix a circular locking dependency in the frame buffer console driver pushing down the mutex fb_info->lock. Circular locking dependecies occur calling the blocking fb_notifier_call_chain() with fb_info->lock held. Notifier callbacks can try to acquire mm->mmap_sem, while fb_mmap() acquires the locks in the reverse order mm->mmap_sem => fb_info->lock. Tested-by: Andrey Borzenkov Signed-off-by: Andrea Righi Cc: Geert Uytterhoeven Cc: Krzysztof Helt Cc: Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

fbdev: Kill Atari vblank cursor blinking

2009-01-12T19:56:43Z

Kill the last remaining vblank cursor blinking user Signed-off-by: Geert Uytterhoeven

fbcon: Protect free_irq() by MACH_IS_ATARI check

2008-12-28T19:00:06Z

Add missing check for Atari in free_irq() call, which could cause problems on multi-platform m68k kernels. Reported-by: Brad Boyer Signed-off-by: Geert Uytterhoeven

fbcon: remove broken mac vbl handler

2008-12-28T19:00:06Z

Remove the Mac VBL interrupt code as it doesn't work properly and doesn't bring any benefit when fixed. Also remove unused DEFAULT_CURSOR_BLINK_RATE macro and irqres variable. Signed-off-by: Finn Thain Signed-off-by: Geert Uytterhoeven

fbcon: fix workqueue shutdown

2008-12-10T16:01:53Z

Add a call to cancel_work_sync() in fbcon_exit() to cancel any pending work in the fbcon workqueue. The current implementation of fbcon_exit() sets the fbcon workqueue function info->queue.func to NULL, but does not assure that there is no work pending when it does so. On occasion, depending on system timing, there will still be pending work in the queue when fbcon_exit() is called. This results in a null pointer deference when run_workqueue() tries to call the queue's work function. Fixes errors on shutdown similar to these: Console: switching to colour dummy device 80x25 Unable to handle kernel paging request for data at address 0x00000000 Signed-off-by: Geoff Levand Cc: Krzysztof Helt Cc: Geert Uytterhoeven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

fbdev: fix FB console blanking

2008-12-02T03:55:25Z

The commit aef7db4bd5a3b6068dfa05919a3d685199eed116 fixed the problem with recursive locking in fb blanking code if blank is caused by user setting the /sys/class/graphics/fb*/blank. However this broke the fbcon timeout blanking. If you use a driver that defines ->fb_blank operation and at the same time that driver relies on other driver (e.g. backlight or lcd class) to blank the screen, when the fbcon times out and tries to blank the fb, it will call only fb driver blanker and won't notify the other driver. Thus FB output is disabled, but the screen isn't blanked. Restore fbcon blanking and at the same time apply the proper fix for the above problem: if fbcon_blank is called with FBINFO_FLAG_USEREVENT, we are already called through notification from fb_blank, thus we don't have to blank the fb again. Signed-off-by: Dmitry Baryshkov Cc: Geert Uytterhoeven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

fbcon: don't inline updatescrollmode

2008-10-30T18:38:46Z

Updatescrollmode is marked inline, but it's big and is called only from non-critical codepaths (fbcon_resize, fbcon_switch, fbcon_modechanged). Dropping it saves almost 800 bytes of text size. text data bss dec hex filename 23859 287 8448 32594 7f52 drivers/video/console/fbcon.o.before 23065 287 8448 31800 7c38 drivers/video/console/fbcon.o.after Signed-off-by: Marcin Slusarz Cc: Antonino Daplas Cc: Krzysztof Helt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds