The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* ICL: igt@gem_exec_await@wide-context - incomplete - BUG: sleeping function called from invalid context
  - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_233/fi-icl-y/igt@gem_exec_await@wide-contexts.html

The CI Bug Log issue associated to this bug has been updated.

### New filters associated

* ICL: igt@runner@aborted - fail - Previous test: gem_exec_await (wide-contexts)
  - https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_233/fi-icl-y/igt@runner@aborted.html

<4>[  423.304434] RIP: 0010:__list_del_entry_valid+0x2d/0x90
<4>[  423.304441] Code: 48 b9 00 01 00 00 00 00 ad de 48 8b 57 08 48 39 c8 74 26 48 b9 00 02 00 00 00 00 ad de 48 39 ca 74 2e 48 8b 32 48 39 fe 75 3a <48> 8b 50 08 48 39 f2 75 48 b8 01 00 00 00 c3 48 89 fe 48 89 c2 48
<4>[  423.304458] RSP: 0018:ffffa953406e3c98 EFLAGS: 00010246
<4>[  423.304465] RAX: fffda3ee05d4f988 RBX: ffffa3ee04c5a008 RCX: dead000000000200
<4>[  423.304473] RDX: ffffa3ee1de3d990 RSI: ffffa3ee04c5a008 RDI: ffffa3ee04c5a008
<4>[  423.304480] RBP: ffffa953406e3cf8 R08: 0000000000000000 R09: 0000000000000001
<4>[  423.304488] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa3ee1bf8d3d8
<4>[  423.304495] R13: ffffa3ee1bf8d910 R14: dead000000000200 R15: dead000000000100
<4>[  423.304503] FS:  00007f5b84551980(0000) GS:ffffa3ee5be00000(0000) knlGS:0000000000000000
<4>[  423.304512] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[  423.304518] CR2: 00007fd945eb1788 CR3: 000000028de16003 CR4: 0000000000760ef0
<4>[  423.304526] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>[  423.304533] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
<4>[  423.304540] PKRU: 55555554
<4>[  423.304544] Call Trace:
<4>[  423.304588]  context_close+0x79/0x2b0 [i915]
<4>[  423.304624]  ? i915_gem_context_create_ioctl+0x160/0x160 [i915]
<4>[  423.304656]  ? i915_gem_context_create_ioctl+0x160/0x160 [i915]
<4>[  423.304687]  i915_gem_context_destroy_ioctl+0x1a9/0x200 [i915]
<4>[  423.304696]  drm_ioctl_kernel+0x83/0xf0
<4>[  423.304703]  drm_ioctl+0x2f3/0x3b0
<4>[  423.304730]  ? i915_gem_context_create_ioctl+0x160/0x160 [i915]
<4>[  423.304741]  ? trace_hardirqs_on_thunk+0x1a/0x1c
<4>[  423.304749]  ? lockdep_hardirqs_on+0xe0/0x1b0
<4>[  423.304755]  ? trace_hardirqs_on_thunk+0x1a/0x1c
<4>[  423.304764]  do_vfs_ioctl+0xa0/0x6e0
<4>[  423.304771]  ? retint_kernel+0x2d/0x2d
<4>[  423.304778]  ksys_ioctl+0x35/0x60
<4>[  423.304785]  __x64_sys_ioctl+0x11/0x20
<4>[  423.304790]  do_syscall_64+0x55/0x190
<4>[  423.304796]  entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[  423.304803] RIP: 0033:0x7f5b839e75d7
<4>[  423.304809] Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 f7 d8 64 89 01 48
<4>[  423.304826] RSP: 002b:00007ffdc3c527e8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
<4>[  423.304835] RAX: ffffffffffffffda RBX: 000055b373ac1c20 RCX: 00007f5b839e75d7
<4>[  423.304844] RDX: 00007ffdc3c52840 RSI: 000000004008646e RDI: 0000000000000005
<4>[  423.304855] RBP: 00007ffdc3c52840 R08: 00007ffdc3ce30b0 R09: 00007ffdc3ce3080
<4>[  423.304865] R10: 00000000000ce1fc R11: 0000000000000246 R12: 000000004008646e
<4>[  423.304875] R13: 0000000000000005 R14: 0000000000000000 R15: 0000000000000000
<4>[  423.304886] Modules linked in: vgem snd_hda_codec_hdmi mei_hdcp snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm x86_pkg_temp_thermal coretemp ax88179_178a usbnet mii crct10dif_pclmul crc32_pclmul ghash_clmulni_intel e1000e ptp pps_core i915 i2c_i801 mei_me mei prime_numbers


Very surprising.

That would be release_hw_id(), and so ctx->hw_id_link which should be guared by i915->contexts.mutex.

We always use list_del_init() on ctx->hw_id_link so no opportunity for list poisoning, so either it isn't complaining about hw_id_link or this is a very weird stray write.

lut_close() also has a list_del. Let's look there next.

And lut->obj_link looks pretty solidly guarded by struct_mutex.

The question du jour then is where exactly is context_close + 0x79.

Also odd, despite it being LIST_POISON and list debugging enabled, we hit

<4>[  423.304395] general protection fault: 0000 [#1] PREEMPT SMP PTI

and not the list debug itself. Thinking more likely stray write in that case?

Bumping the priority since it is also seen on shards!

According to Chris, this is a random memcorruption that was waiting on the gem_create/clear bisect.

Could be

commit 0152b3b3f49b36b0f1a1bf9f0353dc636f41d8f0
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed May 8 12:24:52 2019 +0100

    drm/i915: Seal races between async GPU cancellation, retirement and signaling
    
    Currently there is an underlying assumption that i915_request_unsubmit()
    is synchronous wrt the GPU -- that is the request is no longer in flight
    as we remove it. In the near future that may change, and this may upset
    our signaling as we can process an interrupt for that request while it
    is no longer in flight.
    
    CPU0                                    CPU1
    intel_engine_breadcrumbs_irq
    (queue request completion)
                                            i915_request_cancel_signaling
    ...                                     ...
                                            i915_request_enable_signaling
    dma_fence_signal
    
    Hence in the time it took us to drop the lock to signal the request, a
    preemption event may have occurred and re-queued the request. In the
    process, that request would have seen I915_FENCE_FLAG_SIGNAL clear and
    so reused the rq->signal_link that was in use on CPU0, leading to bad
    pointer chasing in intel_engine_breadcrumbs_irq.
    
    A related issue was that if someone started listening for a signal on a
    completed but no longer in-flight request, we missed the opportunity to
    immediately signal that request.
    
    Furthermore, as intel_contexts may be immediately released during
    request retirement, in order to be entirely sure that
    intel_engine_breadcrumbs_irq may no longer dereference the intel_context
    (ce->signals and ce->signal_link), we must wait for irq spinlock.
    
    In order to prevent the race, we use a bit in the fence.flags to signal
    the transfer onto the signal list inside intel_engine_breadcrumbs_irq.
    For simplicity, we use the DMA_FENCE_FLAG_SIGNALED_BIT as it then
    quickly signals to any outside observer that the fence is indeed signaled.
    
    v2: Sketch out potential dma-fence API for manual signaling
    v3: And the test_and_set_bit()
    
    Fixes: 52c0fdb25c7c ("drm/i915: Replace global breadcrumbs with per-context interrupt tracking")
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190508112452.18942-1-chris@chris-wilson.co.uk

There's a very small potential use-after-free inside the context there.