All of lore.kernel.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: Rob Clark <robdclark@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [RFCv3 02/14] drm: convert crtc to ww_mutex
Date: Thu, 21 Nov 2013 15:11:46 +0100	[thread overview]
Message-ID: <528E14A2.6010206@canonical.com> (raw)
In-Reply-To: <1384980493-25499-3-git-send-email-robdclark@gmail.com>

op 20-11-13 21:48, Rob Clark schreef:
> At the moment, this doesn't do anything.  But for atomic we will have an
> ww_acquire_ctx associated with the state, to simplify the locking and
> avoid potential deadlock when we cannot control the locking order.
Nack. :-)

Please don't split this out. ww_mutex may be backed by a mutex, but that's an implementation detail you must not rely on.
> ---
>  drivers/gpu/drm/drm_crtc.c           | 20 +++++++++++---------
>  drivers/gpu/drm/i915/intel_display.c | 16 ++++++++--------
>  drivers/gpu/drm/omapdrm/omap_crtc.c  | 10 +++++-----
>  drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  | 12 ++++++++----
>  include/drm/drm_crtc.h               |  3 ++-
>  5 files changed, 34 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 81ac351..55f37db 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -52,7 +52,7 @@ void drm_modeset_lock_all(struct drm_device *dev)
>  	mutex_lock(&dev->mode_config.mutex);
>  
>  	list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
> -		mutex_lock_nest_lock(&crtc->mutex, &dev->mode_config.mutex);
> +		mutex_lock_nest_lock(&crtc->mutex.base, &dev->mode_config.mutex);
>  }
This breaks ww_mutex semantics, for example. What if someone holding a ww_ctx acquires has one mutex, and tries to acquire a second crtc mutex?
If lockdep was smart it would notice that this lock is nested in different locks, but I don't think lockdep is that smart.
>  EXPORT_SYMBOL(drm_modeset_lock_all);
>  
> @@ -65,7 +65,7 @@ void drm_modeset_unlock_all(struct drm_device *dev)
>  	struct drm_crtc *crtc;
>  
>  	list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
> -		mutex_unlock(&crtc->mutex);
> +		ww_mutex_unlock(&crtc->mutex);
>  
>  	mutex_unlock(&dev->mode_config.mutex);
>  }
> @@ -84,7 +84,7 @@ void drm_warn_on_modeset_not_all_locked(struct drm_device *dev)
>  		return;
>  
>  	list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
> -		WARN_ON(!mutex_is_locked(&crtc->mutex));
> +		WARN_ON(!ww_mutex_is_locked(&crtc->mutex));
>  
>  	WARN_ON(!mutex_is_locked(&dev->mode_config.mutex));
>  }
> @@ -613,6 +613,8 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
>  }
>  EXPORT_SYMBOL(drm_framebuffer_remove);
>  
> +static DEFINE_WW_CLASS(crtc_ww_class);
> +
>  /**
>   * drm_crtc_init - Initialise a new CRTC object
>   * @dev: DRM device
> @@ -634,8 +636,8 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
>  	crtc->invert_dimensions = false;
>  
>  	drm_modeset_lock_all(dev);
> -	mutex_init(&crtc->mutex);
> -	mutex_lock_nest_lock(&crtc->mutex, &dev->mode_config.mutex);
> +	ww_mutex_init(&crtc->mutex, &crtc_ww_class);
> +	mutex_lock_nest_lock(&crtc->mutex.base, &dev->mode_config.mutex);
In a later patch you keep this snippet, please make this a trylock instead. It removes
the assumption that ww_mutex has mutex as base.

~Maarten

  reply	other threads:[~2013-11-21 14:11 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-20 20:47 [RFCv3 00/14] Atomic/nuclear modeset/pageflip Rob Clark
2013-11-20 20:48 ` [RFCv3 01/14] drm: add atomic fxns Rob Clark
2013-11-20 20:48 ` [RFCv3 02/14] drm: convert crtc to ww_mutex Rob Clark
2013-11-21 14:11   ` Maarten Lankhorst [this message]
2013-11-21 15:12     ` Rob Clark
2013-11-20 20:48 ` [RFCv3 03/14] drm: add object property type Rob Clark
2013-11-20 20:48 ` [RFCv3 04/14] drm: add DRM_MODE_PROP_DYNAMIC property flag Rob Clark
2013-11-20 20:48 ` [RFCv3 05/14] drm: add DRM_MODE_PROP_SIGNED " Rob Clark
2013-11-20 20:48 ` [RFCv3 06/14] drm: helpers to find mode objects Rob Clark
2013-11-20 20:48 ` [RFCv3 07/14] drm: split propvals out and blob property support Rob Clark
2013-11-20 20:48 ` [RFCv3 08/14] drm: Allow drm_mode_object_find() to look up an object of any type Rob Clark
2013-11-20 20:48 ` [RFCv3 09/14] drm: Refactor object property check code Rob Clark
2013-11-20 20:48 ` [RFCv3 10/14] drm: convert plane to properties/state Rob Clark
2013-11-20 20:48 ` [RFCv3 11/14] drm: convert crtc " Rob Clark
2013-11-21 14:25   ` Maarten Lankhorst
2013-11-20 20:48 ` [RFCv3 12/14] drm: Atomic modeset ioctl Rob Clark
2013-11-22  8:35   ` Inki Dae
2013-11-22 12:34     ` Rob Clark
2013-11-20 20:48 ` [RFCv3 13/14] drm/msm: add atomic support Rob Clark
2013-11-20 20:48 ` [RFCv3 14/14] HACK: drm: allow FB's in drm_mode_object_find Rob Clark

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=528E14A2.6010206@canonical.com \
    --to=maarten.lankhorst@canonical.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=robdclark@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.