On Thu, Apr 19, 2012 at 5:22 PM, Andy Whitcroft apw@canonical.com wrote:
We have been carrying a (rather poor) patch for an issue we identified in the DRM driver. This issue is triggered when a DRM device is initialising and userspace attempts to open it, typically in response to the sysfs device added event. Basically we allocate the minor numbers making the device available, and then call the drm load callback. Until this completes the device is really not ready and these early opens typically lead to oopses.
We have been using the following patch to avoid this by marking the minors as in error until the load method has completed. This avoids the early open by simply erroring out the opens with EAGAIN. Obviously we should be delaying the open until the load method complete.
I include the existing patch for completness (it is not really ready for merging) to illustrate the issue. I think it is logical that the wait should simply be delayed until the load has completed. I am proposing to include a wait queue associated with the idr cache for the drm minors which we can use to allow open callers to wait_event_interruptible() on. I'll be putting together a prototype shortly and will follow up with it.
Thoughts?
I've just revisited this, maybe I'm going insane but why does drm_global_mutex not stop this?
drm_get_pci_dev takes drm_global_mutex before calling drm_fill_in_dev and drm_get_minor.
Now the fops should be pointing at stub_open at this point, as we won't have switched to the per device fops yet, and one of the first things drm_stub_open does is take the drm_global_mutex before doing the idr lookup.
So is the problem opening some sysfs or proc file early?
Dave.
-apw
Andy Whitcroft (1): drm -- stop early access to drm devices
drivers/gpu/drm/drm_fops.c | 8 ++++++-- drivers/gpu/drm/drm_pci.c | 4 ++++ drivers/gpu/drm/drm_platform.c | 4 ++++ drivers/gpu/drm/drm_stub.c | 2 +- 4 files changed, 15 insertions(+), 3 deletions(-)
-- 1.7.9.5
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/