linux-kernel - Re: [Patch, RFC] Make struct fb

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.2.00.1009221829590.25874@casper.infradead.org>
Date:	Wed, 22 Sep 2010 18:31:37 +0100 (BST)
From:	James Simmons <jsimmons@...radead.org>
To:	Bruno Prémont <bonbons@...ux-vserver.org>
cc:	Florian Tobias Schandinat <FlorianSchandinat@....de>,
	linux-fbdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	Bernie Thompson <bernie@...gable.com>
Subject: Re: [Patch, RFC] Make struct fb_info ref-counted with kref


> > Bruno Prémont schrieb:
> > > On Tue, 21 Sep 2010 00:28:27 Florian Tobias Schandinat <FlorianSchandinat@....de> wrote:
> > >>> Tracking if/how often framebuffer is opened as such is a separate thing (though
> > >>> all users that have the framebuffer opened hold a reference to fb_info).
> > >> That's what I said. So as long as refcount <= 1 it does not matter whether you 
> > >> just count on open/release or additionally on every framebuffer operation, just 
> > >> that the later produces more noise.
> > > 
> > > Hm, I don't count on every framebuffer operation... in most cases
> > > fb_info is provided as function argument, in which case no further
> > > counting is needed as the caller has a valid reference.
> > > 
> > > With my patch applied refcount for registered but unsed framebuffer was
> > > 2 (once for the driver, once for registered_fb entry) and went up to 3
> > > when userspace opened framebuffer. fbcon's usage only incremented
> > > refcount for very short timeframes when effectively using fb_info.
> > > 
> > > When starting with the FB minor I have to take a new reference.
> > > (though I maybe should check if file's private data is set and use
> > > that reference instead of looking up fb_info by minor as is currently
> > > done)
> > > 
> > > For fbcon all the references are taken by FB minor (I wondered why
> > > fbcon only remembers index into registered_fb aka minor instead of
> > > fb_info itself)
> > 
> > True, I guess fb infrastructure and fbcon both could use a lot of work. At the 
> > moment I am more at fixing my driver but once that's done to an acceptable level 
> > I think I'll give it a try, too.
> 
> This year someone said he/she would look at making it possible to have
> multiple concurrently active consoles on distinct framebuffers.
> Hopefully something is happening on that front (that would certainly
> also include some fbcon cleanup)

That would be me. I have a tree at

http://git.infradead.org/users/jsimmons/linuxconsole-2.6.git

but currently fbcon is broken so I'm tracing down the problem.