Quoting Michel Thierry (2018-05-08 18:30:22)
> On 05/08/2018 08:35 AM, Chris Wilson wrote:
> > CI noticed
> >
> > <4>[ 23.430701] ============================================
> > <4>[ 23.430706] WARNING: possible recursive locking detected
> > <4>[ 23.430713] 4.17.0-rc4-CI-CI_DRM_4156+ #1 Not tainted
> > <4>[ 23.430720] --------------------------------------------
> > <4>[ 23.430725] systemd-udevd/169 is trying to acquire lock:
> > <4>[ 23.430732] (ptrval) (&(&timeline->lock)->rlock){....}, at:
> > move_to_timeline+0x48/0x12c [i915]
> > <4>[ 23.430888]
> > but task is already holding lock:
> > <4>[ 23.430894] (ptrval) (&(&timeline->lock)->rlock){....}, at:
> > i915_request_submit+0x1a/0x40 [i915]
> > <4>[ 23.430995]
> > other info that might help us debug this:
> > <4>[ 23.431002] Possible unsafe locking scenario:
> >
> > <4>[ 23.431007] CPU0
> > <4>[ 23.431010] ----
> > <4>[ 23.431013] lock(&(&timeline->lock)->rlock);
> > <4>[ 23.431021] lock(&(&timeline->lock)->rlock);
> > <4>[ 23.431028]
> > *** DEADLOCK ***
> >
> > <4>[ 23.431036] May be due to missing lock nesting notation
> >
> > <4>[ 23.431044] 5 locks held by systemd-udevd/169:
> > <4>[ 23.431049] #0: (ptrval) (&dev->mutex){....}, at:
> > __driver_attach+0x42/0xe0
> > <4>[ 23.431065] #1: (ptrval) (&dev->mutex){....}, at:
> > __driver_attach+0x50/0xe0
> > <4>[ 23.431078] #2: (ptrval) (&dev->struct_mutex){+.+.}, at:
> > i915_gem_init+0xca/0x630 [i915]
> > <4>[ 23.431174] #3: (ptrval) (rcu_read_lock){....}, at:
> > submit_notify+0x35/0x124 [i915]
> > <4>[ 23.431271] #4: (ptrval) (&(&timeline->lock)->rlock){....},
> > at: i915_request_submit+0x1a/0x40 [i915]
> > <4>[ 23.431369]
> > stack backtrace:
> > <4>[ 23.431377] CPU: 0 PID: 169 Comm: systemd-udevd Not tainted
> > 4.17.0-rc4-CI-CI_DRM_4156+ #1
> > <4>[ 23.431385] Hardware name: Dell Inc. OptiPlex GX280
> > /0G8310, BIOS A04 02/09/2005
> > <4>[ 23.431394] Call Trace:
> > <4>[ 23.431403] dump_stack+0x67/0x9b
> ...
> > <4>[ 23.432765] R13: 0000561a47296450 R14: 0000000000020000 R15:
> > 0000561a472a4b30
> >
> > but did not report it as an issue as it only occurred during the first
> > module on boot. This is due to the removal of the distinct global
> > timeline, and its separate lock class. So instead mark up the expected
> > nesting. An alternative would be to define a separate lock class for the
> > engine, but since we only expect to have a single point of nesting, we
> > can avoid having multiple lock classes for the struct.
> >
> > Fixes: a89d1f921c15 ("drm/i915: Split i915_gem_timeline into individual
> > timelines")
> > Signed-off-by: Chris Wilson <[email protected]>
> > Cc: Chris Wilson <[email protected]>
> > Cc: Tvrtko Ursulin <[email protected]>
> > Cc: Joonas Lahtinen <[email protected]>
>
> Tested-by: Michel Thierry <[email protected]>
Thanks for the review and testing; pushed. My apologies for letting an
obvious bug in hindsight slip through,
-Chris
_______________________________________________
Intel-gfx mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
