Re: [PATCH 9/9 v2] drm/i915: Remove todo and comments about struct_mutex

[Rodrigo Vivi <rodrigo.vivi@intel.com>]

On Thu, Aug 07, 2025 at 02:02:08PM -0300, Luiz Otavio Mello wrote:
> This patch completes the removal of struct_mutex from the driver.
> 
> Remove the related TODO item, as the transition away from struct_mutex
> is now complete.
> 
> Also clean up references to struct_mutex in i915.rst to avoid outdated
> documentation.
> 
> Signed-off-by: Luiz Otavio Mello <luiz.mello@estudante.ufscar.br>
> ---
>  Documentation/gpu/i915.rst |  7 -------
>  Documentation/gpu/todo.rst | 25 -------------------------

misc Maintainers, I also need your ack here to get this through drm-intel-next
please.

I wondered if it would be better to have a split patch to clean up the
i915 doc separate of the drm one, but I believe this single all in one
patch for the doc part is okay...

Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>

>  2 files changed, 32 deletions(-)
> 
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 72932fa31b8d..eba09c3ddce4 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -358,8 +358,6 @@ Locking Guidelines
>  #. All locking rules and interface contracts with cross-driver interfaces
>     (dma-buf, dma_fence) need to be followed.
>  
> -#. No struct_mutex anywhere in the code
> -
>  #. dma_resv will be the outermost lock (when needed) and ww_acquire_ctx
>     is to be hoisted at highest level and passed down within i915_gem_ctx
>     in the call chain
> @@ -367,11 +365,6 @@ Locking Guidelines
>  #. While holding lru/memory manager (buddy, drm_mm, whatever) locks
>     system memory allocations are not allowed
>  
> -	* Enforce this by priming lockdep (with fs_reclaim). If we
> -	  allocate memory while holding these looks we get a rehash
> -	  of the shrinker vs. struct_mutex saga, and that would be
> -	  real bad.
> -
>  #. Do not nest different lru/memory manager locks within each other.
>     Take them in turn to update memory allocations, relying on the object’s
>     dma_resv ww_mutex to serialize against other operations.
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 92db80793bba..b5f58b4274b1 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -173,31 +173,6 @@ Contact: Simona Vetter
>  
>  Level: Intermediate
>  
> -Get rid of dev->struct_mutex from GEM drivers
> ----------------------------------------------
> -
> -``dev->struct_mutex`` is the Big DRM Lock from legacy days and infested
> -everything. Nowadays in modern drivers the only bit where it's mandatory is
> -serializing GEM buffer object destruction. Which unfortunately means drivers
> -have to keep track of that lock and either call ``unreference`` or
> -``unreference_locked`` depending upon context.
> -
> -Core GEM doesn't have a need for ``struct_mutex`` any more since kernel 4.8,
> -and there's a GEM object ``free`` callback for any drivers which are
> -entirely ``struct_mutex`` free.
> -
> -For drivers that need ``struct_mutex`` it should be replaced with a driver-
> -private lock. The tricky part is the BO free functions, since those can't
> -reliably take that lock any more. Instead state needs to be protected with
> -suitable subordinate locks or some cleanup work pushed to a worker thread. For
> -performance-critical drivers it might also be better to go with a more
> -fine-grained per-buffer object and per-context lockings scheme. Currently only
> -the ``msm`` and `i915` drivers use ``struct_mutex``.
> -
> -Contact: Simona Vetter, respective driver maintainers
> -
> -Level: Advanced
> -
>  Move Buffer Object Locking to dma_resv_lock()
>  ---------------------------------------------
>  
> -- 
> 2.50.1
>