[Intel-gfx] [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS

[Daniel Vetter]

On Wed, Nov 29, 2017 at 10:01:09AM +0000, Chris Wilson wrote:
> Quoting Chris Wilson (2017-11-29 09:57:14)
> > Quoting Daniel Vetter (2017-11-29 09:46:36)
> > > 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
> > > Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>
> >
> > In principle acked-by for core-for-CI, I think we need a bit surer
> > ground before saying that in general lockdep needs a larger array.
> 
> For upstreaming, I wonder if we could sell them on a kconfig? That way
> Tomi could adjust it more easily in his kconfig.git than having us
> provide a patch.

I'll submit both (once CI is taken care of) to lockdep folks and hear what
they think about this issue. Maybe fixing module reload is already on
their plans, maybe not.

Same really for the kthread fix, lockdep code (and maintainers) are funky
enough that I don't really dwell too much in there ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch