1. 26 3月, 2015 1 次提交
  2. 20 3月, 2015 1 次提交
    • M
      drm/i915: Do not leak objects after capturing error state · 0b37a9a9
      Michel Thierry 提交于
      While running kmemleak chasing a different memleak, I saw that the
      capture_error_state function was leaking some objects, for example:
      
      unreferenced object 0xffff8800a9b72148 (size 8192):
        comm "kworker/u16:0", pid 1499, jiffies 4295201243 (age 990.096s)
        hex dump (first 32 bytes):
          00 00 04 00 00 00 00 00 5d f4 ff ff 00 00 00 00  ........].......
          00 30 b0 01 00 00 00 00 37 00 00 00 00 00 00 00  .0......7.......
        backtrace:
          [<ffffffff811e5ae4>] create_object+0x104/0x2c0
          [<ffffffff8178f50a>] kmemleak_alloc+0x7a/0xc0
          [<ffffffff811cde4b>] __kmalloc+0xeb/0x220
          [<ffffffffa038f1d9>] kcalloc.constprop.12+0x2d/0x2f [i915]
          [<ffffffffa0316064>] i915_capture_error_state+0x3f4/0x1660 [i915]
          [<ffffffffa03207df>] i915_handle_error+0x7f/0x660 [i915]
          [<ffffffffa03210f7>] i915_hangcheck_elapsed+0x2e7/0x470 [i915]
          [<ffffffff8108d574>] process_one_work+0x144/0x490
          [<ffffffff8108dfbd>] worker_thread+0x11d/0x530
          [<ffffffff81094079>] kthread+0xc9/0xe0
          [<ffffffff817a2398>] ret_from_fork+0x58/0x90
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      The following objects are allocated in i915_gem_capture_buffers, but not
      released in i915_error_state_free:
        - error->active_bo_count
        - error->pinned_bo
        - error->pinned_bo_count
        - error->active_bo[vm_count] (allocated in i915_gem_capture_vm).
      
      The leaks were introduced by
      commit 95f5301d
      Author: Ben Widawsky <ben@bwidawsk.net>
      Date:   Wed Jul 31 17:00:15 2013 -0700
      
          drm/i915: Update error capture for VMs
      
      v2: Reuse iterator and add culprit commit details (Chris)
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NMichel Thierry <michel.thierry@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      0b37a9a9
  3. 14 2月, 2015 1 次提交
  4. 27 1月, 2015 1 次提交
  5. 18 12月, 2014 3 次提交
  6. 15 12月, 2014 1 次提交
    • T
      drm/i915: Infrastructure for supporting different GGTT views per object · fe14d5f4
      Tvrtko Ursulin 提交于
      Things like reliable GGTT mappings and mirrored 2d-on-3d display will need
      to map objects into the same address space multiple times.
      
      Added a GGTT view concept and linked it with the VMA to distinguish between
      multiple instances per address space.
      
      New objects and GEM functions which do not take this new view as a parameter
      assume the default of zero (I915_GGTT_VIEW_NORMAL) which preserves the
      previous behaviour.
      
      This now means that objects can have multiple VMA entries so the code which
      assumed there will only be one also had to be modified.
      
      Alternative GGTT views are supposed to borrow DMA addresses from obj->pages
      which is DMA mapped on first VMA instantiation and unmapped on the last one
      going away.
      
      v2:
          * Removed per view special casing in i915_gem_ggtt_prepare /
            finish_object in favour of creating and destroying DMA mappings
            on first VMA instantiation and last VMA destruction. (Daniel Vetter)
          * Simplified i915_vma_unbind which does not need to count the GGTT views.
            (Daniel Vetter)
          * Also moved obj->map_and_fenceable reset under the same check.
          * Checkpatch cleanups.
      
      v3:
          * Only retire objects once the last VMA is unbound.
      
      v4:
          * Keep scatter-gather table for alternative views persistent for the
            lifetime of the VMA.
          * Propagate binding errors to callers and handle appropriately.
      
      v5:
          * Explicitly look for normal GGTT view in i915_gem_obj_bound to align
            usage in i915_gem_object_ggtt_unpin. (Michel Thierry)
          * Change to single if statement in i915_gem_obj_to_ggtt. (Michel Thierry)
          * Removed stray semi-colon in i915_gem_object_set_cache_level.
      
      For: VIZ-4544
      Signed-off-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
      [danvet: Drop hunk from i915_gem_shrink since it's just prettification
      but upsets a __must_check warning.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      fe14d5f4
  7. 03 12月, 2014 3 次提交
  8. 20 11月, 2014 1 次提交
  9. 18 11月, 2014 1 次提交
  10. 08 11月, 2014 1 次提交
  11. 04 11月, 2014 1 次提交
  12. 24 9月, 2014 3 次提交
  13. 19 9月, 2014 1 次提交
  14. 03 9月, 2014 5 次提交
  15. 14 8月, 2014 1 次提交
  16. 13 8月, 2014 1 次提交
    • D
      drm/i915: Only track real ppgtt for a context · ae6c4806
      Daniel Vetter 提交于
      There's a bit a confusion since we track the global gtt,
      the aliasing and real ppgtt in the ctx->vm pointer. And not
      all callers really bother to check for the different cases and just
      presume that it points to a real ppgtt.
      
      Now looking closely we don't actually need ->vm to always point at an
      address space - the only place that cares actually has fixup code
      already to decide whether to look at the per-proces or the global
      address space.
      
      So switch to just tracking the ppgtt directly and ditch all the
      extraneous code.
      
      v2: Fixup the ppgtt debugfs file to not oops on a NULL ctx->ppgtt.
      Also drop the early exit - without aliasing ppgtt we want to dump all
      the ppgtts of the contexts if we have full ppgtt.
      
      v3: Actually git add the compile fix.
      Reviewed-by: NMichel Thierry <michel.thierry@intel.com>
      Cc: "Thierry, Michel" <michel.thierry@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      OTC-Jira: VIZ-3724
      [danvet: Resolve conflicts with execlist patches while applying.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ae6c4806
  17. 07 8月, 2014 4 次提交
  18. 23 7月, 2014 2 次提交
    • R
      drm/i915: Fix possible overflow when recording semaphore states. · b4558b46
      Rodrigo Vivi 提交于
      semaphore _sync_seqno, _seqno and _mbox are smaller than number of rings.
      This optimization is to remove the ring itself from the list and the logic to do that
      is at intel_ring_sync_index as below:
      
      /*
       * rcs -> 0 = vcs, 1 = bcs, 2 = vecs, 3 = vcs2;
       * vcs -> 0 = bcs, 1 = vecs, 2 = vcs2, 3 = rcs;
       * bcs -> 0 = vecs, 1 = vcs2. 2 = rcs, 3 = vcs;
       * vecs -> 0 = vcs2, 1 = rcs, 2 = vcs, 3 = bcs;
       * vcs2 -> 0 = rcs, 1 = vcs, 2 = bcs, 3 = vecs;
      */
      
      v2: Skip when from == to (Damien).
      v3: avoid computing idx when from == to (Damien).
          use ring == to instead of ring->id == to->id (Damien).
          use continue instead of return (Rodrigo).
      v4: avoid all unecessary computation (Damien).
          reduce idx to loop scope (Damien).
      
      Cc: Damien Lespiau <damien.lespiau@intel.com>
      Cc: Ben Widawsky <benjamin.widawsky@intel.com>
      Signed-off-by: NRodrigo Vivi <rodrigo.vivi@intel.com>
      Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com>
      Reviewed-by: NBen Widawsky <ben@bwidawsk.net>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      b4558b46
    • B
      drm/i915/error: Check the potential ctx obj's vm · 36362ad3
      Ben Widawsky 提交于
      The bound list is global (all objects which back the VMAs are stored
      here). Recently the BUG() in the offset lookup was demoted to a WARN,
      but the fault actually lies in the caller, here.
      
      This bug has existed since the initial introduction of PPGTT (however,
      it was fixed in unmerged patches to fix up the error state).
      
      Note: The reason for the BUG_ON to WARN_ON demotion was _not_ to
      duct-tape over this bug here but another but triggerable without
      ppgtt. See the commit for details:
      
      commit f25748ea
      Author: Daniel Vetter <daniel.vetter@ffwll.ch>
      Date:   Tue Jun 17 22:34:38 2014 +0200
      
          drm/i915: Don't BUG_ON in i915_gem_obj_offset
      
          A WARN_ON is perfectly fine.
      
          The BUG in here seems to be the cause behind hard-hangs when I cat the
          i915_gem_pageflip debugfs file (which calls this from an irq
          spinlock). But only while running a full igt run after a while. I
          still need to root cause the underlying issue.
      
          I'll also start reject patches which add new BUG_ON but don't come
          with a really good justification for it. The general rule really
          should be to just WARN and hope the driver survives for long enough.
      
          v2: Make the WARN a bit more useful per Chris' suggestion.
      Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: NBen Widawsky <ben@bwidawsk.net>
      [danvet: Clarfy that the WARN_ON (former BUG_ON) in ggtt_offset caught
      more than just this bug fixed in this patch here.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      36362ad3
  19. 08 7月, 2014 2 次提交
  20. 11 6月, 2014 1 次提交
  21. 23 5月, 2014 2 次提交
    • O
      drm/i915: Split the ringbuffers from the rings (2/3) · ee1b1e5e
      Oscar Mateo 提交于
      This refactoring has been performed using the following Coccinelle
      semantic script:
      
          @@
          struct intel_engine_cs r;
          @@
          (
          - (r).obj
          + r.buffer->obj
          |
          - (r).virtual_start
          + r.buffer->virtual_start
          |
          - (r).head
          + r.buffer->head
          |
          - (r).tail
          + r.buffer->tail
          |
          - (r).space
          + r.buffer->space
          |
          - (r).size
          + r.buffer->size
          |
          - (r).effective_size
          + r.buffer->effective_size
          |
          - (r).last_retired_head
          + r.buffer->last_retired_head
          )
      
          @@
          struct intel_engine_cs *r;
          @@
          (
          - (r)->obj
          + r->buffer->obj
          |
          - (r)->virtual_start
          + r->buffer->virtual_start
          |
          - (r)->head
          + r->buffer->head
          |
          - (r)->tail
          + r->buffer->tail
          |
          - (r)->space
          + r->buffer->space
          |
          - (r)->size
          + r->buffer->size
          |
          - (r)->effective_size
          + r->buffer->effective_size
          |
          - (r)->last_retired_head
          + r->buffer->last_retired_head
          )
      
          @@
          expression E;
          @@
          (
          - LP_RING(E)->obj
          + LP_RING(E)->buffer->obj
          |
          - LP_RING(E)->virtual_start
          + LP_RING(E)->buffer->virtual_start
          |
          - LP_RING(E)->head
          + LP_RING(E)->buffer->head
          |
          - LP_RING(E)->tail
          + LP_RING(E)->buffer->tail
          |
          - LP_RING(E)->space
          + LP_RING(E)->buffer->space
          |
          - LP_RING(E)->size
          + LP_RING(E)->buffer->size
          |
          - LP_RING(E)->effective_size
          + LP_RING(E)->buffer->effective_size
          |
          - LP_RING(E)->last_retired_head
          + LP_RING(E)->buffer->last_retired_head
          )
      
      Note: On top of this this patch also removes the now unused ringbuffer
      fields in intel_engine_cs.
      Signed-off-by: NOscar Mateo <oscar.mateo@intel.com>
      [danvet: Add note about fixup patch included here.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      ee1b1e5e
    • O
      drm/i915: s/intel_ring_buffer/intel_engine_cs · a4872ba6
      Oscar Mateo 提交于
      In the upcoming patches we plan to break the correlation between
      engine command streamers (a.k.a. rings) and ringbuffers, so it
      makes sense to refactor the code and make the change obvious.
      
      No functional changes.
      Signed-off-by: NOscar Mateo <oscar.mateo@intel.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      a4872ba6
  22. 17 5月, 2014 1 次提交
    • C
      drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl · 5cc9ed4b
      Chris Wilson 提交于
      By exporting the ability to map user address and inserting PTEs
      representing their backing pages into the GTT, we can exploit UMA in order
      to utilize normal application data as a texture source or even as a
      render target (depending upon the capabilities of the chipset). This has
      a number of uses, with zero-copy downloads to the GPU and efficient
      readback making the intermixed streaming of CPU and GPU operations
      fairly efficient. This ability has many widespread implications from
      faster rendering of client-side software rasterisers (chromium),
      mitigation of stalls due to read back (firefox) and to faster pipelining
      of texture data (such as pixel buffer objects in GL or data blobs in CL).
      
      v2: Compile with CONFIG_MMU_NOTIFIER
      v3: We can sleep while performing invalidate-range, which we can utilise
      to drop our page references prior to the kernel manipulating the vma
      (for either discard or cloning) and so protect normal users.
      v4: Only run the invalidate notifier if the range intercepts the bo.
      v5: Prevent userspace from attempting to GTT mmap non-page aligned buffers
      v6: Recheck after reacquire mutex for lost mmu.
      v7: Fix implicit padding of ioctl struct by rounding to next 64bit boundary.
      v8: Fix rebasing error after forwarding porting the back port.
      v9: Limit the userptr to page aligned entries. We now expect userspace
          to handle all the offset-in-page adjustments itself.
      v10: Prevent vma from being copied across fork to avoid issues with cow.
      v11: Drop vma behaviour changes -- locking is nigh on impossible.
           Use a worker to load user pages to avoid lock inversions.
      v12: Use get_task_mm()/mmput() for correct refcounting of mm.
      v13: Use a worker to release the mmu_notifier to avoid lock inversion
      v14: Decouple mmu_notifier from struct_mutex using a custom mmu_notifer
           with its own locking and tree of objects for each mm/mmu_notifier.
      v15: Prevent overlapping userptr objects, and invalidate all objects
           within the mmu_notifier range
      v16: Fix a typo for iterating over multiple objects in the range and
           rearrange error path to destroy the mmu_notifier locklessly.
           Also close a race between invalidate_range and the get_pages_worker.
      v17: Close a race between get_pages_worker/invalidate_range and fresh
           allocations of the same userptr range - and notice that
           struct_mutex was presumed to be held when during creation it wasn't.
      v18: Sigh. Fix the refactor of st_set_pages() to allocate enough memory
           for the struct sg_table and to clear it before reporting an error.
      v19: Always error out on read-only userptr requests as we don't have the
           hardware infrastructure to support them at the moment.
      v20: Refuse to implement read-only support until we have the required
           infrastructure - but reserve the bit in flags for future use.
      v21: use_mm() is not required for get_user_pages(). It is only meant to
           be used to fix up the kernel thread's current->mm for use with
           copy_user().
      v22: Use sg_alloc_table_from_pages for that chunky feeling
      v23: Export a function for sanity checking dma-buf rather than encode
           userptr details elsewhere, and clean up comments based on
           suggestions by Bradley.
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Cc: "Gong, Zhipeng" <zhipeng.gong@intel.com>
      Cc: Akash Goel <akash.goel@intel.com>
      Cc: "Volkin, Bradley D" <bradley.d.volkin@intel.com>
      Reviewed-by: NTvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
      Reviewed-by: NBrad Volkin <bradley.d.volkin@intel.com>
      [danvet: Frob ioctl allocation to pick the next one - will cause a bit
      of fuss with create2 apparently, but such are the rules.]
      [danvet2: oops, forgot to git add after manual patch application]
      [danvet3: Appease sparse.]
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      5cc9ed4b
  23. 05 5月, 2014 2 次提交