1. 06 Nov, 2019 2 commits
    • Daniel Vetter's avatar
      drm/nouveau: slowpath for pushbuf ioctl · 03e0d26f
      Daniel Vetter authored
      We can't copy_*_user while holding reservations, that will (soon even
      for nouveau) lead to deadlocks. And it breaks the cross-driver
      contract around dma_resv.
      
      Fix this by adding a slowpath for when we need relocations, and by
      pushing the writeback of the new presumed offsets to the very end.
      
      Aside from "it compiles" entirely untested unfortunately.
      
      Cc: Ilia Mirkin <imirkin@alum.mit.edu>
      Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: nouveau@lists.freedesktop.org
      Reviewed-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
      Acked-by: default avatarDave Airlie <airlied@gmail.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-2-daniel.vetter@ffwll.ch
      03e0d26f
    • Daniel Vetter's avatar
      dma_resv: prime lockdep annotations · b2a8116e
      Daniel Vetter authored
      Full audit of everyone:
      
      - i915, radeon, amdgpu should be clean per their maintainers.
      
      - vram helpers should be fine, they don't do command submission, so
        really no business holding struct_mutex while doing copy_*_user. But
        I haven't checked them all.
      
      - panfrost seems to dma_resv_lock only in panfrost_job_push, which
        looks clean.
      
      - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
        copying from/to userspace happens all in v3d_lookup_bos which is
        outside of the critical section.
      
      - vmwgfx has a bunch of ioctls that do their own copy_*_user:
        - vmw_execbuf_process: First this does some copies in
          vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
          Then comes the usual ttm reserve/validate sequence, then actual
          submission/fencing, then unreserving, and finally some more
          copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
          details, but looks all safe.
        - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
          seen, seems to only create a fence and copy it out.
        - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
          found there.
        Summary: vmwgfx seems to be fine too.
      
      - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
        copying from userspace before even looking up objects through their
        handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
      
      - qxl only has qxl_execbuffer_ioctl, which calls into
        qxl_process_single_command. There's a lovely comment before the
        __copy_from_user_inatomic that the slowpath should be copied from
        i915, but I guess that never happened. Try not to be unlucky and get
        your CS data evicted between when it's written and the kernel tries
        to read it. The only other copy_from_user is for relocs, but those
        are done before qxl_release_reserve_list(), which seems to be the
        only thing reserving buffers (in the ttm/dma_resv sense) in that
        code. So looks safe.
      
      - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
        usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
        everywhere and needs to be fixed up.
      
      v2: Thomas pointed at that vmwgfx calls dma_resv_init while it holds a
      dma_resv lock of a different object already. Christian mentioned that
      ttm core does this too for ghost objects. intel-gfx-ci highlighted
      that i915 has similar issues.
      
      Unfortunately we can't do this in the usual module init functions,
      because kernel threads don't have an ->mm - we have to wait around for
      some user thread to do this.
      
      Solution is to spawn a worker (but only once). It's horrible, but it
      works.
      
      v3: We can allocate mm! (Chris). Horrible worker hack out, clean
      initcall solution in.
      
      v4: Annotate with __init (Rob Herring)
      
      Cc: Rob Herring <robh@kernel.org>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Cc: Christian König <christian.koenig@amd.com>
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Thomas Zimmermann <tzimmermann@suse.de>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com>
      Cc: Eric Anholt <eric@anholt.net>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: Ben Skeggs <bskeggs@redhat.com>
      Cc: "VMware Graphics" <linux-graphics-maintainer@vmware.com>
      Cc: Thomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Tested-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20191104173801.2972-1-daniel.vetter@ffwll.ch
      b2a8116e
  2. 04 Nov, 2019 9 commits
  3. 30 Oct, 2019 5 commits
  4. 29 Oct, 2019 4 commits
  5. 28 Oct, 2019 4 commits
  6. 25 Oct, 2019 15 commits
  7. 24 Oct, 2019 1 commit