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 <chris@xxxxxxxxxxxxxxxxxx>
> > Cc: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
> > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
> > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx>
>
> Tested-by: Michel Thierry <michel.thierry@xxxxxxxxx>
Thanks for the review and testing; pushed. My apologies for letting an
obvious bug in hindsight slip through,
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
