On Fri, Apr 20, 2012 at 10:40:35AM +0100, Dave Airlie wrote: > 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? I may be reading things wrong but the initialisation does indeed hold drm_global_mutex, but and back when this first occured we would have been using kernel_lock() which was at least partially reentrant right? Anyhow, I will go back to the reporter and try and get a proper reproduce by, there is no point in fixing something which is something else. -apw _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
