Message ID | 20211130121936.586031-1-thomas.hellstrom@linux.intel.com (mailing list archive) |
---|---|
Headers | show |
Series | Attempt to avoid dma-fence-[chain|array] lockdep splats | expand |
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@lists.linaro.org > Cc: dri-devel@lists.freedesktop.org > Cc: Christian König <christian.koenig@amd.com> >