1. 08 1月, 2018 1 次提交
    • C
      drm/i915: Don't adjust priority on an already signaled fence · c218ee03
      Chris Wilson 提交于
      When we retire a signaled fence, we free the dependency tree. However,
      we skip clearing the list so that if we then try to adjust the priority
      of the signaled fence, we may walk the list of freed dependencies.
      
      [ 3083.156757] ==================================================================
      [ 3083.156806] BUG: KASAN: use-after-free in execlists_schedule+0x199/0x660 [i915]
      [ 3083.156810] Read of size 8 at addr ffff8806bf20f400 by task Xorg/831
      
      [ 3083.156815] CPU: 0 PID: 831 Comm: Xorg Not tainted 4.15.0-rc6-no-psn+ #1
      [ 3083.156817] Hardware name: Notebook                         N24_25BU/N24_25BU, BIOS 5.12 02/17/2017
      [ 3083.156818] Call Trace:
      [ 3083.156823]  dump_stack+0x5c/0x7a
      [ 3083.156827]  print_address_description+0x6b/0x290
      [ 3083.156830]  kasan_report+0x28f/0x380
      [ 3083.156872]  ? execlists_schedule+0x199/0x660 [i915]
      [ 3083.156914]  execlists_schedule+0x199/0x660 [i915]
      [ 3083.156956]  ? intel_crtc_atomic_check+0x146/0x4e0 [i915]
      [ 3083.156997]  ? execlists_submit_request+0xe0/0xe0 [i915]
      [ 3083.157038]  ? i915_vma_misplaced.part.4+0x25/0xb0 [i915]
      [ 3083.157079]  ? __i915_vma_do_pin+0x7c8/0xc80 [i915]
      [ 3083.157121]  ? intel_atomic_state_alloc+0x44/0x60 [i915]
      [ 3083.157130]  ? drm_atomic_helper_page_flip+0x3e/0xb0 [drm_kms_helper]
      [ 3083.157145]  ? drm_mode_page_flip_ioctl+0x7d2/0x850 [drm]
      [ 3083.157159]  ? drm_ioctl_kernel+0xa7/0xf0 [drm]
      [ 3083.157172]  ? drm_ioctl+0x45b/0x560 [drm]
      [ 3083.157211]  i915_gem_object_wait_priority+0x14c/0x2c0 [i915]
      [ 3083.157251]  ? i915_gem_get_aperture_ioctl+0x150/0x150 [i915]
      [ 3083.157290]  ? i915_vma_pin_fence+0x1d8/0x320 [i915]
      [ 3083.157331]  ? intel_pin_and_fence_fb_obj+0x175/0x250 [i915]
      [ 3083.157372]  ? intel_rotation_info_size+0x60/0x60 [i915]
      [ 3083.157413]  ? intel_link_compute_m_n+0x80/0x80 [i915]
      [ 3083.157428]  ? drm_dev_printk+0x1b0/0x1b0 [drm]
      [ 3083.157443]  ? drm_dev_printk+0x1b0/0x1b0 [drm]
      [ 3083.157485]  intel_prepare_plane_fb+0x2f8/0x5a0 [i915]
      [ 3083.157527]  ? intel_crtc_get_vblank_counter+0x80/0x80 [i915]
      [ 3083.157536]  drm_atomic_helper_prepare_planes+0xa0/0x1c0 [drm_kms_helper]
      [ 3083.157587]  intel_atomic_commit+0x12e/0x4e0 [i915]
      [ 3083.157605]  drm_atomic_helper_page_flip+0xa2/0xb0 [drm_kms_helper]
      [ 3083.157621]  drm_mode_page_flip_ioctl+0x7d2/0x850 [drm]
      [ 3083.157638]  ? drm_mode_cursor2_ioctl+0x10/0x10 [drm]
      [ 3083.157652]  ? drm_lease_owner+0x1a/0x30 [drm]
      [ 3083.157668]  ? drm_mode_cursor2_ioctl+0x10/0x10 [drm]
      [ 3083.157681]  drm_ioctl_kernel+0xa7/0xf0 [drm]
      [ 3083.157696]  drm_ioctl+0x45b/0x560 [drm]
      [ 3083.157711]  ? drm_mode_cursor2_ioctl+0x10/0x10 [drm]
      [ 3083.157725]  ? drm_getstats+0x20/0x20 [drm]
      [ 3083.157729]  ? timerqueue_del+0x49/0x80
      [ 3083.157732]  ? __remove_hrtimer+0x62/0xb0
      [ 3083.157735]  ? hrtimer_try_to_cancel+0x173/0x210
      [ 3083.157738]  do_vfs_ioctl+0x13b/0x880
      [ 3083.157741]  ? ioctl_preallocate+0x140/0x140
      [ 3083.157744]  ? _raw_spin_unlock_irq+0xe/0x30
      [ 3083.157746]  ? do_setitimer+0x234/0x370
      [ 3083.157750]  ? SyS_setitimer+0x19e/0x1b0
      [ 3083.157752]  ? SyS_alarm+0x140/0x140
      [ 3083.157755]  ? __rcu_read_unlock+0x66/0x80
      [ 3083.157757]  ? __fget+0xc4/0x100
      [ 3083.157760]  SyS_ioctl+0x74/0x80
      [ 3083.157763]  entry_SYSCALL_64_fastpath+0x1a/0x7d
      [ 3083.157765] RIP: 0033:0x7f6135d0c6a7
      [ 3083.157767] RSP: 002b:00007fff01451888 EFLAGS: 00003246 ORIG_RAX: 0000000000000010
      [ 3083.157769] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f6135d0c6a7
      [ 3083.157771] RDX: 00007fff01451950 RSI: 00000000c01864b0 RDI: 000000000000000c
      [ 3083.157772] RBP: 00007f613076f600 R08: 0000000000000001 R09: 0000000000000000
      [ 3083.157773] R10: 0000000000000060 R11: 0000000000003246 R12: 0000000000000000
      [ 3083.157774] R13: 0000000000000060 R14: 000000000000001b R15: 0000000000000060
      
      [ 3083.157779] Allocated by task 831:
      [ 3083.157783]  kmem_cache_alloc+0xc0/0x200
      [ 3083.157822]  i915_gem_request_await_dma_fence+0x2c4/0x5d0 [i915]
      [ 3083.157861]  i915_gem_request_await_object+0x321/0x370 [i915]
      [ 3083.157900]  i915_gem_do_execbuffer+0x1165/0x19c0 [i915]
      [ 3083.157937]  i915_gem_execbuffer2+0x1ad/0x550 [i915]
      [ 3083.157950]  drm_ioctl_kernel+0xa7/0xf0 [drm]
      [ 3083.157962]  drm_ioctl+0x45b/0x560 [drm]
      [ 3083.157964]  do_vfs_ioctl+0x13b/0x880
      [ 3083.157966]  SyS_ioctl+0x74/0x80
      [ 3083.157968]  entry_SYSCALL_64_fastpath+0x1a/0x7d
      
      [ 3083.157971] Freed by task 831:
      [ 3083.157973]  kmem_cache_free+0x77/0x220
      [ 3083.158012]  i915_gem_request_retire+0x72c/0xa70 [i915]
      [ 3083.158051]  i915_gem_request_alloc+0x1e9/0x8b0 [i915]
      [ 3083.158089]  i915_gem_do_execbuffer+0xa96/0x19c0 [i915]
      [ 3083.158127]  i915_gem_execbuffer2+0x1ad/0x550 [i915]
      [ 3083.158140]  drm_ioctl_kernel+0xa7/0xf0 [drm]
      [ 3083.158153]  drm_ioctl+0x45b/0x560 [drm]
      [ 3083.158155]  do_vfs_ioctl+0x13b/0x880
      [ 3083.158156]  SyS_ioctl+0x74/0x80
      [ 3083.158158]  entry_SYSCALL_64_fastpath+0x1a/0x7d
      
      [ 3083.158162] The buggy address belongs to the object at ffff8806bf20f400
                      which belongs to the cache i915_dependency of size 64
      [ 3083.158166] The buggy address is located 0 bytes inside of
                      64-byte region [ffff8806bf20f400, ffff8806bf20f440)
      [ 3083.158168] The buggy address belongs to the page:
      [ 3083.158171] page:00000000d43decc4 count:1 mapcount:0 mapping:          (null) index:0x0
      [ 3083.158174] flags: 0x17ffe0000000100(slab)
      [ 3083.158179] raw: 017ffe0000000100 0000000000000000 0000000000000000 0000000180200020
      [ 3083.158182] raw: ffffea001afc16c0 0000000500000005 ffff880731b881c0 0000000000000000
      [ 3083.158184] page dumped because: kasan: bad access detected
      
      [ 3083.158187] Memory state around the buggy address:
      [ 3083.158190]  ffff8806bf20f300: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      [ 3083.158192]  ffff8806bf20f380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      [ 3083.158195] >ffff8806bf20f400: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      [ 3083.158196]                    ^
      [ 3083.158199]  ffff8806bf20f480: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      [ 3083.158201]  ffff8806bf20f500: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      [ 3083.158203] ==================================================================
      Reported-by: NAlexandru Chirvasitu <achirvasub@gmail.com>
      Reported-by: NMike Keehan <mike@keehan.net>
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104436
      Fixes: 1f181225 ("drm/i915/execlists: Keep request->priority for its lifetime")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Alexandru Chirvasitu <achirvasub@gmail.com>
      Cc: Michał Winiarski <michal.winiarski@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Tested-by: NAlexandru Chirvasitu <achirvasub@gmail.com>
      Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180106105618.13532-1-chris@chris-wilson.co.uk
      c218ee03
  2. 03 1月, 2018 6 次提交
  3. 23 12月, 2017 1 次提交
    • C
      drm/i915/execlists: Show preemption progress in GEM_TRACE · 193a98dc
      Chris Wilson 提交于
      We already emit a GEM_TRACE for when we start preemption, but we lack
      one to show when the preemption is completed and we return to the regular
      queue. This is to continue the investigation into the mysterious
      
      <0>[  197.854177]   <idle>-0       1..s1 197837017us : execlists_submission_tasklet: rcs0 cs-irq head=0 [0], tail=0 [0]
      <0>[  197.854209] drv_self-6008    2.... 197837390us : reset_common_ring: rcs0 seqno=15515
      <0>[  197.854240] drv_self-6008    2.... 197837415us : reset_common_ring: bcs0 seqno=0
      <0>[  197.854270] drv_self-6008    2.... 197837443us : reset_common_ring: vcs0 seqno=0
      <0>[  197.854300] drv_self-6008    2.... 197837463us : reset_common_ring: vcs1 seqno=0
      <0>[  197.854330] drv_self-6008    2.... 197837482us : reset_common_ring: vecs0 seqno=0
      <0>[  197.854360] ksoftirq-23      2..s. 197838341us : execlists_submission_tasklet: bcs0 in[0]:  ctx=0.1, seqno=1dce7
      <0>[  197.854392]   <idle>-0       1..s1 197838347us : execlists_submission_tasklet: bcs0 cs-irq head=0 [0], tail=0 [0]
      <0>[  197.854423] ksoftirq-23      2..s. 197838354us : execlists_submission_tasklet: vcs0 in[0]:  ctx=0.1, seqno=1d027
      <0>[  197.854456] ksoftirq-23      2.Ns. 197838361us : execlists_submission_tasklet: vcs1 in[0]:  ctx=0.1, seqno=1e738
      <0>[  197.854488] ksoftirq-23      2.Ns. 197838366us : execlists_submission_tasklet: vecs0 in[0]:  ctx=0.1, seqno=235aa
      <0>[  197.854520] ksoftirq-23      2.Ns. 197838376us : execlists_submission_tasklet: rcs0 in[0]:  ctx=0.1, seqno=15518
      <0>[  197.854552]   <idle>-0       1..s1 197853285us : execlists_submission_tasklet: rcs0 cs-irq head=0 [0], tail=7 [7]
      <0>[  197.854584]   <idle>-0       1..s1 197853285us : execlists_submission_tasklet: rcs0 csb[1]: status=0x00000018:0x00000000
      <0>[  197.854616]   <idle>-0       1..s1 197853286us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171222132742.4272-1-chris@chris-wilson.co.ukReviewed-by: NTvrtko Ursulin <tvrtko.ursulin@intel.com>
      193a98dc
  4. 20 12月, 2017 2 次提交
  5. 08 12月, 2017 1 次提交
  6. 29 11月, 2017 1 次提交
  7. 22 11月, 2017 2 次提交
  8. 21 11月, 2017 2 次提交
  9. 20 11月, 2017 3 次提交
  10. 16 11月, 2017 2 次提交
  11. 11 11月, 2017 3 次提交
  12. 10 11月, 2017 1 次提交
    • C
      drm/i915: Use trace_printk to provide a death rattle for GEM · bccd3b83
      Chris Wilson 提交于
      Trying to enable printk debugging for GEM is fraught with the issue of
      spam; interactions with HW are very frequent and often boring. However,
      one instance where they are not so boring is just before a BUG; here
      ftrace provides a facility to dump its ringbuffer on an oops. So for CI
      let's enable trace_printk() to capture the last exchanges with HW as a
      death rattle.
      
      For example,
      [   79.234110] ------------[ cut here ]------------
      [   79.234137] kernel BUG at drivers/gpu/drm/i915/intel_lrc.c:907!
      [   79.234145] invalid opcode: 0000 [#1] SMP
      [   79.234153] Dumping ftrace buffer:
      [   79.234158] ---------------------------------
      ...
      [   79.314044] gem_conc-1059    1..s1 79203443us : intel_lrc_irq_handler: bcs0 out[0]: ctx=5.2, seqno=145
      [   79.314089] gem_conc-1059    1..s. 79220800us : intel_lrc_irq_handler: bcs0 csb[1/1]: status=0x00000018:0x00000005
      [   79.314133] gem_conc-1059    1..s. 79220803us : intel_lrc_irq_handler: bcs0 out[0]: ctx=5.1, seqno=145
      [   79.314177] gem_conc-1062    2..s1 79230458us : intel_lrc_irq_handler: bcs0 in[0]:  ctx=8.1, seqno=146
      [   79.314220] gem_conc-1062    2..s1 79230515us : intel_lrc_irq_handler: bcs0 in[0]:  ctx=8.2, seqno=147
      [   79.314265] gem_conc-1059    1..s1 79230951us : intel_lrc_irq_handler: bcs0 csb[2/3]: status=0x00000012:0x00000008
      [   79.314309] gem_conc-1059    1..s1 79230954us : intel_lrc_irq_handler: bcs0 out[0]: ctx=8.2, seqno=147
      [   79.314353] gem_conc-1059    1..s1 79230954us : intel_lrc_irq_handler: bcs0 csb[3/3]: status=0x00008002:0x00000008
      [   79.314396] gem_conc-1059    1..s1 79230955us : intel_lrc_irq_handler: bcs0 out[0]: ctx=8.1, seqno=147
      [   79.314402] ---------------------------------
      
      v2: Tweak the formatting to be more consistent between in/out.
      v3: do {} while (0) stub macro protection
      Suggested-by: NMichał Winiarski <michal.winiarski@intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171109143019.16568-1-chris@chris-wilson.co.uk
      bccd3b83
  13. 09 11月, 2017 2 次提交
  14. 27 10月, 2017 3 次提交
  15. 26 10月, 2017 2 次提交
  16. 24 10月, 2017 2 次提交
    • C
      drm/i915/execlists: Remove the priority "optimisation" · 64b80085
      Chris Wilson 提交于
      Originally we set the priority to max upon inserting the request into
      the execlists queue (and removing it from the scheduler lists). We could
      then use the prio==INT_MAX as a shortcut within execlists_schedule() to
      detect the end of the dependency chain. Since commit 1f181225
      ("drm/i915/execlists: Keep request->priority for its lifetime") this is
      no longer true as we use the request completion as an indicator the
      schedule dependency chain is complete instead. (This allows us to then
      reschedule requests even when its context is in flight.) However, this
      makes the GEM_BUG_ON() inside execlists_schedule() racy as we may change
      the rq->prio at the same time. As the assertion is useful, let's keep
      the assertion and remove the micro-optimisation.
      
      Fixes: 1f181225 ("drm/i915/execlists: Keep request->priority for its lifetime")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michał Winiarski <michal.winiarski@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171024115501.21033-1-chris@chris-wilson.co.ukReviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
      64b80085
    • C
      drm/i915: Filter out spurious execlists context-switch interrupts · 4a118ecb
      Chris Wilson 提交于
      Back in commit a4b2b015 ("drm/i915: Don't mark an execlists
      context-switch when idle") we noticed the presence of late
      context-switch interrupts. We were able to filter those out by looking
      at whether the ELSP remained active, but in commit beecec90
      ("drm/i915/execlists: Preemption!") that became problematic as we now
      anticipate receiving a context-switch event for preemption while ELSP
      may be empty. To restore the spurious interrupt suppression, add a
      counter for the expected number of pending context-switches and skip if
      we do not need to handle this interrupt to make forward progress.
      
      v2: Don't forget to switch on for preempt.
      v3: Reduce the counter to a on/off boolean tracker. Declare the HW as
      active when we first submit, and idle after the final completion event
      (with which we confirm the HW says it is idle), and track each source
      of activity separately. With a finite number of sources, it should aide
      us in debugging which gets stuck.
      
      Fixes: beecec90 ("drm/i915/execlists: Preemption!")
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michal Winiarski <michal.winiarski@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171023213237.26536-3-chris@chris-wilson.co.ukReviewed-by: NMika Kuoppala <mika.kuoppala@linux.intel.com>
      4a118ecb
  17. 17 10月, 2017 1 次提交
  18. 16 10月, 2017 1 次提交
  19. 10 10月, 2017 1 次提交
  20. 07 10月, 2017 1 次提交
  21. 05 10月, 2017 2 次提交
    • C
      drm/i915/execlists: Preemption! · beecec90
      Chris Wilson 提交于
      When we write to ELSP, it triggers a context preemption at the earliest
      arbitration point (3DPRIMITIVE, some PIPECONTROLs, a few other
      operations and the explicit MI_ARB_CHECK). If this is to the same
      context, it triggers a LITE_RESTORE where the RING_TAIL is merely
      updated (used currently to chain requests from the same context
      together, avoiding bubbles). However, if it is to a different context, a
      full context-switch is performed and it will start to execute the new
      context saving the image of the old for later execution.
      
      Previously we avoided preemption by only submitting a new context when
      the old was idle. But now we wish embrace it, and if the new request has
      a higher priority than the currently executing request, we write to the
      ELSP regardless, thus triggering preemption, but we tell the GPU to
      switch to our special preemption context (not the target). In the
      context-switch interrupt handler, we know that the previous contexts
      have finished execution and so can unwind all the incomplete requests
      and compute the new highest priority request to execute.
      
      It would be feasible to avoid the switch-to-idle intermediate by
      programming the ELSP with the target context. The difficulty is in
      tracking which request that should be whilst maintaining the dependency
      change, the error comes in with coalesced requests. As we only track the
      most recent request and its priority, we may run into the issue of being
      tricked in preempting a high priority request that was followed by a
      low priority request from the same context (e.g. for PI); worse still
      that earlier request may be our own dependency and the order then broken
      by preemption. By injecting the switch-to-idle and then recomputing the
      priority queue, we avoid the issue with tracking in-flight coalesced
      requests. Having tried the preempt-to-busy approach, and failed to find
      a way around the coalesced priority issue, Michal's original proposal to
      inject an idle context (based on handling GuC preemption) succeeds.
      
      The current heuristic for deciding when to preempt are only if the new
      request is of higher priority, and has the privileged priority of
      greater than 0. Note that the scheduler remains unfair!
      
      v2: Disable for gen8 (bdw/bsw) as we need additional w/a for GPGPU.
      Since, the feature is now conditional and not always available when we
      have a scheduler, make it known via the HAS_SCHEDULER GETPARAM (now a
      capability mask).
      v3: Stylistic tweaks.
      v4: Appease Joonas with a snippet of kerneldoc, only to fuel to fire of
      the preempt vs preempting debate.
      Suggested-by: NMichal Winiarski <michal.winiarski@intel.com>
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michal Winiarski <michal.winiarski@intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
      Cc: Mika Kuoppala <mika.kuoppala@intel.com>
      Cc: Ben Widawsky <benjamin.widawsky@intel.com>
      Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
      Cc: Zhi Wang <zhi.a.wang@intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-8-chris@chris-wilson.co.uk
      beecec90
    • C
      drm/i915/execlists: Keep request->priority for its lifetime · 1f181225
      Chris Wilson 提交于
      With preemption, we will want to "unsubmit" a request, taking it back
      from the hw and returning it to the priority sorted execution list. In
      order to know where to insert it into that list, we need to remember
      its adjust priority (which may change even as it was being executed).
      
      This also affects reset for execlists as we are now unsubmitting the
      requests following the reset (rather than directly writing the ELSP for
      the inflight contexts). This turns reset into an accidental preemption
      point, as after the reset we may choose a different pair of contexts to
      submit to hw.
      
      GuC is not updated as this series doesn't add preemption to the GuC
      submission, and so it can keep benefiting from the early pruning of the
      DFS inside execlists_schedule() for a little longer. We also need to
      find a way of reducing the cost of that DFS...
      
      v2: Include priority in error-state
      Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk>
      Cc: Michał Winiarski <michal.winiarski@intel.com>
      Reviewed-by: NMichał Winiarski <michal.winiarski@intel.com>
      Reviewed-by: NJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-6-chris@chris-wilson.co.uk
      1f181225