1. 22 Apr, 2017 1 commit
    • Chris Wilson's avatar
      drm/i915: Confirm the request is still active before adding it to the await · ade0b0c9
      Chris Wilson authored
      Although we do check the completion-status of the request before
      actually adding a wait on it (either to its submit fence or its
      completion dma-fence), we currently do not check before adding it to the
      dependency lists.
      
      In fact, without checking for a completed request we may try to use the
      signaler after it has been retired and its dependency tree freed:
      
      [   60.044057] BUG: KASAN: use-after-free in __list_add_valid+0x1d/0xd0 at addr ffff880348c9e6a0
      [   60.044118] Read of size 8 by task gem_exec_fence/530
      [   60.044164] CPU: 1 PID: 530 Comm: gem_exec_fence Tainted: G            E   4.11.0-rc7+ #46
      [   60.044226] Hardware name: ��������������������������������� ���������������������������������/���������������������������������, BIOS RYBDWi35.86A.0246.2
      [   60.044290] Call Trace:
      [   60.044337]  dump_stack+0x4d/0x6a
      [   60.044383]  kasan_object_err+0x21/0x70
      [   60.044435]  kasan_report+0x225/0x4e0
      [   60.044488]  ? __list_add_valid+0x1d/0xd0
      [   60.044534]  ? kasan_kmalloc+0xad/0xe0
      [   60.044587]  __asan_load8+0x5e/0x70
      [   60.044639]  __list_add_valid+0x1d/0xd0
      [   60.044788]  __i915_priotree_add_dependency+0x67/0x130 [i915]
      [   60.044895]  i915_gem_request_await_request+0xa8/0x370 [i915]
      [   60.044974]  i915_gem_request_await_dma_fence+0x129/0x140 [i915]
      [   60.045049]  i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
      [   60.045077]  ? save_stack+0xb1/0xd0
      [   60.045105]  ? save_stack_trace+0x1b/0x20
      [   60.045132]  ? save_stack+0x46/0xd0
      [   60.045158]  ? kasan_kmalloc+0xad/0xe0
      [   60.045184]  ? __kmalloc+0xd8/0x670
      [   60.045229]  ? drm_ioctl+0x359/0x640 [drm]
      [   60.045256]  ? SyS_ioctl+0x41/0x70
      [   60.045330]  ? i915_vma_move_to_active+0x540/0x540 [i915]
      [   60.045360]  ? tty_insert_flip_string_flags+0xa1/0xf0
      [   60.045387]  ? tty_flip_buffer_push+0x63/0x70
      [   60.045414]  ? remove_wait_queue+0xa9/0xc0
      [   60.045441]  ? kasan_unpoison_shadow+0x35/0x50
      [   60.045467]  ? kasan_kmalloc+0xad/0xe0
      [   60.045494]  ? kasan_check_write+0x14/0x20
      [   60.045568]  i915_gem_execbuffer2+0xdb/0x2a0 [i915]
      [   60.045616]  drm_ioctl+0x359/0x640 [drm]
      [   60.045705]  ? i915_gem_execbuffer+0x5a0/0x5a0 [i915]
      [   60.045751]  ? drm_version+0x150/0x150 [drm]
      [   60.045778]  ? compat_start_thread+0x60/0x60
      [   60.045805]  ? plist_del+0xda/0x1a0
      [   60.045833]  do_vfs_ioctl+0x12e/0x910
      [   60.045860]  ? ioctl_preallocate+0x130/0x130
      [   60.045886]  ? pci_mmcfg_check_reserved+0xc0/0xc0
      [   60.045913]  ? vfs_write+0x196/0x240
      [   60.045939]  ? __fget_light+0xa7/0xc0
      [   60.045965]  SyS_ioctl+0x41/0x70
      [   60.045991]  entry_SYSCALL_64_fastpath+0x17/0x98
      [   60.046017] RIP: 0033:0x7feb2baefc47
      [   60.046042] RSP: 002b:00007fff56d28e58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
      [   60.046075] RAX: ffffffffffffffda RBX: 00007fff56d290a8 RCX: 00007feb2baefc47
      [   60.046102] RDX: 00007fff56d29050 RSI: 00000000c0406469 RDI: 0000000000000003
      [   60.046129] RBP: 00007fff56d29050 R08: 000055ecc4cd27d0 R09: 00007feb2bda8600
      [   60.046154] R10: 0000000000000073 R11: 0000000000000246 R12: 00000000c0406469
      [   60.046177] R13: 0000000000000003 R14: 000000000000000f R15: 0000000000000099
      [   60.046203] Object at ffff880348c9e680, in cache i915_dependency size: 64
      [   60.046225] Allocated:
      [   60.046246] PID = 530
      [   60.046269]  save_stack_trace+0x1b/0x20
      [   60.046292]  save_stack+0x46/0xd0
      [   60.046318]  kasan_kmalloc+0xad/0xe0
      [   60.046343]  kasan_slab_alloc+0x12/0x20
      [   60.046368]  kmem_cache_alloc+0xab/0x650
      [   60.046445]  i915_gem_request_await_request+0x88/0x370 [i915]
      [   60.046559]  i915_gem_request_await_dma_fence+0x129/0x140 [i915]
      [   60.046705]  i915_gem_do_execbuffer.isra.37+0xb0a/0x26b0 [i915]
      [   60.046849]  i915_gem_execbuffer2+0xdb/0x2a0 [i915]
      [   60.046936]  drm_ioctl+0x359/0x640 [drm]
      [   60.046987]  do_vfs_ioctl+0x12e/0x910
      [   60.047038]  SyS_ioctl+0x41/0x70
      [   60.047090]  entry_SYSCALL_64_fastpath+0x17/0x98
      [   60.047139] Freed:
      [   60.047179] PID = 530
      [   60.047223]  save_stack_trace+0x1b/0x20
      [   60.047269]  save_stack+0x46/0xd0
      [   60.047317]  kasan_slab_free+0x72/0xc0
      [   60.047366]  kmem_cache_free+0x39/0x160
      [   60.047512]  i915_gem_request_retire+0x83f/0x930 [i915]
      [   60.047657]  i915_gem_request_alloc+0x166/0x600 [i915]
      [   60.047799]  i915_gem_do_execbuffer.isra.37+0xad8/0x26b0 [i915]
      [   60.047897]  i915_gem_execbuffer2+0xdb/0x2a0 [i915]
      [   60.047942]  drm_ioctl+0x359/0x640 [drm]
      [   60.047968]  do_vfs_ioctl+0x12e/0x910
      [   60.047993]  SyS_ioctl+0x41/0x70
      [   60.048019]  entry_SYSCALL_64_fastpath+0x17/0x98
      [   60.048044] Memory state around the buggy address:
      [   60.048066]  ffff880348c9e580: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
      [   60.048105]  ffff880348c9e600: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
      [   60.048138] >ffff880348c9e680: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc
      [   60.048170]                                ^
      [   60.048191]  ffff880348c9e700: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
      [   60.048225]  ffff880348c9e780: 00 00 00 00 00 00 00 00 fc fc fc fc fc fc fc fc
      
      Note to hit the use-after-free requires us to be passed back a request
      via a fence-array, that is from explicit fencing accumulated into a
      sync-file fence-array.
      
      Fixes: 52e54209 ("drm/i915/scheduler: Record all dependencies upon request construction")
      Testcase: igt/gem_exec_fence/expired-history
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarMichał Winiarski <michal.winiarski@intel.com>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170422081537.6468-1-chris@chris-wilson.co.uk
      ade0b0c9
  2. 21 Apr, 2017 2 commits
    • Chris Wilson's avatar
      drm/i915: Avoid busy-spinning on VLV_GLTC_PW_STATUS mmio · 3dd14c04
      Chris Wilson authored
      The busy-spin, as the first stage of intel_wait_for_register(), is
      currently under suspicion for causing:
      
      [   62.034926] NMI watchdog: Watchdog detected hard LOCKUP on cpu 1
      [   62.034928] Modules linked in: i2c_dev i915 intel_gtt drm_kms_helper prime_numbers
      [   62.034932] CPU: 1 PID: 183 Comm: kworker/1:2 Not tainted 4.11.0-rc7+ #471
      [   62.034933] Hardware name:                  /        , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
      [   62.034934] Workqueue: pm pm_runtime_work
      [   62.034936] task: ffff880275a04ec0 task.stack: ffffc900002d8000
      [   62.034936] RIP: 0010:__intel_wait_for_register_fw+0x77/0x1a0 [i915]
      [   62.034937] RSP: 0018:ffffc900002dbc38 EFLAGS: 00000082
      [   62.034939] RAX: ffffc90003530094 RBX: 0000000000130094 RCX: 0000000000000001
      [   62.034940] RDX: 00000000000000a1 RSI: ffff88027fd15e58 RDI: 0000000000000000
      [   62.034941] RBP: ffffc900002dbc78 R08: 0000000000000002 R09: 0000000000000000
      [   62.034942] R10: ffffc900002dbc18 R11: ffff880276429dd0 R12: ffff8802707c0000
      [   62.034943] R13: 00000000000000a0 R14: 0000000000000000 R15: 00000000fffefc10
      [   62.034945] FS:  0000000000000000(0000) GS:ffff88027fd00000(0000) knlGS:0000000000000000
      [   62.034945] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [   62.034947] CR2: 00007ffd3cd98ff8 CR3: 0000000274c19000 CR4: 00000000001006e0
      [   62.034947] Call Trace:
      [   62.034948]  intel_wait_for_register+0x77/0x140 [i915]
      [   62.034949]  vlv_suspend_complete+0x23/0x5b0 [i915]
      [   62.034950]  intel_runtime_suspend+0x16c/0x2a0 [i915]
      [   62.034950]  pci_pm_runtime_suspend+0x50/0x180
      [   62.034951]  ? pci_pm_runtime_resume+0xa0/0xa0
      [   62.034952]  __rpm_callback+0xc5/0x210
      [   62.034953]  rpm_callback+0x1f/0x80
      [   62.034953]  ? pci_pm_runtime_resume+0xa0/0xa0
      [   62.034954]  rpm_suspend+0x118/0x580
      [   62.034955]  pm_runtime_work+0x64/0x90
      [   62.034956]  process_one_work+0x1bb/0x3e0
      [   62.034956]  worker_thread+0x46/0x4f0
      [   62.034957]  ? __schedule+0x18b/0x610
      [   62.034958]  kthread+0xff/0x140
      [   62.034958]  ? process_one_work+0x3e0/0x3e0
      [   62.034959]  ? kthread_create_on_node+
      
      and related hard lockups in CI for byt and bsw.
      
      Note this effectively reverts commits 41ce405e and b2736695
      ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")
      
      v2: Convert bool allow into a u32 mask for clarity and repeat the
      comment on vlv rc6 timing to justify the 3ms timeout used for the wait (Ville)
      
      Fixes: 41ce405e ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")
      Fixes: b2736695 ("drm/i915: Convert wait_for(I915_READ(reg)) to intel_wait_for_register()")
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100718Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
      Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
      Cc: Tomi Sarvela <tomi.p.sarvela@intel.com>
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170421135815.11897-1-chris@chris-wilson.co.ukTested-by: default avatarTomi Sarvela <tomi.p.sarvela@intel.com>
      3dd14c04
    • Chris Wilson's avatar
      drm/i915: Stop touching hangcheck.seqno from intel_engine_init_global_seqno() · 546cdbc7
      Chris Wilson authored
      The hangcheck runs independently to the main flow of seqno through the
      driver. However, we have an odd coupling of the seqno reset that is
      unwelcome, and if poked at just the right rate can cause spurious hangs
      (e.g. gem_exec_whisper) on an apparently idle engine.
      Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
      Reviewed-by: default avatarMika Kuoppala <mika.kuoppala@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170421083113.21321-1-chris@chris-wilson.co.uk
      546cdbc7
  3. 20 Apr, 2017 2 commits
  4. 19 Apr, 2017 2 commits
  5. 18 Apr, 2017 2 commits
  6. 15 Apr, 2017 2 commits
  7. 13 Apr, 2017 4 commits
  8. 12 Apr, 2017 17 commits
  9. 11 Apr, 2017 8 commits