All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Danilo Krummrich <dakr@redhat.com>
Cc: airlied@gmail.com, daniel@ffwll.ch, tzimmermann@suse.de,
	mripard@kernel.org, corbet@lwn.net, christian.koenig@amd.com,
	bskeggs@redhat.com, Liam.Howlett@oracle.com,
	matthew.brost@intel.com, alexdeucher@gmail.com,
	ogabbay@kernel.org, bagasdotme@gmail.com, willy@infradead.org,
	jason@jlekstrand.net, donald.robson@imgtec.com,
	dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH drm-misc-next v9 01/11] drm/gem: fix lockdep check for dma-resv lock
Date: Tue, 8 Aug 2023 09:21:17 +0200	[thread overview]
Message-ID: <20230808092117.7f7fdef9@collabora.com> (raw)
In-Reply-To: <20230803165238.8798-2-dakr@redhat.com>

On Thu,  3 Aug 2023 18:52:20 +0200
Danilo Krummrich <dakr@redhat.com> wrote:

> When no custom lock is set to protect a GEMs GPUVA list, lockdep checks
> should fall back to the GEM objects dma-resv lock. With the current
> implementation we're setting the lock_dep_map of the GEM objects 'resv'
> pointer (in case no custom lock_dep_map is set yet) on
> drm_gem_private_object_init().
> 
> However, the GEM objects 'resv' pointer might still change after
> drm_gem_private_object_init() is called, e.g. through
> ttm_bo_init_reserved(). This can result in the wrong lock being tracked.
> 
> To fix this, call dma_resv_held() directly from
> drm_gem_gpuva_assert_lock_held() and fall back to the GEMs lock_dep_map
> pointer only if an actual custom lock is set.
> 
> Fixes: e6303f323b1a ("drm: manager to keep track of GPUs VA mappings")
> Signed-off-by: Danilo Krummrich <dakr@redhat.com>

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

but I'm wondering if it wouldn't be a good thing to add a
drm_gem_set_resv() helper, so the core can control drm_gem_object::resv
re-assignments (block them if it's happening after the GEM has been
exposed to the outside world or update auxiliary data if it's happening
before that).

> ---
>  include/drm/drm_gem.h | 15 +++++++++------
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index c0b13c43b459..bc9f6aa2f3fe 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -551,15 +551,17 @@ int drm_gem_evict(struct drm_gem_object *obj);
>   * @lock: the lock used to protect the gpuva list. The locking primitive
>   * must contain a dep_map field.
>   *
> - * Call this if you're not proctecting access to the gpuva list
> - * with the dma-resv lock, otherwise, drm_gem_gpuva_init() takes care
> - * of initializing lock_dep_map for you.
> + * Call this if you're not proctecting access to the gpuva list with the
> + * dma-resv lock, but with a custom lock.
>   */
>  #define drm_gem_gpuva_set_lock(obj, lock) \
> -	if (!(obj)->gpuva.lock_dep_map) \
> +	if (!WARN((obj)->gpuva.lock_dep_map, \
> +		  "GEM GPUVA lock should be set only once.")) \
>  		(obj)->gpuva.lock_dep_map = &(lock)->dep_map
>  #define drm_gem_gpuva_assert_lock_held(obj) \
> -	lockdep_assert(lock_is_held((obj)->gpuva.lock_dep_map))
> +	lockdep_assert((obj)->gpuva.lock_dep_map ? \
> +		       lock_is_held((obj)->gpuva.lock_dep_map) : \
> +		       dma_resv_held((obj)->resv))
>  #else
>  #define drm_gem_gpuva_set_lock(obj, lock) do {} while (0)
>  #define drm_gem_gpuva_assert_lock_held(obj) do {} while (0)
> @@ -573,11 +575,12 @@ int drm_gem_evict(struct drm_gem_object *obj);
>   *
>   * Calling this function is only necessary for drivers intending to support the
>   * &drm_driver_feature DRIVER_GEM_GPUVA.
> + *
> + * See also drm_gem_gpuva_set_lock().
>   */
>  static inline void drm_gem_gpuva_init(struct drm_gem_object *obj)
>  {
>  	INIT_LIST_HEAD(&obj->gpuva.list);
> -	drm_gem_gpuva_set_lock(obj, &obj->resv->lock.base);
>  }
>  
>  /**


WARNING: multiple messages have this Message-ID (diff)
From: Boris Brezillon <boris.brezillon@collabora.com>
To: Danilo Krummrich <dakr@redhat.com>
Cc: matthew.brost@intel.com, willy@infradead.org,
	dri-devel@lists.freedesktop.org, corbet@lwn.net,
	nouveau@lists.freedesktop.org, ogabbay@kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	mripard@kernel.org, bskeggs@redhat.com, tzimmermann@suse.de,
	Liam.Howlett@oracle.com, bagasdotme@gmail.com,
	christian.koenig@amd.com, jason@jlekstrand.net,
	donald.robson@imgtec.com
Subject: Re: [PATCH drm-misc-next v9 01/11] drm/gem: fix lockdep check for dma-resv lock
Date: Tue, 8 Aug 2023 09:21:17 +0200	[thread overview]
Message-ID: <20230808092117.7f7fdef9@collabora.com> (raw)
In-Reply-To: <20230803165238.8798-2-dakr@redhat.com>

On Thu,  3 Aug 2023 18:52:20 +0200
Danilo Krummrich <dakr@redhat.com> wrote:

> When no custom lock is set to protect a GEMs GPUVA list, lockdep checks
> should fall back to the GEM objects dma-resv lock. With the current
> implementation we're setting the lock_dep_map of the GEM objects 'resv'
> pointer (in case no custom lock_dep_map is set yet) on
> drm_gem_private_object_init().
> 
> However, the GEM objects 'resv' pointer might still change after
> drm_gem_private_object_init() is called, e.g. through
> ttm_bo_init_reserved(). This can result in the wrong lock being tracked.
> 
> To fix this, call dma_resv_held() directly from
> drm_gem_gpuva_assert_lock_held() and fall back to the GEMs lock_dep_map
> pointer only if an actual custom lock is set.
> 
> Fixes: e6303f323b1a ("drm: manager to keep track of GPUs VA mappings")
> Signed-off-by: Danilo Krummrich <dakr@redhat.com>

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

but I'm wondering if it wouldn't be a good thing to add a
drm_gem_set_resv() helper, so the core can control drm_gem_object::resv
re-assignments (block them if it's happening after the GEM has been
exposed to the outside world or update auxiliary data if it's happening
before that).

> ---
>  include/drm/drm_gem.h | 15 +++++++++------
>  1 file changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index c0b13c43b459..bc9f6aa2f3fe 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -551,15 +551,17 @@ int drm_gem_evict(struct drm_gem_object *obj);
>   * @lock: the lock used to protect the gpuva list. The locking primitive
>   * must contain a dep_map field.
>   *
> - * Call this if you're not proctecting access to the gpuva list
> - * with the dma-resv lock, otherwise, drm_gem_gpuva_init() takes care
> - * of initializing lock_dep_map for you.
> + * Call this if you're not proctecting access to the gpuva list with the
> + * dma-resv lock, but with a custom lock.
>   */
>  #define drm_gem_gpuva_set_lock(obj, lock) \
> -	if (!(obj)->gpuva.lock_dep_map) \
> +	if (!WARN((obj)->gpuva.lock_dep_map, \
> +		  "GEM GPUVA lock should be set only once.")) \
>  		(obj)->gpuva.lock_dep_map = &(lock)->dep_map
>  #define drm_gem_gpuva_assert_lock_held(obj) \
> -	lockdep_assert(lock_is_held((obj)->gpuva.lock_dep_map))
> +	lockdep_assert((obj)->gpuva.lock_dep_map ? \
> +		       lock_is_held((obj)->gpuva.lock_dep_map) : \
> +		       dma_resv_held((obj)->resv))
>  #else
>  #define drm_gem_gpuva_set_lock(obj, lock) do {} while (0)
>  #define drm_gem_gpuva_assert_lock_held(obj) do {} while (0)
> @@ -573,11 +575,12 @@ int drm_gem_evict(struct drm_gem_object *obj);
>   *
>   * Calling this function is only necessary for drivers intending to support the
>   * &drm_driver_feature DRIVER_GEM_GPUVA.
> + *
> + * See also drm_gem_gpuva_set_lock().
>   */
>  static inline void drm_gem_gpuva_init(struct drm_gem_object *obj)
>  {
>  	INIT_LIST_HEAD(&obj->gpuva.list);
> -	drm_gem_gpuva_set_lock(obj, &obj->resv->lock.base);
>  }
>  
>  /**


  reply	other threads:[~2023-08-08 16:54 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-03 16:52 [PATCH drm-misc-next v9 00/11] Nouveau VM_BIND UAPI & DRM GPUVA Manager (merged) Danilo Krummrich
2023-08-03 16:52 ` Danilo Krummrich
2023-08-03 16:52 ` [Nouveau] " Danilo Krummrich
2023-08-03 16:52 ` [PATCH drm-misc-next v9 01/11] drm/gem: fix lockdep check for dma-resv lock Danilo Krummrich
2023-08-03 16:52   ` Danilo Krummrich
2023-08-03 16:52   ` [Nouveau] " Danilo Krummrich
2023-08-08  7:21   ` Boris Brezillon [this message]
2023-08-08  7:21     ` Boris Brezillon
2023-08-09 22:40     ` Danilo Krummrich
2023-08-09 22:40       ` Danilo Krummrich
2023-08-09 22:40       ` [Nouveau] " Danilo Krummrich
2023-08-03 16:52 ` [PATCH drm-misc-next v9 02/11] drm/nouveau: new VM_BIND uapi interfaces Danilo Krummrich
2023-08-03 16:52   ` Danilo Krummrich
2023-08-03 16:52   ` [Nouveau] " Danilo Krummrich
2023-08-03 19:36   ` Faith Ekstrand
2023-08-03 19:36     ` Faith Ekstrand
2023-08-03 16:52 ` [PATCH drm-misc-next v9 03/11] drm/nouveau: get vmm via nouveau_cli_vmm() Danilo Krummrich
2023-08-03 16:52   ` Danilo Krummrich
2023-08-03 16:52   ` [Nouveau] " Danilo Krummrich
2023-08-03 16:52 ` [PATCH drm-misc-next v9 04/11] drm/nouveau: bo: initialize GEM GPU VA interface Danilo Krummrich
2023-08-03 16:52   ` Danilo Krummrich
2023-08-03 16:52   ` [Nouveau] " Danilo Krummrich
2023-08-03 16:52 ` [PATCH drm-misc-next v9 05/11] drm/nouveau: move usercopy helpers to nouveau_drv.h Danilo Krummrich
2023-08-03 16:52   ` Danilo Krummrich
2023-08-03 16:52   ` [Nouveau] " Danilo Krummrich
2023-08-03 16:52 ` [PATCH drm-misc-next v9 06/11] drm/nouveau: fence: separate fence alloc and emit Danilo Krummrich
2023-08-03 16:52   ` Danilo Krummrich
2023-08-03 16:52   ` [Nouveau] " Danilo Krummrich
2023-08-07 18:07   ` Christian König
2023-08-07 18:07     ` Christian König
2023-08-07 18:07     ` [Nouveau] " Christian König
2023-08-07 18:54     ` Danilo Krummrich
2023-08-07 18:54       ` Danilo Krummrich
2023-08-07 18:54       ` [Nouveau] " Danilo Krummrich
2023-08-08  6:06       ` Christian König
2023-08-08  6:06         ` Christian König
2023-08-08  6:06         ` [Nouveau] " Christian König
2023-08-03 16:52 ` [PATCH drm-misc-next v9 07/11] drm/nouveau: fence: fail to emit when fence context is killed Danilo Krummrich
2023-08-03 16:52   ` Danilo Krummrich
2023-08-03 16:52   ` [Nouveau] " Danilo Krummrich
2023-08-03 16:52 ` [PATCH drm-misc-next v9 08/11] drm/nouveau: chan: provide nouveau_channel_kill() Danilo Krummrich
2023-08-03 16:52   ` Danilo Krummrich
2023-08-03 16:52   ` [Nouveau] " Danilo Krummrich
2023-08-03 16:52 ` [PATCH drm-misc-next v9 09/11] drm/nouveau: nvkm/vmm: implement raw ops to manage uvmm Danilo Krummrich
2023-08-03 16:52   ` Danilo Krummrich
2023-08-03 16:52   ` [Nouveau] " Danilo Krummrich
2023-08-03 16:52 ` [Nouveau] [PATCH drm-misc-next v9 10/11] drm/nouveau: implement new VM_BIND uAPI Danilo Krummrich
2023-08-03 16:52   ` Danilo Krummrich
2023-08-03 16:52   ` Danilo Krummrich
2023-08-03 16:52 ` [PATCH drm-misc-next v9 11/11] drm/nouveau: debugfs: implement DRM GPU VA debugfs Danilo Krummrich
2023-08-03 16:52   ` Danilo Krummrich
2023-08-03 16:52   ` [Nouveau] " Danilo Krummrich
2023-08-03 21:44 ` [PATCH drm-misc-next v9 00/11] Nouveau VM_BIND UAPI & DRM GPUVA Manager (merged) Dave Airlie
2023-08-03 21:44   ` Dave Airlie
2023-08-03 21:44   ` [Nouveau] " Dave Airlie
2023-08-03 21:47   ` Faith Ekstrand
2023-08-03 21:47     ` Faith Ekstrand

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=20230808092117.7f7fdef9@collabora.com \
    --to=boris.brezillon@collabora.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=airlied@gmail.com \
    --cc=alexdeucher@gmail.com \
    --cc=bagasdotme@gmail.com \
    --cc=bskeggs@redhat.com \
    --cc=christian.koenig@amd.com \
    --cc=corbet@lwn.net \
    --cc=dakr@redhat.com \
    --cc=daniel@ffwll.ch \
    --cc=donald.robson@imgtec.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jason@jlekstrand.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew.brost@intel.com \
    --cc=mripard@kernel.org \
    --cc=nouveau@lists.freedesktop.org \
    --cc=ogabbay@kernel.org \
    --cc=tzimmermann@suse.de \
    --cc=willy@infradead.org \
    /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.