forked from Minki/linux
f9eb63b98c
Despite us reloading the module around every selftest, the lockclasses persist and the chains used in selftesting may then dictate how we are allowed to nest locks during runtime testing. As such we have to be just as careful, and in particular it turns out we are not allowed to nest dev->object_name_lock (drm_gem_handle_create) inside dev->struct_mutex. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103830 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171121110652.1107-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> |
||
|---|---|---|
| .. | ||
| huge_gem_object.c | ||
| huge_gem_object.h | ||
| huge_pages.c | ||
| i915_gem_coherency.c | ||
| i915_gem_context.c | ||
| i915_gem_dmabuf.c | ||
| i915_gem_evict.c | ||
| i915_gem_gtt.c | ||
| i915_gem_object.c | ||
| i915_gem_request.c | ||
| i915_gem_timeline.c | ||
| i915_live_selftests.h | ||
| i915_mock_selftests.h | ||
| i915_random.c | ||
| i915_random.h | ||
| i915_selftest.c | ||
| i915_sw_fence.c | ||
| i915_syncmap.c | ||
| i915_vma.c | ||
| intel_breadcrumbs.c | ||
| intel_guc.c | ||
| intel_hangcheck.c | ||
| intel_uncore.c | ||
| lib_sw_fence.c | ||
| lib_sw_fence.h | ||
| mock_context.c | ||
| mock_context.h | ||
| mock_dmabuf.c | ||
| mock_dmabuf.h | ||
| mock_drm.c | ||
| mock_drm.h | ||
| mock_engine.c | ||
| mock_engine.h | ||
| mock_gem_device.c | ||
| mock_gem_device.h | ||
| mock_gem_object.h | ||
| mock_gtt.c | ||
| mock_gtt.h | ||
| mock_request.c | ||
| mock_request.h | ||
| mock_timeline.c | ||
| mock_timeline.h | ||
| mock_uncore.c | ||
| mock_uncore.h | ||
| scatterlist.c | ||