<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body><span class="vcard"><a class="email" href="mailto:martin.peres@free.fr" title="Martin Peres <martin.peres@free.fr>"> <span class="fn">Martin Peres</span></a>
</span> changed
<a class="bz_bug_link
bz_status_CLOSED bz_closed"
title="CLOSED FIXED - [CI][SHARDS] igt@gem_mmap_gtt@hang - fail - Failed assertion: !control->error"
href="https://bugs.freedesktop.org/show_bug.cgi?id=109469">bug 109469</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Status</td>
<td>RESOLVED
</td>
<td>CLOSED
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_CLOSED bz_closed"
title="CLOSED FIXED - [CI][SHARDS] igt@gem_mmap_gtt@hang - fail - Failed assertion: !control->error"
href="https://bugs.freedesktop.org/show_bug.cgi?id=109469#c6">Comment # 6</a>
on <a class="bz_bug_link
bz_status_CLOSED bz_closed"
title="CLOSED FIXED - [CI][SHARDS] igt@gem_mmap_gtt@hang - fail - Failed assertion: !control->error"
href="https://bugs.freedesktop.org/show_bug.cgi?id=109469">bug 109469</a>
from <span class="vcard"><a class="email" href="mailto:martin.peres@free.fr" title="Martin Peres <martin.peres@free.fr>"> <span class="fn">Martin Peres</span></a>
</span></b>
<pre>(In reply to Chris Wilson from <a href="show_bug.cgi?id=109469#c5">comment #5</a>)
<span class="quote">> commit 2caffbf1176256cc4f8d4e5c3c524fc689cb9876
> Author: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>>
> Date: Fri Feb 8 15:37:03 2019 +0000
>
> drm/i915: Revoke mmaps and prevent access to fence registers across reset
>
> Previously, we were able to rely on the recursive properties of
> struct_mutex to allow us to serialise revoking mmaps and reacquiring the
> FENCE registers with them being clobbered over a global device reset.
> I then proceeded to throw out the baby with the bath water in order to
> pursue a struct_mutex-less reset.
>
> Perusing LWN for alternative strategies, the dilemma on how to serialise
> access to a global resource on one side was answered by
> <a href="https://lwn.net/Articles/202847/">https://lwn.net/Articles/202847/</a> -- Sleepable RCU:
>
> 1 int readside(void) {
> 2 int idx;
> 3 rcu_read_lock();
> 4 if (nomoresrcu) {
> 5 rcu_read_unlock();
> 6 return -EINVAL;
> 7 }
> 8 idx = srcu_read_lock(&ss);
> 9 rcu_read_unlock();
> 10 /* SRCU read-side critical section. */
> 11 srcu_read_unlock(&ss, idx);
> 12 return 0;
> 13 }
> 14
> 15 void cleanup(void)
> 16 {
> 17 nomoresrcu = 1;
> 18 synchronize_rcu();
> 19 synchronize_srcu(&ss);
> 20 cleanup_srcu_struct(&ss);
> 21 }
>
> No more worrying about stop_machine, just an uber-complex mutex,
> optimised for reads, with the overhead pushed to the rare reset path.
>
> However, we do run the risk of a deadlock as we allocate underneath the
> SRCU read lock, and the allocation may require a GPU reset, causing a
> dependency cycle via the in-flight requests. We resolve that by declaring
> the driver wedged and cancelling all in-flight rendering.
>
> v2: Use expedited rcu barriers to match our earlier timing
> characteristics.
> v3: Try to annotate locking contexts for sparse
> v4: Reduce selftest lock duration to avoid a reset deadlock with fences
> v5: s/srcu/reset_backoff_srcu/
> v6: Remove more stale comments
>
> Testcase: igt/gem_mmap_gtt/hang
> Fixes: eb8d0f5af4ec ("drm/i915: Remove GPU reset dependence on
> struct_mutex")
> Signed-off-by: Chris Wilson <<a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a>>
> Cc: Mika Kuoppala <<a href="mailto:mika.kuoppala@intel.com">mika.kuoppala@intel.com</a>>
> Reviewed-by: Mika Kuoppala <<a href="mailto:mika.kuoppala@linux.intel.com">mika.kuoppala@linux.intel.com</a>>
> Link:
> <a href="https://patchwork.freedesktop.org/patch/msgid/20190208153708.20023-2">https://patchwork.freedesktop.org/patch/msgid/20190208153708.20023-2</a>-
> <a href="mailto:chris@chris-wilson.co.uk">chris@chris-wilson.co.uk</a></span >
It did the trick! Used to be seen every run, but not anymore for the past 3.5
weeks! Closing :)</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
<li>You are the assignee for the bug.</li>
<li>You are the QA Contact for the bug.</li>
</ul>
</body>
</html>