On Mon, May 26, 2014 at 11:07 AM, Daniel Vetter <daniel@xxxxxxxx> wrote: > On Mon, May 26, 2014 at 5:04 PM, Rob Clark <robdclark@xxxxxxxxx> wrote: >> hmm, ok, I had thought this case, thread B would get -EDEADLK because >> lock was held, and not his acquire ctx. If that is not the case, then >> I would propose this: >> >> All places doing things the old way, must grab mode_config.mutex first >> currently. And we use mode_config.mutex to protect >> mode_config.acquire_ctx. So all the lower spots grabbing individual >> crtc mutexes can safely use mode_config.acquire_ctx. >> >> Then the only headache is propagating -EDEADLK up the call stack. If >> we are lucky, the all already propagate -EINTR, etc. > > The output poll work most definitely doesn't propagate -EINTR. Like > I've said, this will be painful. And imo doing this also makes the kms > locking into quite a mess overall. Well, we could hold mode_config.mutex as a traditional mutex around atomic operations. What you loose out would be now _NONBLOCK operations could conceivable call into driver paths without mode_config.mutex held. This was the advantage of converting mode_config.mutex as well. Granted, it is slightly theoretical because until we expose atomic ioctl it would only apply to page_flip (which was not holding mode_config.mutex). And we also want to get rid of mode_config.mutex in these paths too. Otoh, if we want to make locking more fine grained, more use of ww_mutex seems like the best way. And if that means adding a return value to a fxn here/there and propagating errors properly, maybe we should just go ahead and do that. It sounds like the right long term solution anyways. BR, -R > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
