[Bug 103950] [CI] igt@* - dmesg-warn - WARNING: possible circular locking dependency detected

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=103950

Marta Löfstedt <marta.lofstedt at intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #21 from Marta Löfstedt <marta.lofstedt at intel.com> ---
a fix was integrated to CI_DRM_3411

commit 8f873adc152c899d0e1b9ccaf9caa468955c1fdd
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date:   Wed Nov 29 17:29:54 2017 +0100

    drm-tip: 2017y-11m-29d-16h-28m-40s UTC integration manifest

commit aff78eb7ce76b42d4c94d2f5ce768c1c2c8fb94d
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date:   Wed Nov 29 12:29:26 2017 +0100

    lockdep: finer-grained completion key for kthread

    Ideally we'd create the key through a macro at the real callers and
    pass it all the way down. This would give us better coverage for cases
    where a bunch of kthreads are created for the same thing.
    But this gets the job done meanwhile and unblocks our CI. Refining
    later on is always possible.

    v2:
    - make it compile
    - use the right map (Tvrtko)

    v3:

    lockdep insist on a static key, so the cheap way didn't work. Wire
    2 keys through all the callers.

    I didn't extend this up to alloc_workqueue because the
    lockdep_invariant_state() call should separate the work functions from
    the workqueue kthread logic and prevent cross-release state from
    leaking between unrelated work queues that happen to reuse the same
    kthreads.

    v4: CI found more compile fail :-/

    Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
    Cc: Marta Lofstedt <marta.lofstedt at intel.com>
    References: https://bugs.freedesktop.org/show_bug.cgi?id=103950
    Acked-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
    Acked-by: Chris Wilson <chris at chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
    Link:
https://patchwork.freedesktop.org/patch/msgid/20171129112926.28704-1-daniel.vetter@ffwll.ch

commit 281f8d96fa83efe67198608fe0d1792518c91925
Author: Daniel Vetter <daniel.vetter at ffwll.ch>
Date:   Wed Nov 29 10:46:36 2017 +0100

    lockdep: Up MAX_LOCKDEP_CHAINS

    cross-release ftl

    From Chris:

    "Fwiw, this isn't cross-release but us reloading the module many times,
    creating a whole host of new lockclasses. Even more fun is when the
    module gets a slightly different address and the new lock address hashes
    into an old lock...

    "I did think about a module-hook to revoke the stale lockclasses, but
    that still leaves all the hashed chains.

    "This particular nuisance was temporarily pushed back by teaching igt not
    to reload i915.ko on a whim."

    Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
    Cc: Marta Lofstedt <marta.lofstedt at intel.com>
    References: https://bugs.freedesktop.org/show_bug.cgi?id=103707
    Acked-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
    Acked-by: Chris Wilson <chris at chris-wilson.co.uk>
    Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
    Link:
https://patchwork.freedesktop.org/patch/msgid/20171129094636.18638-2-daniel.vetter@ffwll.ch

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20171130/d6e72957/attachment-0001.html>