[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