Re: locking inconsistency, when calling fb_ops::fb_release()

[Greg KH <gregkh@suse.de>]

On Mon, Sep 13, 2010 at 09:17:04AM +0200, Guennadi Liakhovetski wrote:
> Hi
> 
> I do not know, whether this can be a problem for any existing driver, but 
> such an inconsistency seems like a bad idea to me anyway. The struct 
> fb_ops::fb_release() method can be called in following ways:
> 
> fbmem.c::fb_release() under the info->lock mutex (file.close("/dev/fbX") 
> 							operation)
> fbcon.c::con2fb_release_oldinfo() under console semaphore
> fbcon.c::fbcon_exit() from
> 	fbcon_deinit() from
> 		vt.c::vc_deallocate() under console semaphore (has 
> 			WARN_CONSOLE_UNLOCKED())
> 		bind_con_driver() under console semaphore
> 	fb_console_exit() under console semaphore
> 
> I.e., it can be either called within an acquire_console_sem() / 
> release_console_sem() block, or within a mutex_lock(&info->lock) / 
> mutex_unlock(&info->lock) block, which looks inconsistent to me.
> 
> The problem, this is causing me is, that I'd like to call the framebuffer 
> notifier chain from my driver's fb_release() method.

Why would you need/want to do this?  If you don't do that, all should be
fine, right?

thanks,

greg k-h