Thread (2 messages) 2 messages, 2 authors, 2009-07-31

Re: [patch] fbcon: don't use vc_resize() on initialization

From: Catalin Marinas <catalin.marinas@arm.com>
Date: 2009-07-31 09:09:53
Also in: lkml

On Thu, 2009-07-30 at 16:11 -0700, Andrew Morton wrote:
On Wed, 29 Jul 2009 19:21:23 +0200
Johannes Weiner [off-list ref] wrote:
quoted
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):
That's a big leak!

What sequence of user actions would cause it to occur?
In my case, I think anything that causes a tty_open() call with a
framebuffer console. I get a leak when logging in on the console and
another when starting the X server.

-- 
Catalin
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help