[PATCH] udlfb: handle unplug properly
Bartlomiej Zolnierkiewicz
b.zolnierkie at samsung.com
Mon Oct 8 10:18:36 UTC 2018
On 07/30/2018 12:32 PM, Mikulas Patocka wrote:
> The udlfb driver maintained an open count and cleaned up itself when the
> count reached zero. But the console is also counted in the reference count
> - so, if the user unplugged the device, the open count would not drop to
> zero and the driver stayed loaded with console attached. If the user
> re-plugged the adapter, it would create a device /dev/fb1, show green
> screen and the access to the console would be lost.
>
> The framebuffer subsystem has reference counting on its own - in order to
> fix the unplug bug, we rely the framebuffer reference counting. When the
> user unplugs the adapter, we call unregister_framebuffer unconditionally.
> unregister_framebuffer will unbind the console, wait until all users stop
> using the framebuffer and then call the fb_destroy method. The fb_destroy
> cleans up the USB driver.
>
> This patch makes the following changes:
> * Drop dlfb->kref and rely on implicit framebuffer reference counting
> instead.
> * dlfb_usb_disconnect calls unregister_framebuffer, the rest of driver
> cleanup is done in the function dlfb_ops_destroy. dlfb_ops_destroy will
> be called by the framebuffer subsystem when no processes have the
> framebuffer open or mapped.
> * We don't use workqueue during initialization, but initialize directly
> from dlfb_usb_probe. The workqueue could race with dlfb_usb_disconnect
> and this racing would produce various kinds of memory corruption.
> * We use usb_get_dev and usb_put_dev to make sure that the USB subsystem
> doesn't free the device under us.
>
> Signed-off-by: Mikulas Patocka <mpatocka at redhat.com>
Patch queued for 4.20, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Poland
Samsung Electronics
More information about the dri-devel
mailing list