[Intel-gfx] [PATCH v2] drm/i915/selftests: Yet another forgotten mock_i915->mm initialiser

[Chris Wilson]

Quoting Matthew Auld (2017-11-10 23:40:07)
> On 10 November 2017 at 23:24, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> > Move all of the i915->mm initialisation to a private function that can
> > be reused by the mock i915 device to save forgetting any more steps.
> >
> > For example,
> > <7>[ 1542.046332] [IGT] drv_selftest: starting subtest mock_objects
> > <4>[ 1542.123924] Setting dangerous option mock_selftests - tainting kernel
> > <6>[ 1542.167941] i915: Performing mock selftests with st_random_seed=0x246f5ab5 st_timeout=1000
> > <4>[ 1542.178012] INFO: trying to register non-static key.
> > <4>[ 1542.178027] the code is fine but needs lockdep annotation.
> > <4>[ 1542.178032] turning off the locking correctness validator.
> > <4>[ 1542.178041] CPU: 3 PID: 6008 Comm: kworker/3:7 Tainted: G     U          4.14.0-rc8-CI-CI_DRM_3332+ #1
> > <4>[ 1542.178049] Hardware name:                  /NUC6CAYB, BIOS AYAPLCEL.86A.0040.2017.0619.1722 06/19/2017
> > <4>[ 1542.178144] Workqueue: events __i915_gem_free_work [i915]
> > <4>[ 1542.178152] Call Trace:
> > <4>[ 1542.178163]  dump_stack+0x68/0x9f
> > <4>[ 1542.178170]  register_lock_class+0x3fd/0x580
> > <4>[ 1542.178177]  ? unwind_next_frame+0x14/0x20
> > <4>[ 1542.178184]  ? __save_stack_trace+0x73/0xd0
> > <4>[ 1542.178191]  __lock_acquire+0xa4/0x1b00
> > <4>[ 1542.178254]  ? __i915_gem_free_work+0x28/0xa0 [i915]
> > <4>[ 1542.178261]  ? __lock_acquire+0x4ab/0x1b00
> > <4>[ 1542.178268]  lock_acquire+0xb0/0x200
> > <4>[ 1542.178273]  ? lock_acquire+0xb0/0x200
> > <4>[ 1542.178336]  ? __i915_gem_free_work+0x28/0xa0 [i915]
> > <4>[ 1542.178344]  _raw_spin_lock+0x32/0x50
> > <4>[ 1542.178405]  ? __i915_gem_free_work+0x28/0xa0 [i915]
> > <4>[ 1542.178468]  __i915_gem_free_work+0x28/0xa0 [i915]
> > <4>[ 1542.178476]  process_one_work+0x221/0x650
> > <4>[ 1542.178483]  worker_thread+0x4e/0x3c0
> > <4>[ 1542.178489]  kthread+0x114/0x150
> > <4>[ 1542.178494]  ? process_one_work+0x650/0x650
> > <4>[ 1542.178499]  ? kthread_create_on_node+0x40/0x40
> > <4>[ 1542.178506]  ret_from_fork+0x27/0x40
> >
> > v2: Fish out i915->mm.object_stat_lock which was being inited over in
> > i915_drv.c (Matthew)
> >
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Matthew Auld <matthew.auld at intel.com>
> Reviewed-by: Matthew Auld <matthew.auld at intel.com>

Thanks, and pushed. One thing we to consider is how to reign
live_hugepages in a bit or complain about the owatch timeout being too
short. And if you have a moment to spare, the shards suggest that there
is a kernel memory leak but not being reported by the standard mm checks
on unload.
-Chris