On Mon, Dec 01, 2014 at 03:04:27AM +0000, Cheng, Yao wrote:
-----Original Message----- From: Beckett, Robert Sent: Saturday, November 29, 2014 0:59 To: Cheng, Yao; intel-gfx@lists.freedesktop.org; dri- devel@lists.freedesktop.org; daniel.vetter@ffwll.ch; Kelley, Sean V; Chehab, John Cc: emil.l.velikov@gmail.com; Jiang, Fei; dh.herrmann@gmail.com; daniel@fooishbar.org Subject: Re: [Intel-gfx] [RFC PATCH v3 1/4] drm/i915: add i915_ved.c to setup bridge for VED
- Threats:
- Due to the restriction in Linux platform device model, user need
+manually
- uninstall ipvr driver before uninstalling i915 module, otherwise
+he might
- run into use-after-free issues after i915 removes the platform device.
Can you go in to more detail on what you consider to be the restriction in the platform device model?
When removing the device via platform_device_unregister, it will call the remove callback of any drivers handling this device (via the bus remove function). It is then up to the driver to ensure no further usage of the device from which it is being removed. This usually involves removing all user input vectors, disabling interrupts involved and flushing/canceling any delayed work. This should prevent any further use of the device by the driver.
The driver's remove function is called in a direct call chain from platform_device_unregister, so by the time it returns, there should be no further chance of accesses.
Bob, thx for your review comments. The symptom is, after "rmmod i915", though drm_drv_release() is also called on the child device "ipvr", I still see the module exist in the system (check it by "lsmod"). This causes issue when I modprobe i915 and ipvr again later. Actually I don't understand why this restriction exists, but accroding to Daniel, grabbing a module refcount for the platform device doesn't work (it would pin the module forever).
Btw this entire story with platform drivers make unload a mess was just a best guess from my side why module unloading doesn't work well or could blow up. I've thought platform drivers registered from modules are inheritely racy, but I'll be very happy to learn that this is a misunderstanding on my side ;-)
Wrt the testcase I'm fairly pragmatic though: Whatever makes it work reliably is good enough for me, even if it's a gross hack (we already need to manually kick fbcon anyway). Cheers, Daniel