On Thu, Apr 19, 2012 at 5:22 PM, Andy Whitcroft <apw@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
