| Message ID | 51484307.3040906@canonical.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Mar 19, 2013 at 11:50:47AM +0100, Maarten Lankhorst wrote: > The drmSetMaster call is needed, but the spinning is really just waiting for the workqueue to run. > > bryce's patch never worked, it just caused it to try drmsetinterfaceversion for a few seconds before timing out. That call > was failing because his patch series never tried to obtain drm master. You missed that the series Bryce posted did contain the drmSetMaster() call inside the loop to retry drmSetVersion(). :) Your explanation as to why the delay is required is certainly intriguing. Thanks, -Chris
Hey, Op 19-03-13 22:13, Chris Wilson schreef: > On Tue, Mar 19, 2013 at 11:50:47AM +0100, Maarten Lankhorst wrote: >> The drmSetMaster call is needed, but the spinning is really just waiting for the workqueue to run. >> >> bryce's patch never worked, it just caused it to try drmsetinterfaceversion for a few seconds before timing out. That call >> was failing because his patch series never tried to obtain drm master. > You missed that the series Bryce posted did contain the drmSetMaster() > call inside the loop to retry drmSetVersion(). :) > > Oh I must have missed that. Is the drmSetInterfaceVersion call really needed here? If I look at DRM_IOCTL_GET_UNIQUE, I don't see any requirement of drm master or anything, so it looks to me like for this specific race the drmSetInterfaceVersion call can be skipped entirely without any side effects. This would end up with cleaner code here, and drop the master requirement entirely. Of course there's still a race that needs to be investigated, and is currently not completely understood, I think. ~Maarten
Op 20-03-13 09:40, Maarten Lankhorst schreef: > Hey, > > Op 19-03-13 22:13, Chris Wilson schreef: >> On Tue, Mar 19, 2013 at 11:50:47AM +0100, Maarten Lankhorst wrote: >>> The drmSetMaster call is needed, but the spinning is really just waiting for the workqueue to run. >>> >>> bryce's patch never worked, it just caused it to try drmsetinterfaceversion for a few seconds before timing out. That call >>> was failing because his patch series never tried to obtain drm master. >> You missed that the series Bryce posted did contain the drmSetMaster() >> call inside the loop to retry drmSetVersion(). :) >> >> > Oh I must have missed that. > > Is the drmSetInterfaceVersion call really needed here? If I look at DRM_IOCTL_GET_UNIQUE, > I don't see any requirement of drm master or anything, so it looks to me like for this specific race > the drmSetInterfaceVersion call can be skipped entirely without any side effects. > This would end up with cleaner code here, and drop the master requirement entirely. > > Of course there's still a race that needs to be investigated, and is currently not completely understood, I think. > Or worse, is that drmGetBusId call there even useful? From digging at the kernel it seems it's a per master value. So if a device is hotplugged, it wouldn't be set yet. If someone else holds master, it wouldn't be set either. In fact it would only be ever set from DRIOpenDRMMaster, but that call only happens a lot later, if it even happens at all. It seems to me like opening the fd there should be removed entirely, and the bus id should be retrieved from the udev event instead. I'll try to get something working for this. ~Maarten
On Wed, Mar 20, 2013 at 09:40:04AM +0100, Maarten Lankhorst wrote: > Is the drmSetInterfaceVersion call really needed here? If I look at DRM_IOCTL_GET_UNIQUE, > I don't see any requirement of drm master or anything, so it looks to me like for this specific race > the drmSetInterfaceVersion call can be skipped entirely without any side effects. > This would end up with cleaner code here, and drop the master requirement entirely. Indeed, it does look like drmSetVersion() at that point is overkill. Instead we will hit the race later in the drivers. For the purposes of clearer code, we could happily lose that drmSetVersion(). > Of course there's still a race that needs to be investigated, and is currently not completely understood, I think. We are all in agreement. Ultimately we want to root cause the race, in the meantime we need a fallback to make sure that no desktop is left behind! -Chris
diff --git a/drivers/gpu/drm/drm_fops.c b/drivers/gpu/drm/drm_fops.c index f369429..1d3099f 100644 --- a/drivers/gpu/drm/drm_fops.c +++ b/drivers/gpu/drm/drm_fops.c @@ -339,6 +339,7 @@ static int drm_open_helper(struct inode *inode, struct file *filp, } } mutex_unlock(&dev->struct_mutex); + drm_dropmaster_ioctl(dev, NULL, priv); } else { /* get a reference to the master */ priv->master = drm_master_get(priv->minor->master);