[0/2] drm/i915/gem: dma-buf fixes for migration

Message

Thomas Hellström June 30, 2021, 1:06 p.m. UTC

Our dma-buf code is currently completely broken unless the importer is
dynamic in which case the sg_list caching saves the day. In particular,
the case where another instance of our driver tries to import a dma-buf
exported by our driver ends up in a recursive lock.

Since the recent TTM migration work spec specifies to fix up the dma-buf
code with migration and there's no point in doing so when it's
completely broken, take a first step to make at least the exporter obey
the dma-buf locking rules the dma-buf core enforces for a dynamic exporter:

- Implement and act on pin- and unpin.
- Call move_notify if migrating. (we opt not to migrate while dma-buf_mapped).
- map_dma_buf() is unconditionally called locked.

Add a selftest that ensures that it works with both our own and a fake
dynamic importer.

Also implement migration in the second patch before pinning in pin()
and map_dma_buf().

Note that the importer remains broken for other non-dynamic exporters, but
at least not for the same-driver-separate-instances case.

Regardless whether we want to fix this now with this series, or in an
unspecified future, the selftest may come in handy.

Thomas Hellström (2):
  drm/i915/gem: Make our dma-buf exporter dynamic
  drm/i915/gem: Migrate to system at dma-buf map time

 drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c    |  48 ++++++-
 .../drm/i915/gem/selftests/i915_gem_dmabuf.c  | 118 +++++++++++++++++-
 2 files changed, 162 insertions(+), 4 deletions(-)