On Fri, Jan 15, 2021 at 02:35:50PM +0100, Christian König wrote:

DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT can't be used when a reservation object lock is help or otherwise we can deadlock with page faults.

Make lockdep complain badly about that.

Signed-off-by: Christian König christian.koenig@amd.com

drivers/gpu/drm/drm_syncobj.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index 6e74e6745eca..6228e9cd089a 100644 --- a/drivers/gpu/drm/drm_syncobj.c +++ b/drivers/gpu/drm/drm_syncobj.c @@ -387,6 +387,20 @@ int drm_syncobj_find_fence(struct drm_file *file_private, if (!syncobj) return -ENOENT;

• if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT &&

•    IS_ENABLED(CONFIG_LOCKDEP)) {
  

• struct dma_resv robj;
  

• /* Waiting for userspace with a reservation lock help is illegal
  

•  * cause that can deadlock with page faults. Make lockdep
  

•  * complain about it early on.
  

Not sure this is a good enough explanation, since anything that holds up userspace can result in a functional deadlock (i.e. user observes no forward progress, gets angry and decides that our gpu driver stack is garbage). It's by far not pagefault.

I'd put something like

/* We must not impede forward progress of userspace in any * way, for otherwise the future fence never materializes * and the application grinds to a full halt. Check for * the worst offenders in terms of locking issues. */

Feel free to bikeshed further.

•  */
  

• dma_resv_init(&robj);
  

• dma_resv_lock(&robj, NULL);
  

• dma_resv_unlock(&robj);
  

• dma_resv_fini(&robj);
  

I think you want to go stronger, since it's not just dma_resv, it's holding anything that might hold up userspace that's illegal here. A lockdep_assert_no_locks_held might be ideal, but a good second-best option would be to grab mmap_lock. Since dma_resv (and a lot of other things, like gup in general) nest within that it would be a substantially stronger asssertion.

Specifically this should also go boom when you do it in places like serving (hmm) page faults, which I think we want. Just locking dma_resv_lock wont go boom like that (since taking the dma_resv_lock from a page fault handler is explicitly allowed, it nests within mmap_lock).

Conceptually I think it's otherwise all fine and at the right spot. -Daniel

• }
• *fence = drm_syncobj_fence_get(syncobj); drm_syncobj_put(syncobj);

-- 2.25.1