drm, fbdev emulation and drm_dev_unplug()
Daniel Vetter
daniel at ffwll.ch
Tue Aug 22 06:16:04 UTC 2017
On Mon, Aug 21, 2017 at 08:53:08PM +0200, Noralf Trønnes wrote:
> Hi,
>
> I'm looking into what happens if fbdev has open file handles when
> drm_dev_unplug() is called. udl is the only user of drm_dev_unplug(),
> but AFAICT it will keel over if unplugged with a /dev/fb handle open
> since fbdev is torn down during drm_driver->unload.
>
> My first attempt was to rely on the drm_device ref counting and tear
> down fbdev in drm_driver->release. This requires that a ref is taken on
> drm_device in &fb_ops.fb_open and dropped in &fb_ops.fb_release.
> The problem is that .fb_release is called under console_lock(), which
> means that unregister_framebuffer() will deadlock (assuming last ref on
> drm_device here). Trying to do trickery with console_lock to get this
> through is bound to be painful, so a straightforward solution is to fork
> of fbdev teardown to a worker.
> Since we are already in drm_driver->release, this won't work.
>
> My next idea is to refcount struct drm_fb_helper, take one ref on
> drm_device and handle the lifetime of fbdev that way. Now it's possible to
> do teardown in a worker and when that's done, drop the ref on drm_device.
> The plan was to make this ref counting optional for drivers.
>
> Is ref counting drm_fb_helper a good/bad idea, or is there another
> solution to this?
I think we'd need to do something similar to what we do with the main drm
devices:
- On unplug we unregister the framebuffer to stop any userspace apps from
opening it and creating new references.
- Every time someone opens the /dev/fb0 node for our emulated fbdev, we
call drm_dev_ref(), and drm_dev_unref() on close.
- We need to sprinkle drm_dev_is_unplugged() checks over all the fbdev
entry points.
- Getting this right for the mmaps will be additional fun, but then we
don't really get that right for drm either ...
- (Aside, those should be rename to _get()/_put() for ocd consistency,
it's the prefererred refcounting naming convention in the kernel).
I have no idea whether fbdev supports this, it was kinda created before
hotplug was a thing :-( But from a quick look we do have fb_open/close
callbacks in fb_ops, so this should be doable.
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the dri-devel
mailing list