[PATCH 1/2] lockdep: finer-grained completion key for kthread

[PATCH 1/2] lockdep: finer-grained completion key for kthread

[Daniel Vetter]

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)

Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Marta Lofstedt <marta.lofstedt@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=103950
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 kernel/kthread.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/kernel/kthread.c b/kernel/kthread.c
index cd50e99202b0..8df5fedb9529 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -44,6 +44,10 @@ struct kthread {
 	unsigned long flags;
 	unsigned int cpu;
 	void *data;
+#ifdef CONFIG_LOCKDEP_COMPLETIONS
+	struct lock_class_key parked_key;
+	struct lock_class_key exited_key;
+#endif
 	struct completion parked;
 	struct completion exited;
 #ifdef CONFIG_BLK_CGROUP
@@ -221,8 +225,17 @@ static int kthread(void *_create)
 	}
 
 	self->data = data;
-	init_completion(&self->exited);
-	init_completion(&self->parked);
+	/* these two completions are shared with all kthread, which is bonghist
+	 * imo */
+	lockdep_init_map_crosslock(&self->exited.map.map,
+			"(kthread completion)->exited",
+			&self->exited_key, 0);
+	init_completion_map(&self->exited, &self->exited.map.map);
+	lockdep_init_map_crosslock(&self->parked.map.map,
+			"(kthread completion)->parked",
+			&self->parked_key, 0);
+	init_completion_map(&self->parked, &self->exited.map.map);
+
 	current->vfork_done = &self->exited;
 
 	/* OK, tell user we're spawned, wait for stop or wakeup */
-- 
2.15.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS

[Daniel Vetter]

cross-release ftl

Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Marta Lofstedt <marta.lofstedt@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=103707
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 kernel/locking/lockdep_internals.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/locking/lockdep_internals.h b/kernel/locking/lockdep_internals.h
index d459d624ba2a..41630a5385c6 100644
--- a/kernel/locking/lockdep_internals.h
+++ b/kernel/locking/lockdep_internals.h
@@ -69,7 +69,7 @@ enum {
 #else
 #define MAX_LOCKDEP_ENTRIES	32768UL
 
-#define MAX_LOCKDEP_CHAINS_BITS	16
+#define MAX_LOCKDEP_CHAINS_BITS	17
 
 /*
  * Stack-trace: tightly packed array of stack backtrace
-- 
2.15.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS

[Chris Wilson]

Quoting Daniel Vetter (2017-11-28 17:07:07)
> cross-release ftl

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.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.BAT: success for series starting with [1/2] lockdep: finer-grained completion key for kthread

[Patchwork]

== Series Details ==

Series: series starting with [1/2] lockdep: finer-grained completion key for kthread
URL   : https://patchwork.freedesktop.org/series/34556/
State : success

== Summary ==

Series 34556v1 series starting with [1/2] lockdep: finer-grained completion key for kthread
https://patchwork.freedesktop.org/api/1.0/series/34556/revisions/1/mbox/

fi-bdw-5557u     total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  time:421s
fi-bdw-gvtdvm    total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  time:427s
fi-bsw-n3050     total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  time:454s
fi-bwr-2160      total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 time:253s
fi-bxt-dsi       total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  time:471s
fi-bxt-j4205     total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  time:470s
fi-byt-j1900     total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  time:443s
fi-byt-n2820     total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  time:427s
fi-elk-e7500     total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  time:409s
fi-gdg-551       total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 time:240s
fi-glk-1         total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  time:514s
fi-hsw-4770      total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:374s
fi-hsw-4770r     total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  time:246s
fi-ilk-650       total:288  pass:228  dwarn:0   dfail:0   fail:0   skip:60  time:409s
fi-ivb-3520m     total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  time:464s
fi-kbl-7500u     total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  time:476s
fi-kbl-7567u     total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:460s
fi-kbl-r         total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:513s
fi-pnv-d510      total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  time:482s
fi-skl-6260u     total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:433s
fi-skl-6600u     total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:525s
fi-skl-6700hq    total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:547s
fi-skl-6700k     total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  time:505s
fi-skl-6770hq    total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:479s
fi-skl-gvtdvm    total:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  time:432s
fi-snb-2520m     total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  time:544s
fi-snb-2600      total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  time:400s
Blacklisted hosts:
fi-cfl-s2        total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:600s
fi-cnl-y         total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:583s
fi-glk-dsi       total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  time:461s
fi-blb-e6850 failed to collect. IGT log at Patchwork_7328/fi-blb-e6850/igt.log
fi-kbl-7560u failed to collect. IGT log at Patchwork_7328/fi-kbl-7560u/igt.log

5144438448829ec2a3d94fd16a9e69a52cfa7b3b drm-tip: 2017y-11m-28d-17h-04m-56s UTC integration manifest
77504fcd19ba lockdep: Up MAX_LOCKDEP_CHAINS
0dc70bf6d898 lockdep: finer-grained completion key for kthread

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7328/
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS

[Daniel Vetter]

On Tue, Nov 28, 2017 at 05:22:00PM +0000, Chris Wilson wrote:
> Quoting Daniel Vetter (2017-11-28 17:07:07)
> > cross-release ftl
> 
> 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.

Ah ... Added your explanation to the commit message, and I guess that just
means we'll have to carry it ourselves :-/

I'll still send them out if CI approves to lockdep folks, just as an fyi.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

✓ Fi.CI.IGT: success for series starting with [1/2] lockdep: finer-grained completion key for kthread

[Patchwork]

== Series Details ==

Series: series starting with [1/2] lockdep: finer-grained completion key for kthread
URL   : https://patchwork.freedesktop.org/series/34556/
State : success

== Summary ==

Blacklisted hosts:
shard-hsw        total:2661 pass:1532 dwarn:2   dfail:0   fail:11  skip:1116 time:8786s
shard-snb        total:2559 pass:1238 dwarn:12  dfail:4   fail:7   skip:1296 time:7820s

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7328/shards.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS

[Daniel Vetter]

On Thu, Nov 30, 2017 at 08:47:18AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 29, 2017 at 04:41:45PM +0100, Daniel Vetter wrote:
> > 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...
> 
> Yeah, this is a known issue, just reboot.
> 
> > "I did think about a module-hook to revoke the stale lockclasses, but
> > that still leaves all the hashed chains.
> 
> Its an absolute royal pain to remove all the resources consumed by a
> module, and if you manage you then have to deal with fragmented storage
> -- that is, we need to go keep track of which entries are used.
> 
> Its a giant heap of complexity that's just not worth it.
> 
> 
> Given all that, I don't see why we should up this. Just don't reload
> modules (or better, don't use modules at all).

We use excessive amounts of module reloading to validate the failure paths
of driver load. Rebooting takes too much time. I guess we could look into
just rebinding the driver without reloading, that should take the pain off
lockdep. Meanwhile we can carry this locally.

I just included this to check whether you have any plans, thanks for
clarifying that this is not worth it from a core perspective to get fixed.
The real issue we have in CI is the one the first patch papers over.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS

[Daniel Vetter]

On Thu, Nov 30, 2017 at 08:47:18AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 29, 2017 at 04:41:45PM +0100, Daniel Vetter wrote:
> > 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...
> 
> Yeah, this is a known issue, just reboot.
> 
> > "I did think about a module-hook to revoke the stale lockclasses, but
> > that still leaves all the hashed chains.
> 
> Its an absolute royal pain to remove all the resources consumed by a
> module, and if you manage you then have to deal with fragmented storage
> -- that is, we need to go keep track of which entries are used.
> 
> Its a giant heap of complexity that's just not worth it.
> 
> 
> Given all that, I don't see why we should up this. Just don't reload
> modules (or better, don't use modules at all).

We use excessive amounts of module reloading to validate the failure paths
of driver load. Rebooting takes too much time. I guess we could look into
just rebinding the driver without reloading, that should take the pain off
lockdep. Meanwhile we can carry this locally.

I just included this to check whether you have any plans, thanks for
clarifying that this is not worth it from a core perspective to get fixed.
The real issue we have in CI is the one the first patch papers over.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS

[Peter Zijlstra]

On Wed, Nov 29, 2017 at 04:41:45PM +0100, Daniel Vetter wrote:
> 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...

Yeah, this is a known issue, just reboot.

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

Its an absolute royal pain to remove all the resources consumed by a
module, and if you manage you then have to deal with fragmented storage
-- that is, we need to go keep track of which entries are used.

Its a giant heap of complexity that's just not worth it.


Given all that, I don't see why we should up this. Just don't reload
modules (or better, don't use modules at all).

Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS

[Peter Zijlstra]

On Wed, Nov 29, 2017 at 04:41:45PM +0100, Daniel Vetter wrote:
> 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...

Yeah, this is a known issue, just reboot.

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

Its an absolute royal pain to remove all the resources consumed by a
module, and if you manage you then have to deal with fragmented storage
-- that is, we need to go keep track of which entries are used.

Its a giant heap of complexity that's just not worth it.


Given all that, I don't see why we should up this. Just don't reload
modules (or better, don't use modules at all).
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS

[Daniel Vetter]

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@intel.com>
Cc: Marta Lofstedt <marta.lofstedt@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=103707
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 kernel/locking/lockdep_internals.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/locking/lockdep_internals.h b/kernel/locking/lockdep_internals.h
index d459d624ba2a..41630a5385c6 100644
--- a/kernel/locking/lockdep_internals.h
+++ b/kernel/locking/lockdep_internals.h
@@ -69,7 +69,7 @@ enum {
 #else
 #define MAX_LOCKDEP_ENTRIES	32768UL
 
-#define MAX_LOCKDEP_CHAINS_BITS	16
+#define MAX_LOCKDEP_CHAINS_BITS	17
 
 /*
  * Stack-trace: tightly packed array of stack backtrace
-- 
2.15.0

[PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS

[Daniel Vetter]

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@intel.com>
Cc: Marta Lofstedt <marta.lofstedt@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=103707
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 kernel/locking/lockdep_internals.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/locking/lockdep_internals.h b/kernel/locking/lockdep_internals.h
index d459d624ba2a..41630a5385c6 100644
--- a/kernel/locking/lockdep_internals.h
+++ b/kernel/locking/lockdep_internals.h
@@ -69,7 +69,7 @@ enum {
 #else
 #define MAX_LOCKDEP_ENTRIES	32768UL
 
-#define MAX_LOCKDEP_CHAINS_BITS	16
+#define MAX_LOCKDEP_CHAINS_BITS	17
 
 /*
  * Stack-trace: tightly packed array of stack backtrace
-- 
2.15.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [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@intel.com>
> > > Cc: Marta Lofstedt <marta.lofstedt@intel.com>
> > > References: https://bugs.freedesktop.org/show_bug.cgi?id=103707
> > > Signed-off-by: Daniel Vetter <daniel.vetter@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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS

[Chris Wilson]

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@intel.com>
> > Cc: Marta Lofstedt <marta.lofstedt@intel.com>
> > References: https://bugs.freedesktop.org/show_bug.cgi?id=103707
> > Signed-off-by: Daniel Vetter <daniel.vetter@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.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS

[Chris Wilson]

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@intel.com>
> Cc: Marta Lofstedt <marta.lofstedt@intel.com>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=103707
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>

Yes, I think we need to carry this for CI. cross-release will add many
more chains, and since we already exhausted the previous array we will
need more (and just reducing the number of module reloads only gives a
temporary respite). Doubling the array doesn't seem like it'll buy us
much time though? Could we afford 20 bits? Might we not also need to
expand the lockclasses array? That we could just double?

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.
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS

[Daniel Vetter]

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@intel.com>
Cc: Marta Lofstedt <marta.lofstedt@intel.com>
References: https://bugs.freedesktop.org/show_bug.cgi?id=103707
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
 kernel/locking/lockdep_internals.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/locking/lockdep_internals.h b/kernel/locking/lockdep_internals.h
index d459d624ba2a..41630a5385c6 100644
--- a/kernel/locking/lockdep_internals.h
+++ b/kernel/locking/lockdep_internals.h
@@ -69,7 +69,7 @@ enum {
 #else
 #define MAX_LOCKDEP_ENTRIES	32768UL
 
-#define MAX_LOCKDEP_CHAINS_BITS	16
+#define MAX_LOCKDEP_CHAINS_BITS	17
 
 /*
  * Stack-trace: tightly packed array of stack backtrace
-- 
2.15.0

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx