public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Maarten Lankhorst <maarten.lankhorst@canonical.com>
To: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: Ben Skeggs <bskeggs@redhat.com>,
	nouveau@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Dave Airlie <airlied@linux.ie>,
	Daniel J Blueman <daniel@quora.org>,
	Peter Hurley <peter@hurleysoftware.com>,
	Arend van Spriel <arend@broadcom.com>
Subject: Re: [PATCH] drm/nouveau: add lockdep annotations
Date: Mon, 04 Feb 2013 22:59:28 +0100	[thread overview]
Message-ID: <51102F40.2090008@canonical.com> (raw)
In-Reply-To: <20130204213041.GA3433@joi.lan>

Op 04-02-13 22:30, Marcin Slusarz schreef:
> 1) Lockdep thinks all nouveau subdevs belong to the same class and can be
> locked in arbitrary order, which is not true (at least in general case).
> Tell it to distinguish subdevs by (o)class type.
Apart from this specific case, is there any other reason why we require being able to nest 2 subdev locks?

Add a NVOBJ_FLAG_CREATE_EXCLUSIVE flag to nouveau_engctx_create and return -EBUSY if there is any existing object. Problem solved, and lockdep is still generic.

> 2) DRM client can be locked under user client lock - tell lockdep to put DRM
> client lock in a separate class.
Can you copy paste a typical lockdep splat for this? Also this should be a separate patch. :-)


> Reported-by: Arend van Spriel <arend@broadcom.com>
> Reported-by: Peter Hurley <peter@hurleysoftware.com>
> Reported-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
> Reported-by: Daniel J Blueman <daniel@quora.org>
> Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
> Cc: stable@vger.kernel.org [3.7, but needs s/const ofuncs/ofuncs/ to build]
> ---
> Lightly tested, only on NV4B and NVC1.
> ---
>  drivers/gpu/drm/nouveau/core/core/subdev.c         | 2 +-
>  drivers/gpu/drm/nouveau/core/include/core/object.h | 7 +++++--
>  drivers/gpu/drm/nouveau/nouveau_drm.c              | 3 +++
>  3 files changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/core/core/subdev.c b/drivers/gpu/drm/nouveau/core/core/subdev.c
> index f74c30a..48f0637 100644
> --- a/drivers/gpu/drm/nouveau/core/core/subdev.c
> +++ b/drivers/gpu/drm/nouveau/core/core/subdev.c
> @@ -99,7 +99,7 @@ nouveau_subdev_create_(struct nouveau_object *parent,
>  	if (ret)
>  		return ret;
>  
> -	mutex_init(&subdev->mutex);
> +	__mutex_init(&subdev->mutex, subname, &oclass->lock_class_key);
>  	subdev->name = subname;
>  
>  	if (parent) {
> diff --git a/drivers/gpu/drm/nouveau/core/include/core/object.h b/drivers/gpu/drm/nouveau/core/include/core/object.h
> index 6a90267..62e68ba 100644
> --- a/drivers/gpu/drm/nouveau/core/include/core/object.h
> +++ b/drivers/gpu/drm/nouveau/core/include/core/object.h
> @@ -50,10 +50,13 @@ int  nouveau_object_fini(struct nouveau_object *, bool suspend);
>  
>  extern struct nouveau_ofuncs nouveau_object_ofuncs;
>  
> +/* Don't allocate dynamically, because lockdep needs lock_class_keys to be in
> + * ".data". */
>  struct nouveau_oclass {
>  	u32 handle;
> -	struct nouveau_ofuncs *ofuncs;
> -	struct nouveau_omthds *omthds;
> +	struct nouveau_ofuncs * const ofuncs;
> +	struct nouveau_omthds * const omthds;
> +	struct lock_class_key lock_class_key;
>  };
>  
>  #define nv_oclass(o)    nv_object(o)->oclass
> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c b/drivers/gpu/drm/nouveau/nouveau_drm.c
> index ef1ad21..bc00587 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_drm.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
> @@ -245,6 +245,8 @@ static int nouveau_drm_probe(struct pci_dev *pdev,
>  	return 0;
>  }
>  
> +static struct lock_class_key drm_client_lock_class_key;
> +
>  static int
>  nouveau_drm_load(struct drm_device *dev, unsigned long flags)
>  {
> @@ -256,6 +258,7 @@ nouveau_drm_load(struct drm_device *dev, unsigned long flags)
>  	ret = nouveau_cli_create(pdev, "DRM", sizeof(*drm), (void**)&drm);
>  	if (ret)
>  		return ret;
> +	lockdep_set_class(&drm->client.mutex, &drm_client_lock_class_key);
>  
>  	dev->dev_private = drm;
>  	drm->dev = dev;


  reply	other threads:[~2013-02-04 21:59 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-03 15:09 3.8-rc6: nouveau lockdep recursive lock acquisition Daniel J Blueman
2013-02-04 21:30 ` [PATCH] drm/nouveau: add lockdep annotations Marcin Slusarz
2013-02-04 21:59   ` Maarten Lankhorst [this message]
2013-02-04 23:24     ` Peter Hurley
2013-02-05 20:52     ` Ben Skeggs
2013-02-07 16:19       ` Maarten Lankhorst

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=51102F40.2090008@canonical.com \
    --to=maarten.lankhorst@canonical.com \
    --cc=airlied@linux.ie \
    --cc=arend@broadcom.com \
    --cc=bskeggs@redhat.com \
    --cc=daniel@quora.org \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcin.slusarz@gmail.com \
    --cc=nouveau@lists.freedesktop.org \
    --cc=peter@hurleysoftware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox