[Intel-gfx] [RFC PATCH 0/2] Attempt to avoid dma-fence-[chain|array] lockdep splats

Christian König christian.koenig at amd.com
Tue Nov 30 12:36:23 UTC 2021


Am 30.11.21 um 13:19 schrieb Thomas Hellström:
> Introducing more usage of dma-fence-chain and dma-fence-array in the
> i915 driver we start to hit lockdep splats due to the recursive fence
> locking in the dma-fence-chain and dma-fence-array containers.
> This is a humble suggestion to try to establish a dma-fence locking order
> (patch 1) and to avoid excessive recursive locking in these containers
> (patch 2)

Well completely NAK to this.

This splats are intentional notes that something in the driver code is 
wrong (or we messed up the chain and array containers somehow).

Those two containers are intentionally crafted in a way which allows to 
avoid any dependency between their spinlocks. So as long as you 
correctly use them you should never see a splat.

Please provide the lockdep splat so that we can analyze the problem.

Thanks,
Christian.

>
> Thomas Hellström (2):
>    dma-fence: Avoid establishing a locking order between fence classes
>    dma-fence: Avoid excessive recursive fence locking from
>      enable_signaling() callbacks
>
>   drivers/dma-buf/dma-fence-array.c | 23 +++++++--
>   drivers/dma-buf/dma-fence-chain.c | 12 ++++-
>   drivers/dma-buf/dma-fence.c       | 79 +++++++++++++++++++++----------
>   include/linux/dma-fence.h         |  4 ++
>   4 files changed, 89 insertions(+), 29 deletions(-)
>
> Cc: linaro-mm-sig at lists.linaro.org
> Cc: dri-devel at lists.freedesktop.org
> Cc: Christian König <christian.koenig at amd.com>
>



More information about the Intel-gfx mailing list