[PATCH 13/19] drm: simplify the locking in the GETCRTC ioctl

Daniel Vetter daniel at ffwll.ch
Tue Mar 28 06:27:31 UTC 2017


On Mon, Mar 27, 2017 at 08:13:17PM -0400, Harry Wentland wrote:
> On Wednesday, March 22, 2017 10:50:52 PM EDT Daniel Vetter wrote:
> > No need to grab both plane and crtc locks at the same time, we can do
> > them one after the other. If userspace races it'll get what it
> > deserves either way.
> > 
> > This removes another user of drm_modeset_lock_crtc. There's only one
> > left.
> > 
> > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> > ---
> >  drivers/gpu/drm/drm_crtc.c | 6 ++++--
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > index 660b4c8715de..df1ff0b8818b 100644
> > --- a/drivers/gpu/drm/drm_crtc.c
> > +++ b/drivers/gpu/drm/drm_crtc.c
> > @@ -406,16 +406,18 @@ int drm_mode_getcrtc(struct drm_device *dev,
> >  	if (!crtc)
> >  		return -ENOENT;
> > 
> > -	drm_modeset_lock_crtc(crtc, crtc->primary);
> >  	crtc_resp->gamma_size = crtc->gamma_size;
> > 
> > +	drm_modeset_lock(&crtc->primary->mutex, NULL);
> >  	if (crtc->primary->state && crtc->primary->state->fb)
> >  		crtc_resp->fb_id = crtc->primary->state->fb->base.id;
> >  	else if (!crtc->primary->state && crtc->primary->fb)
> >  		crtc_resp->fb_id = crtc->primary->fb->base.id;
> >  	else
> >  		crtc_resp->fb_id = 0;
> > +	drm_modeset_unlock(&crtc->primary->mutex);
> > 
> > +	drm_modeset_lock(&crtc->mutex, NULL);
> >  	if (crtc->state) {
> >  		crtc_resp->x = crtc->primary->state->src_x >> 16;
> >  		crtc_resp->y = crtc->primary->state->src_y >> 16;
> 
> What about crtc->primary here? Shouldn't that also be locked with the crtc-
> >primary->mutex or do we treat state differently? Still not 100% on the exact 
> locking semantics.

I misread the code, I thought we only access crtc->state here. I'll
shuffle this around so that crtc->primary->state is properly protected,
that's indeed a bug.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


More information about the dri-devel mailing list