• Daniel Vetter's avatar
    dma-fence: prime lockdep annotations · d0b9a9ae
    Daniel Vetter authored
    Two in one go:
    - it is allowed to call dma_fence_wait() while holding a
      dma_resv_lock(). This is fundamental to how eviction works with ttm,
      so required.
    
    - it is allowed to call dma_fence_wait() from memory reclaim contexts,
      specifically from shrinker callbacks (which i915 does), and from mmu
      notifier callbacks (which amdgpu does, and which i915 sometimes also
      does, and probably always should, but that's kinda a debate). Also
      for stuff like HMM we really need to be able to do this, or things
      get real dicey.
    
    Consequence is that any critical path necessary to get to a
    dma_fence_signal for a fence must never a) call dma_resv_lock nor b)
    allocate memory with GFP_KERNEL. Also by implication of
    dma_resv_lock(), no userspace faulting allowed. That's some supremely
    obnoxious limitations, which is why we need to sprinkle the right
    annotations to all relevant paths.
    
    The one big locking context we're leaving out here is mmu notifiers,
    added in
    
    commit 23b68395
    Author: Daniel Vetter <daniel.vetter@ffwll.ch>
    Date:   Mon Aug 26 22:14:21 2019 +0200
    
        mm/mmu_notifiers: add a lockdep map for invalidate_range_start/end
    
    that one covers a lot of other callsites, and it's also allowed to
    wait on dma-fences from mmu notifiers. But there's no ready-made
    functions exposed to prime this, so I've left it out for now.
    
    v2: Also track against mmu notifier context.
    
    v3: kerneldoc to spec the cross-driver contract. Note that currently
    i915 throws in a hard-coded 10s timeout on foreign fences (not sure
    why that was done, but it's there), which is why that rule is worded
    with SHOULD instead of MUST.
    
    Also some of the mmu_notifier/shrinker rules might surprise SoC
    drivers, I haven't fully audited them all. Which is infeasible anyway,
    we'll need to run them with lockdep and dma-fence annotations and see
    what goes boom.
    
    v4: A spelling fix from Mika
    
    v5: #ifdef for CONFIG_MMU_NOTIFIER. Reported by 0day. Unfortunately
    this means lockdep enforcement is slightly inconsistent, it won't spot
    GFP_NOIO and GFP_NOFS allocations in the wrong spot if
    CONFIG_MMU_NOTIFIER is disabled in the kernel config. Oh well.
    
    v5: Note that only drivers/gpu has a reasonable (or at least
    historical) excuse to use dma_fence_wait() from shrinker and mmu
    notifier callbacks. Everyone else should either have a better memory
    manager model, or better hardware. This reflects discussions with
    Jason Gunthorpe.
    
    Cc: Jason Gunthorpe <jgg@mellanox.com>
    Cc: Felix Kuehling <Felix.Kuehling@amd.com>
    Cc: kernel test robot <lkp@intel.com>
    Acked-by: default avatarChristian König <christian.koenig@amd.com>
    Acked-by: default avatarDave Airlie <airlied@redhat.com>
    Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Reviewed-by: Thomas Hellström <thomas.hellstrom@intel.com> (v4)
    Cc: Mika Kuoppala <mika.kuoppala@intel.com>
    Cc: Thomas Hellstrom <thomas.hellstrom@intel.com>
    Cc: linux-media@vger.kernel.org
    Cc: linaro-mm-sig@lists.linaro.org
    Cc: linux-rdma@vger.kernel.org
    Cc: amd-gfx@lists.freedesktop.org
    Cc: intel-gfx@lists.freedesktop.org
    Cc: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
    Cc: Christian König <christian.koenig@amd.com>
    Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20200707201229.472834-3-daniel.vetter@ffwll.ch
    d0b9a9ae
dma-fence.c 26.7 KB