On Mon, 28 June 2010 Bernie Thompson <bernie@xxxxxxxxxxxx> wrote: > On Mon, Jun 28, 2010 at 1:33 PM, Bruno Prémont > <bonbons@xxxxxxxxxxxxxxxxx> wrote: > > As our device may be hot-unplugged and framebuffer cannot handle > > this case by itself we need to keep track of usage count so as > > to release fb_info and framebuffer memory only after the last user > > has closed framebuffer. > > > > We need to do the freeing in a scheduled work as fb_release() > > is called with fb_info lock held. > > The udlfb (DisplayLink) framebuffer driver just got a similar fix in > the last few days: > http://git.plugable.com/gitphp/index.php?p=udlfb&a=commit&h=ae0502457e54904b1a9e0d67db6719182824da7c > > The need to schedule work in fb_release() because fbmem.c touches it > after release is especially unfortunate (we had to do the same). > > Anyone have existing thoughts about fixing the release path more centrally? The best option IMHO would be that framebuffer_release() would free up memory when framebuffer is not in use anymore (or last close if FB was in use when framebuffer_release() was called). Something like framebuffer_alloc() <-- set refcount to 1 ... register_framebuffer() <-- inc refcount ... and open() of fb device would inc refcount and close() would decrement it unregister_framebuffer() <-- dec refcount framebuffer_release() <-- dec refcount When after decrementing refcount, refcount reaches zero close() or framebuffer_release() would free the framebuffer, calling fbops fb_release() callback so owner can do cleanup if it has something to do. That way it would be easiest for drivers of removable framebuffers, possibly also useful for kms adding/removing framebuffers for extra monitors. Thanks, Bruno -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
