All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Matthew Auld <matthew.auld@intel.com>
Cc: Jocelyn Falempe <jfalempe@redhat.com>,
	Sarah Walker <sarah.walker@imgtec.com>,
	Daniel Vetter <daniel.vetter@ffwll.ch>,
	dri-devel@lists.freedesktop.org,
	Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH v2] drm: fix drmm_mutex_init()
Date: Fri, 19 May 2023 11:14:53 +0200	[thread overview]
Message-ID: <20230519111453.1a6aeb95@collabora.com> (raw)
In-Reply-To: <20230519090733.489019-1-matthew.auld@intel.com>

On Fri, 19 May 2023 10:07:33 +0100
Matthew Auld <matthew.auld@intel.com> wrote:

> In mutex_init() lockdep identifies a lock by defining a special static
> key for each lock class. However if we wrap the macro in a function,
> like in drmm_mutex_init(), we end up generating:
> 
> int drmm_mutex_init(struct drm_device *dev, struct mutex *lock)
> {
>       static struct lock_class_key __key;
> 
>       __mutex_init((lock), "lock", &__key);
>       ....
> }
> 
> The static __key here is what lockdep uses to identify the lock class,
> however since this is just a normal function the key here will be
> created once, where all callers then use the same key. In effect the
> mutex->depmap.key will be the same pointer for different
> drmm_mutex_init() callers. This then results in impossible lockdep
> splats since lockdep thinks completely unrelated locks are the same lock
> class.
> 
> To fix this turn drmm_mutex_init() into a macro such that it generates a
> different "static struct lock_class_key __key" for each invocation,
> which looks to be inline with what mutex_init() wants.
> 
> v2:
>   - Revamp the commit message with clearer explanation of the issue.
>   - Rather export __drmm_mutex_release() than static inline.
> 
> Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Reported-by: Sarah Walker <sarah.walker@imgtec.com>
> Fixes: e13f13e039dc ("drm: Add DRM-managed mutex_init()")
> Cc: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
> Cc: Boris Brezillon <boris.brezillon@collabora.com>

Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>

> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Jocelyn Falempe <jfalempe@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> ---
>  drivers/gpu/drm/drm_managed.c | 22 ++--------------------
>  include/drm/drm_managed.h     | 18 +++++++++++++++++-
>  2 files changed, 19 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
> index 4cf214de50c4..c21c3f623033 100644
> --- a/drivers/gpu/drm/drm_managed.c
> +++ b/drivers/gpu/drm/drm_managed.c
> @@ -264,28 +264,10 @@ void drmm_kfree(struct drm_device *dev, void *data)
>  }
>  EXPORT_SYMBOL(drmm_kfree);
>  
> -static void drmm_mutex_release(struct drm_device *dev, void *res)
> +void __drmm_mutex_release(struct drm_device *dev, void *res)
>  {
>  	struct mutex *lock = res;
>  
>  	mutex_destroy(lock);
>  }
> -
> -/**
> - * drmm_mutex_init - &drm_device-managed mutex_init()
> - * @dev: DRM device
> - * @lock: lock to be initialized
> - *
> - * Returns:
> - * 0 on success, or a negative errno code otherwise.
> - *
> - * This is a &drm_device-managed version of mutex_init(). The initialized
> - * lock is automatically destroyed on the final drm_dev_put().
> - */
> -int drmm_mutex_init(struct drm_device *dev, struct mutex *lock)
> -{
> -	mutex_init(lock);
> -
> -	return drmm_add_action_or_reset(dev, drmm_mutex_release, lock);
> -}
> -EXPORT_SYMBOL(drmm_mutex_init);
> +EXPORT_SYMBOL(__drmm_mutex_release);
> diff --git a/include/drm/drm_managed.h b/include/drm/drm_managed.h
> index 359883942612..ad08f834af40 100644
> --- a/include/drm/drm_managed.h
> +++ b/include/drm/drm_managed.h
> @@ -105,6 +105,22 @@ char *drmm_kstrdup(struct drm_device *dev, const char *s, gfp_t gfp);
>  
>  void drmm_kfree(struct drm_device *dev, void *data);
>  
> -int drmm_mutex_init(struct drm_device *dev, struct mutex *lock);
> +void __drmm_mutex_release(struct drm_device *dev, void *res);
> +
> +/**
> + * drmm_mutex_init - &drm_device-managed mutex_init()
> + * @dev: DRM device
> + * @lock: lock to be initialized
> + *
> + * Returns:
> + * 0 on success, or a negative errno code otherwise.
> + *
> + * This is a &drm_device-managed version of mutex_init(). The initialized
> + * lock is automatically destroyed on the final drm_dev_put().
> + */
> +#define drmm_mutex_init(dev, lock) ({					     \
> +	mutex_init(lock);						     \
> +	drmm_add_action_or_reset(dev, __drmm_mutex_release, lock);	     \
> +})									     \
>  
>  #endif


WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Matthew Auld <matthew.auld@intel.com>
Cc: "Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
	"Jocelyn Falempe" <jfalempe@redhat.com>,
	"Sarah Walker" <sarah.walker@imgtec.com>,
	"Daniel Vetter" <daniel.vetter@ffwll.ch>,
	dri-devel@lists.freedesktop.org,
	"Stanislaw Gruszka" <stanislaw.gruszka@linux.intel.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	intel-xe@lists.freedesktop.org
Subject: Re: [PATCH v2] drm: fix drmm_mutex_init()
Date: Fri, 19 May 2023 11:14:53 +0200	[thread overview]
Message-ID: <20230519111453.1a6aeb95@collabora.com> (raw)
In-Reply-To: <20230519090733.489019-1-matthew.auld@intel.com>

On Fri, 19 May 2023 10:07:33 +0100
Matthew Auld <matthew.auld@intel.com> wrote:

> In mutex_init() lockdep identifies a lock by defining a special static
> key for each lock class. However if we wrap the macro in a function,
> like in drmm_mutex_init(), we end up generating:
> 
> int drmm_mutex_init(struct drm_device *dev, struct mutex *lock)
> {
>       static struct lock_class_key __key;
> 
>       __mutex_init((lock), "lock", &__key);
>       ....
> }
> 
> The static __key here is what lockdep uses to identify the lock class,
> however since this is just a normal function the key here will be
> created once, where all callers then use the same key. In effect the
> mutex->depmap.key will be the same pointer for different
> drmm_mutex_init() callers. This then results in impossible lockdep
> splats since lockdep thinks completely unrelated locks are the same lock
> class.
> 
> To fix this turn drmm_mutex_init() into a macro such that it generates a
> different "static struct lock_class_key __key" for each invocation,
> which looks to be inline with what mutex_init() wants.
> 
> v2:
>   - Revamp the commit message with clearer explanation of the issue.
>   - Rather export __drmm_mutex_release() than static inline.
> 
> Reported-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Reported-by: Sarah Walker <sarah.walker@imgtec.com>
> Fixes: e13f13e039dc ("drm: Add DRM-managed mutex_init()")
> Cc: Stanislaw Gruszka <stanislaw.gruszka@linux.intel.com>
> Cc: Boris Brezillon <boris.brezillon@collabora.com>

Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>

> Cc: Thomas Zimmermann <tzimmermann@suse.de>
> Cc: Jocelyn Falempe <jfalempe@redhat.com>
> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Matthew Auld <matthew.auld@intel.com>
> ---
>  drivers/gpu/drm/drm_managed.c | 22 ++--------------------
>  include/drm/drm_managed.h     | 18 +++++++++++++++++-
>  2 files changed, 19 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
> index 4cf214de50c4..c21c3f623033 100644
> --- a/drivers/gpu/drm/drm_managed.c
> +++ b/drivers/gpu/drm/drm_managed.c
> @@ -264,28 +264,10 @@ void drmm_kfree(struct drm_device *dev, void *data)
>  }
>  EXPORT_SYMBOL(drmm_kfree);
>  
> -static void drmm_mutex_release(struct drm_device *dev, void *res)
> +void __drmm_mutex_release(struct drm_device *dev, void *res)
>  {
>  	struct mutex *lock = res;
>  
>  	mutex_destroy(lock);
>  }
> -
> -/**
> - * drmm_mutex_init - &drm_device-managed mutex_init()
> - * @dev: DRM device
> - * @lock: lock to be initialized
> - *
> - * Returns:
> - * 0 on success, or a negative errno code otherwise.
> - *
> - * This is a &drm_device-managed version of mutex_init(). The initialized
> - * lock is automatically destroyed on the final drm_dev_put().
> - */
> -int drmm_mutex_init(struct drm_device *dev, struct mutex *lock)
> -{
> -	mutex_init(lock);
> -
> -	return drmm_add_action_or_reset(dev, drmm_mutex_release, lock);
> -}
> -EXPORT_SYMBOL(drmm_mutex_init);
> +EXPORT_SYMBOL(__drmm_mutex_release);
> diff --git a/include/drm/drm_managed.h b/include/drm/drm_managed.h
> index 359883942612..ad08f834af40 100644
> --- a/include/drm/drm_managed.h
> +++ b/include/drm/drm_managed.h
> @@ -105,6 +105,22 @@ char *drmm_kstrdup(struct drm_device *dev, const char *s, gfp_t gfp);
>  
>  void drmm_kfree(struct drm_device *dev, void *data);
>  
> -int drmm_mutex_init(struct drm_device *dev, struct mutex *lock);
> +void __drmm_mutex_release(struct drm_device *dev, void *res);
> +
> +/**
> + * drmm_mutex_init - &drm_device-managed mutex_init()
> + * @dev: DRM device
> + * @lock: lock to be initialized
> + *
> + * Returns:
> + * 0 on success, or a negative errno code otherwise.
> + *
> + * This is a &drm_device-managed version of mutex_init(). The initialized
> + * lock is automatically destroyed on the final drm_dev_put().
> + */
> +#define drmm_mutex_init(dev, lock) ({					     \
> +	mutex_init(lock);						     \
> +	drmm_add_action_or_reset(dev, __drmm_mutex_release, lock);	     \
> +})									     \
>  
>  #endif


  parent reply	other threads:[~2023-05-19  9:15 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-19  9:07 [Intel-xe] [PATCH v2] drm: fix drmm_mutex_init() Matthew Auld
2023-05-19  9:07 ` Matthew Auld
2023-05-19  9:09 ` [Intel-xe] ✓ CI.Patch_applied: success for " Patchwork
2023-05-19  9:11 ` [Intel-xe] ✓ CI.KUnit: " Patchwork
2023-05-19  9:14 ` Boris Brezillon [this message]
2023-05-19  9:14   ` [PATCH v2] " Boris Brezillon
2023-05-19  9:15 ` [Intel-xe] ✓ CI.Build: success for " Patchwork
2023-05-19  9:40 ` [Intel-xe] [PATCH v2] " Stanislaw Gruszka
2023-05-19  9:40   ` Stanislaw Gruszka
2023-05-19  9:42 ` [Intel-xe] ○ CI.BAT: info for " Patchwork
2023-05-19 15:20 ` [Intel-xe] [PATCH v2] " Lucas De Marchi
2023-05-22  9:43 ` Thomas Zimmermann
2023-05-22  9:43   ` Thomas Zimmermann
2023-05-22  9:50   ` [Intel-xe] " Matthew Auld
2023-05-22  9:50     ` Matthew Auld
2023-05-22 11:12     ` [Intel-xe] " Thomas Zimmermann
2023-05-22 11:12       ` Thomas Zimmermann

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=20230519111453.1a6aeb95@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=jfalempe@redhat.com \
    --cc=matthew.auld@intel.com \
    --cc=sarah.walker@imgtec.com \
    --cc=stanislaw.gruszka@linux.intel.com \
    --cc=tzimmermann@suse.de \
    /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.