All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/2] lockdep: finer-grained completion key for kthread
@ 2017-11-29  9:46 Daniel Vetter
  2017-11-29  9:46 ` [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS Daniel Vetter
                   ` (4 more replies)
  0 siblings, 5 replies; 19+ messages in thread
From: Daniel Vetter @ 2017-11-29  9:46 UTC (permalink / raw)
  To: Intel Graphics Development; +Cc: Daniel Vetter, 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)

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.

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>
---
 include/linux/kthread.h | 48 ++++++++++++++++++++++++++++-----
 kernel/kthread.c        | 70 ++++++++++++++++++++++++++++++++++---------------
 2 files changed, 90 insertions(+), 28 deletions(-)

diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index c1961761311d..3763a9657928 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -6,10 +6,12 @@
 #include <linux/sched.h>
 #include <linux/cgroup.h>
 
-__printf(4, 5)
-struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),
+__printf(6, 7)
+struct task_struct *_kthread_create_on_node(int (*threadfn)(void *data),
 					   void *data,
 					   int node,
+					   struct lock_class_key *exited_key,
+					   struct lock_class_key *parked_key,
 					   const char namefmt[], ...);
 
 /**
@@ -25,12 +27,27 @@ struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),
  */
 #define kthread_create(threadfn, data, namefmt, arg...) \
 	kthread_create_on_node(threadfn, data, NUMA_NO_NODE, namefmt, ##arg)
+#define kthread_create_on_node(threadfn, data, node, namefmt, arg...)	\
+({									\
+	static struct lock_class_key __exited_key, __parked_key;	\
+	_kthread_create_on_node(threadfn, data, node, &__exited_key,	\
+			       &__parked_key, namefmt, ##arg);		\
+})
 
 
-struct task_struct *kthread_create_on_cpu(int (*threadfn)(void *data),
+struct task_struct *_kthread_create_on_cpu(int (*threadfn)(void *data),
 					  void *data,
 					  unsigned int cpu,
+					  struct lock_class_key *exited_key,
+					  struct lock_class_key *parked_key,
 					  const char *namefmt);
+#define kthread_create_on_cpu(threadfn, data, cpu, namefmt)		\
+({									\
+	static struct lock_class_key __exited_key, __parked_key;	\
+	_kthread_create_on_cpu(threadfn, data, cpu, &__exited_key,\
+			       &__parked_key, namefmt);			\
+})
+
 
 /**
  * kthread_run - create and wake a thread.
@@ -171,13 +188,30 @@ extern void __kthread_init_worker(struct kthread_worker *worker,
 
 int kthread_worker_fn(void *worker_ptr);
 
-__printf(2, 3)
+__printf(4, 5)
 struct kthread_worker *
-kthread_create_worker(unsigned int flags, const char namefmt[], ...);
+_kthread_create_worker(unsigned int flags,
+		       struct lock_class_key *exited_key,
+		       struct lock_class_key *parked_key,
+		       const char namefmt[], ...);
+#define kthread_create_worker(flags, namefmt...)				\
+({									\
+	static struct lock_class_key __exited_key, __parked_key;	\
+	_kthread_create_worker(flags, &__exited_key, &__parked_key,	\
+			       ##namefmt);				\
+})
 
-__printf(3, 4) struct kthread_worker *
-kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+__printf(5, 6) struct kthread_worker *
+_kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+		       struct lock_class_key *exited_key,
+		       struct lock_class_key *parked_key,
 			     const char namefmt[], ...);
+#define kthread_create_worker_on_cpu(cpu, flags, namefmt...)	\
+({									\
+	static struct lock_class_key __exited_key, __parked_key;	\
+	_kthread_create_worker(cpu, flags, &__exited_key, &__parked_key,\
+			       ##namefmt);				\
+})
 
 bool kthread_queue_work(struct kthread_worker *worker,
 			struct kthread_work *work);
diff --git a/kernel/kthread.c b/kernel/kthread.c
index cd50e99202b0..9022806818fc 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -32,6 +32,7 @@ struct kthread_create_info
 	int (*threadfn)(void *data);
 	void *data;
 	int node;
+	struct lock_class_key *exited_key, *parked_key;
 
 	/* Result passed back to kthread_create() from kthreadd. */
 	struct task_struct *result;
@@ -221,8 +222,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",
+			create->exited_key, 0);
+	init_completion_map(&self->exited, &self->exited.map.map);
+	lockdep_init_map_crosslock(&self->parked.map.map,
+			"(kthread completion)->parked",
+			create->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 */
@@ -272,9 +282,11 @@ static void create_kthread(struct kthread_create_info *create)
 	}
 }
 
-static __printf(4, 0)
+static __printf(6, 0)
 struct task_struct *__kthread_create_on_node(int (*threadfn)(void *data),
 						    void *data, int node,
+						    struct lock_class_key *exited_key,
+						    struct lock_class_key *parked_key,
 						    const char namefmt[],
 						    va_list args)
 {
@@ -289,6 +301,8 @@ struct task_struct *__kthread_create_on_node(int (*threadfn)(void *data),
 	create->data = data;
 	create->node = node;
 	create->done = &done;
+	create->exited_key = exited_key;
+	create->parked_key = parked_key;
 
 	spin_lock(&kthread_create_lock);
 	list_add_tail(&create->list, &kthread_create_list);
@@ -353,21 +367,24 @@ struct task_struct *__kthread_create_on_node(int (*threadfn)(void *data),
  *
  * Returns a task_struct or ERR_PTR(-ENOMEM) or ERR_PTR(-EINTR).
  */
-struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),
-					   void *data, int node,
-					   const char namefmt[],
-					   ...)
+struct task_struct *_kthread_create_on_node(int (*threadfn)(void *data),
+					    void *data, int node,
+					    struct lock_class_key *exited_key,
+					    struct lock_class_key *parked_key,
+					    const char namefmt[],
+					    ...)
 {
 	struct task_struct *task;
 	va_list args;
 
 	va_start(args, namefmt);
-	task = __kthread_create_on_node(threadfn, data, node, namefmt, args);
+	task = __kthread_create_on_node(threadfn, data, node,
+					exited_key, parked_key, namefmt, args);
 	va_end(args);
 
 	return task;
 }
-EXPORT_SYMBOL(kthread_create_on_node);
+EXPORT_SYMBOL(_kthread_create_on_node);
 
 static void __kthread_bind_mask(struct task_struct *p, const struct cpumask *mask, long state)
 {
@@ -421,14 +438,16 @@ EXPORT_SYMBOL(kthread_bind);
  * Description: This helper function creates and names a kernel thread
  * The thread will be woken and put into park mode.
  */
-struct task_struct *kthread_create_on_cpu(int (*threadfn)(void *data),
+struct task_struct *_kthread_create_on_cpu(int (*threadfn)(void *data),
 					  void *data, unsigned int cpu,
+					  struct lock_class_key *exited_key,
+					  struct lock_class_key *parked_key,
 					  const char *namefmt)
 {
 	struct task_struct *p;
 
-	p = kthread_create_on_node(threadfn, data, cpu_to_node(cpu), namefmt,
-				   cpu);
+	p = _kthread_create_on_node(threadfn, data, cpu_to_node(cpu),
+				    exited_key, parked_key, namefmt, cpu);
 	if (IS_ERR(p))
 		return p;
 	kthread_bind(p, cpu);
@@ -649,8 +668,10 @@ int kthread_worker_fn(void *worker_ptr)
 }
 EXPORT_SYMBOL_GPL(kthread_worker_fn);
 
-static __printf(3, 0) struct kthread_worker *
+static __printf(5, 0) struct kthread_worker *
 __kthread_create_worker(int cpu, unsigned int flags,
+			struct lock_class_key *exited_key,
+			struct lock_class_key *parked_key,
 			const char namefmt[], va_list args)
 {
 	struct kthread_worker *worker;
@@ -666,8 +687,8 @@ __kthread_create_worker(int cpu, unsigned int flags,
 	if (cpu >= 0)
 		node = cpu_to_node(cpu);
 
-	task = __kthread_create_on_node(kthread_worker_fn, worker,
-						node, namefmt, args);
+	task = __kthread_create_on_node(kthread_worker_fn, worker, node,
+					exited_key, parked_key, namefmt, args);
 	if (IS_ERR(task))
 		goto fail_task;
 
@@ -694,18 +715,22 @@ __kthread_create_worker(int cpu, unsigned int flags,
  * when the worker was SIGKILLed.
  */
 struct kthread_worker *
-kthread_create_worker(unsigned int flags, const char namefmt[], ...)
+_kthread_create_worker(unsigned int flags,
+		       struct lock_class_key *exited_key,
+		       struct lock_class_key *parked_key,
+		       const char namefmt[], ...)
 {
 	struct kthread_worker *worker;
 	va_list args;
 
 	va_start(args, namefmt);
-	worker = __kthread_create_worker(-1, flags, namefmt, args);
+	worker = __kthread_create_worker(-1, flags, exited_key, parked_key,
+					 namefmt, args);
 	va_end(args);
 
 	return worker;
 }
-EXPORT_SYMBOL(kthread_create_worker);
+EXPORT_SYMBOL(_kthread_create_worker);
 
 /**
  * kthread_create_worker_on_cpu - create a kthread worker and bind it
@@ -725,19 +750,22 @@ EXPORT_SYMBOL(kthread_create_worker);
  * when the worker was SIGKILLed.
  */
 struct kthread_worker *
-kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+_kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+			      struct lock_class_key *exited_key,
+			      struct lock_class_key *parked_key,
 			     const char namefmt[], ...)
 {
 	struct kthread_worker *worker;
 	va_list args;
 
 	va_start(args, namefmt);
-	worker = __kthread_create_worker(cpu, flags, namefmt, args);
+	worker = __kthread_create_worker(cpu, flags, exited_key, parked_key,
+					 namefmt, args);
 	va_end(args);
 
 	return worker;
 }
-EXPORT_SYMBOL(kthread_create_worker_on_cpu);
+EXPORT_SYMBOL(_kthread_create_worker_on_cpu);
 
 /*
  * Returns true when the work could not be queued at the moment.
-- 
2.15.0

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

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
  2017-11-29  9:46 [PATCH 1/2] lockdep: finer-grained completion key for kthread Daniel Vetter
@ 2017-11-29  9:46 ` Daniel Vetter
  2017-11-29  9:57   ` Chris Wilson
  2017-11-29 10:03 ` ✗ Fi.CI.BAT: failure for series starting with [1/2] lockdep: finer-grained completion key for kthread Patchwork
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 19+ messages in thread
From: Daniel Vetter @ 2017-11-29  9:46 UTC (permalink / raw)
  To: Intel Graphics Development; +Cc: Daniel Vetter, 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

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
  2017-11-29  9:46 ` [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS Daniel Vetter
@ 2017-11-29  9:57   ` Chris Wilson
  2017-11-29 10:01     ` Chris Wilson
  0 siblings, 1 reply; 19+ messages in thread
From: Chris Wilson @ 2017-11-29  9:57 UTC (permalink / raw)
  To: Intel Graphics Development; +Cc: Daniel Vetter, Daniel Vetter

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
  2017-11-29  9:57   ` Chris Wilson
@ 2017-11-29 10:01     ` Chris Wilson
  2017-11-29 10:27       ` Daniel Vetter
  0 siblings, 1 reply; 19+ messages in thread
From: Chris Wilson @ 2017-11-29 10:01 UTC (permalink / raw)
  To: Intel Graphics Development; +Cc: Daniel Vetter, Daniel Vetter

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* ✗ Fi.CI.BAT: failure for series starting with [1/2] lockdep: finer-grained completion key for kthread
  2017-11-29  9:46 [PATCH 1/2] lockdep: finer-grained completion key for kthread Daniel Vetter
  2017-11-29  9:46 ` [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS Daniel Vetter
@ 2017-11-29 10:03 ` Patchwork
  2017-11-29 11:29 ` [PATCH] " Daniel Vetter
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 19+ messages in thread
From: Patchwork @ 2017-11-29 10:03 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

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

== Summary ==

  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CHK     include/generated/bounds.h
  CHK     include/generated/timeconst.h
  CHK     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  DESCEND  objtool
  CHK     scripts/mod/devicetable-offsets.h
  CHK     include/generated/compile.h
  CHK     kernel/config_data.h
  CC [M]  drivers/thermal/intel_powerclamp.o
In file included from drivers/thermal/intel_powerclamp.c:45:0:
drivers/thermal/intel_powerclamp.c: In function ‘start_power_clamp_worker’:
./include/linux/kthread.h:212:52: error: passing argument 4 of ‘_kthread_create_worker’ from incompatible pointer type [-Werror=incompatible-pointer-types]
  _kthread_create_worker(cpu, flags, &__exited_key, &__parked_key,\
                                                    ^
drivers/thermal/intel_powerclamp.c:497:11: note: in expansion of macro ‘kthread_create_worker_on_cpu’
  worker = kthread_create_worker_on_cpu(cpu, 0, "kidle_inject/%ld", cpu);
           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
./include/linux/kthread.h:193:1: note: expected ‘const char *’ but argument is of type ‘struct lock_class_key *’
 _kthread_create_worker(unsigned int flags,
 ^~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
scripts/Makefile.build:316: recipe for target 'drivers/thermal/intel_powerclamp.o' failed
make[2]: *** [drivers/thermal/intel_powerclamp.o] Error 1
scripts/Makefile.build:569: recipe for target 'drivers/thermal' failed
make[1]: *** [drivers/thermal] Error 2
Makefile:1012: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
  2017-11-29 10:01     ` Chris Wilson
@ 2017-11-29 10:27       ` Daniel Vetter
  0 siblings, 0 replies; 19+ messages in thread
From: Daniel Vetter @ 2017-11-29 10:27 UTC (permalink / raw)
  To: Chris Wilson; +Cc: Daniel Vetter, Intel Graphics Development, 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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH] lockdep: finer-grained completion key for kthread
  2017-11-29  9:46 [PATCH 1/2] lockdep: finer-grained completion key for kthread Daniel Vetter
  2017-11-29  9:46 ` [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS Daniel Vetter
  2017-11-29 10:03 ` ✗ Fi.CI.BAT: failure for series starting with [1/2] lockdep: finer-grained completion key for kthread Patchwork
@ 2017-11-29 11:29 ` Daniel Vetter
  2017-11-29 11:59 ` ✓ Fi.CI.BAT: success for series starting with lockdep: finer-grained completion key for kthread (rev2) Patchwork
  2017-11-29 13:30 ` ✓ Fi.CI.IGT: " Patchwork
  4 siblings, 0 replies; 19+ messages in thread
From: Daniel Vetter @ 2017-11-29 11:29 UTC (permalink / raw)
  To: Intel Graphics Development; +Cc: Daniel Vetter, 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)

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@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>
---
 include/linux/kthread.h | 48 ++++++++++++++++++++++++++++-----
 kernel/kthread.c        | 70 ++++++++++++++++++++++++++++++++++---------------
 2 files changed, 90 insertions(+), 28 deletions(-)

diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index c1961761311d..7a9463f0be5c 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -6,10 +6,12 @@
 #include <linux/sched.h>
 #include <linux/cgroup.h>
 
-__printf(4, 5)
-struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),
+__printf(6, 7)
+struct task_struct *_kthread_create_on_node(int (*threadfn)(void *data),
 					   void *data,
 					   int node,
+					   struct lock_class_key *exited_key,
+					   struct lock_class_key *parked_key,
 					   const char namefmt[], ...);
 
 /**
@@ -25,12 +27,27 @@ struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),
  */
 #define kthread_create(threadfn, data, namefmt, arg...) \
 	kthread_create_on_node(threadfn, data, NUMA_NO_NODE, namefmt, ##arg)
+#define kthread_create_on_node(threadfn, data, node, namefmt, arg...)	\
+({									\
+	static struct lock_class_key __exited_key, __parked_key;	\
+	_kthread_create_on_node(threadfn, data, node, &__exited_key,	\
+			       &__parked_key, namefmt, ##arg);		\
+})
 
 
-struct task_struct *kthread_create_on_cpu(int (*threadfn)(void *data),
+struct task_struct *_kthread_create_on_cpu(int (*threadfn)(void *data),
 					  void *data,
 					  unsigned int cpu,
+					  struct lock_class_key *exited_key,
+					  struct lock_class_key *parked_key,
 					  const char *namefmt);
+#define kthread_create_on_cpu(threadfn, data, cpu, namefmt)		\
+({									\
+	static struct lock_class_key __exited_key, __parked_key;	\
+	_kthread_create_on_cpu(threadfn, data, cpu, &__exited_key,\
+			       &__parked_key, namefmt);			\
+})
+
 
 /**
  * kthread_run - create and wake a thread.
@@ -171,13 +188,30 @@ extern void __kthread_init_worker(struct kthread_worker *worker,
 
 int kthread_worker_fn(void *worker_ptr);
 
-__printf(2, 3)
+__printf(4, 5)
 struct kthread_worker *
-kthread_create_worker(unsigned int flags, const char namefmt[], ...);
+_kthread_create_worker(unsigned int flags,
+		       struct lock_class_key *exited_key,
+		       struct lock_class_key *parked_key,
+		       const char namefmt[], ...);
+#define kthread_create_worker(flags, namefmt...)				\
+({									\
+	static struct lock_class_key __exited_key, __parked_key;	\
+	_kthread_create_worker(flags, &__exited_key, &__parked_key,	\
+			       ##namefmt);				\
+})
 
-__printf(3, 4) struct kthread_worker *
-kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+__printf(5, 6) struct kthread_worker *
+_kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+		       struct lock_class_key *exited_key,
+		       struct lock_class_key *parked_key,
 			     const char namefmt[], ...);
+#define kthread_create_worker_on_cpu(cpu, flags, namefmt...)	\
+({									\
+	static struct lock_class_key __exited_key, __parked_key;	\
+	_kthread_create_worker_on_cpu(cpu, flags, &__exited_key, &__parked_key,\
+			       ##namefmt);				\
+})
 
 bool kthread_queue_work(struct kthread_worker *worker,
 			struct kthread_work *work);
diff --git a/kernel/kthread.c b/kernel/kthread.c
index cd50e99202b0..9022806818fc 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -32,6 +32,7 @@ struct kthread_create_info
 	int (*threadfn)(void *data);
 	void *data;
 	int node;
+	struct lock_class_key *exited_key, *parked_key;
 
 	/* Result passed back to kthread_create() from kthreadd. */
 	struct task_struct *result;
@@ -221,8 +222,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",
+			create->exited_key, 0);
+	init_completion_map(&self->exited, &self->exited.map.map);
+	lockdep_init_map_crosslock(&self->parked.map.map,
+			"(kthread completion)->parked",
+			create->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 */
@@ -272,9 +282,11 @@ static void create_kthread(struct kthread_create_info *create)
 	}
 }
 
-static __printf(4, 0)
+static __printf(6, 0)
 struct task_struct *__kthread_create_on_node(int (*threadfn)(void *data),
 						    void *data, int node,
+						    struct lock_class_key *exited_key,
+						    struct lock_class_key *parked_key,
 						    const char namefmt[],
 						    va_list args)
 {
@@ -289,6 +301,8 @@ struct task_struct *__kthread_create_on_node(int (*threadfn)(void *data),
 	create->data = data;
 	create->node = node;
 	create->done = &done;
+	create->exited_key = exited_key;
+	create->parked_key = parked_key;
 
 	spin_lock(&kthread_create_lock);
 	list_add_tail(&create->list, &kthread_create_list);
@@ -353,21 +367,24 @@ struct task_struct *__kthread_create_on_node(int (*threadfn)(void *data),
  *
  * Returns a task_struct or ERR_PTR(-ENOMEM) or ERR_PTR(-EINTR).
  */
-struct task_struct *kthread_create_on_node(int (*threadfn)(void *data),
-					   void *data, int node,
-					   const char namefmt[],
-					   ...)
+struct task_struct *_kthread_create_on_node(int (*threadfn)(void *data),
+					    void *data, int node,
+					    struct lock_class_key *exited_key,
+					    struct lock_class_key *parked_key,
+					    const char namefmt[],
+					    ...)
 {
 	struct task_struct *task;
 	va_list args;
 
 	va_start(args, namefmt);
-	task = __kthread_create_on_node(threadfn, data, node, namefmt, args);
+	task = __kthread_create_on_node(threadfn, data, node,
+					exited_key, parked_key, namefmt, args);
 	va_end(args);
 
 	return task;
 }
-EXPORT_SYMBOL(kthread_create_on_node);
+EXPORT_SYMBOL(_kthread_create_on_node);
 
 static void __kthread_bind_mask(struct task_struct *p, const struct cpumask *mask, long state)
 {
@@ -421,14 +438,16 @@ EXPORT_SYMBOL(kthread_bind);
  * Description: This helper function creates and names a kernel thread
  * The thread will be woken and put into park mode.
  */
-struct task_struct *kthread_create_on_cpu(int (*threadfn)(void *data),
+struct task_struct *_kthread_create_on_cpu(int (*threadfn)(void *data),
 					  void *data, unsigned int cpu,
+					  struct lock_class_key *exited_key,
+					  struct lock_class_key *parked_key,
 					  const char *namefmt)
 {
 	struct task_struct *p;
 
-	p = kthread_create_on_node(threadfn, data, cpu_to_node(cpu), namefmt,
-				   cpu);
+	p = _kthread_create_on_node(threadfn, data, cpu_to_node(cpu),
+				    exited_key, parked_key, namefmt, cpu);
 	if (IS_ERR(p))
 		return p;
 	kthread_bind(p, cpu);
@@ -649,8 +668,10 @@ int kthread_worker_fn(void *worker_ptr)
 }
 EXPORT_SYMBOL_GPL(kthread_worker_fn);
 
-static __printf(3, 0) struct kthread_worker *
+static __printf(5, 0) struct kthread_worker *
 __kthread_create_worker(int cpu, unsigned int flags,
+			struct lock_class_key *exited_key,
+			struct lock_class_key *parked_key,
 			const char namefmt[], va_list args)
 {
 	struct kthread_worker *worker;
@@ -666,8 +687,8 @@ __kthread_create_worker(int cpu, unsigned int flags,
 	if (cpu >= 0)
 		node = cpu_to_node(cpu);
 
-	task = __kthread_create_on_node(kthread_worker_fn, worker,
-						node, namefmt, args);
+	task = __kthread_create_on_node(kthread_worker_fn, worker, node,
+					exited_key, parked_key, namefmt, args);
 	if (IS_ERR(task))
 		goto fail_task;
 
@@ -694,18 +715,22 @@ __kthread_create_worker(int cpu, unsigned int flags,
  * when the worker was SIGKILLed.
  */
 struct kthread_worker *
-kthread_create_worker(unsigned int flags, const char namefmt[], ...)
+_kthread_create_worker(unsigned int flags,
+		       struct lock_class_key *exited_key,
+		       struct lock_class_key *parked_key,
+		       const char namefmt[], ...)
 {
 	struct kthread_worker *worker;
 	va_list args;
 
 	va_start(args, namefmt);
-	worker = __kthread_create_worker(-1, flags, namefmt, args);
+	worker = __kthread_create_worker(-1, flags, exited_key, parked_key,
+					 namefmt, args);
 	va_end(args);
 
 	return worker;
 }
-EXPORT_SYMBOL(kthread_create_worker);
+EXPORT_SYMBOL(_kthread_create_worker);
 
 /**
  * kthread_create_worker_on_cpu - create a kthread worker and bind it
@@ -725,19 +750,22 @@ EXPORT_SYMBOL(kthread_create_worker);
  * when the worker was SIGKILLed.
  */
 struct kthread_worker *
-kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+_kthread_create_worker_on_cpu(int cpu, unsigned int flags,
+			      struct lock_class_key *exited_key,
+			      struct lock_class_key *parked_key,
 			     const char namefmt[], ...)
 {
 	struct kthread_worker *worker;
 	va_list args;
 
 	va_start(args, namefmt);
-	worker = __kthread_create_worker(cpu, flags, namefmt, args);
+	worker = __kthread_create_worker(cpu, flags, exited_key, parked_key,
+					 namefmt, args);
 	va_end(args);
 
 	return worker;
 }
-EXPORT_SYMBOL(kthread_create_worker_on_cpu);
+EXPORT_SYMBOL(_kthread_create_worker_on_cpu);
 
 /*
  * Returns true when the work could not be queued at the moment.
-- 
2.15.0

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

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* ✓ Fi.CI.BAT: success for series starting with lockdep: finer-grained completion key for kthread (rev2)
  2017-11-29  9:46 [PATCH 1/2] lockdep: finer-grained completion key for kthread Daniel Vetter
                   ` (2 preceding siblings ...)
  2017-11-29 11:29 ` [PATCH] " Daniel Vetter
@ 2017-11-29 11:59 ` Patchwork
  2017-11-29 16:36   ` Daniel Vetter
  2017-11-29 13:30 ` ✓ Fi.CI.IGT: " Patchwork
  4 siblings, 1 reply; 19+ messages in thread
From: Patchwork @ 2017-11-29 11:59 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: series starting with lockdep: finer-grained completion key for kthread (rev2)
URL   : https://patchwork.freedesktop.org/series/34603/
State : success

== Summary ==

Series 34603v2 series starting with lockdep: finer-grained completion key for kthread
https://patchwork.freedesktop.org/api/1.0/series/34603/revisions/2/mbox/

Test debugfs_test:
        Subgroup read_all_entries:
                dmesg-warn -> PASS       (fi-bdw-gvtdvm) fdo#103938 +1
Test kms_pipe_crc_basic:
        Subgroup read-crc-pipe-b:
                fail       -> PASS       (fi-skl-6700k) fdo#103191
        Subgroup suspend-read-crc-pipe-b:
                incomplete -> PASS       (fi-snb-2520m) fdo#103713

fdo#103938 https://bugs.freedesktop.org/show_bug.cgi?id=103938
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

fi-bdw-5557u     total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  time:444s
fi-bdw-gvtdvm    total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  time:445s
fi-blb-e6850     total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  time:384s
fi-bsw-n3050     total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  time:516s
fi-bwr-2160      total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 time:283s
fi-bxt-dsi       total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  time:505s
fi-bxt-j4205     total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  time:508s
fi-byt-j1900     total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  time:492s
fi-byt-n2820     total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  time:474s
fi-elk-e7500     total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  time:430s
fi-gdg-551       total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 time:272s
fi-glk-1         total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  time:540s
fi-hsw-4770      total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:363s
fi-hsw-4770r     total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  time:264s
fi-ivb-3520m     total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  time:486s
fi-kbl-7500u     total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  time:484s
fi-kbl-7560u     total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  time:528s
fi-kbl-7567u     total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:478s
fi-kbl-r         total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:534s
fi-pnv-d510      total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  time:598s
fi-skl-6260u     total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:463s
fi-skl-6600u     total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:540s
fi-skl-6700hq    total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:569s
fi-skl-6700k     total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  time:521s
fi-skl-6770hq    total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:503s
fi-skl-gvtdvm    total:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  time:453s
fi-snb-2520m     total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  time:557s
fi-snb-2600      total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  time:419s
Blacklisted hosts:
fi-cfl-s2        total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:611s

c544c30501259c15ced047e547e787d546c24a43 drm-tip: 2017y-11m-29d-08h-19m-47s UTC integration manifest
c7410e9c26c2 lockdep: Up MAX_LOCKDEP_CHAINS
68049d7ef928 lockdep: finer-grained completion key for kthread

== Logs ==

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* ✓ Fi.CI.IGT: success for series starting with lockdep: finer-grained completion key for kthread (rev2)
  2017-11-29  9:46 [PATCH 1/2] lockdep: finer-grained completion key for kthread Daniel Vetter
                   ` (3 preceding siblings ...)
  2017-11-29 11:59 ` ✓ Fi.CI.BAT: success for series starting with lockdep: finer-grained completion key for kthread (rev2) Patchwork
@ 2017-11-29 13:30 ` Patchwork
  4 siblings, 0 replies; 19+ messages in thread
From: Patchwork @ 2017-11-29 13:30 UTC (permalink / raw)
  To: Daniel Vetter; +Cc: intel-gfx

== Series Details ==

Series: series starting with lockdep: finer-grained completion key for kthread (rev2)
URL   : https://patchwork.freedesktop.org/series/34603/
State : success

== Summary ==

Blacklisted hosts:
shard-apl        total:2476 pass:1560 dwarn:10  dfail:8   fail:14  skip:879 time:12836s
shard-hsw        total:2661 pass:1534 dwarn:1   dfail:0   fail:9   skip:1117 time:9575s
shard-kbl        total:2448 pass:1601 dwarn:49  dfail:11  fail:17  skip:764 time:9121s
shard-snb        total:2539 pass:1236 dwarn:8   dfail:8   fail:6   skip:1277 time:7128s

== Logs ==

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: ✓ Fi.CI.BAT: success for series starting with lockdep: finer-grained completion key for kthread (rev2)
  2017-11-29 11:59 ` ✓ Fi.CI.BAT: success for series starting with lockdep: finer-grained completion key for kthread (rev2) Patchwork
@ 2017-11-29 16:36   ` Daniel Vetter
  0 siblings, 0 replies; 19+ messages in thread
From: Daniel Vetter @ 2017-11-29 16:36 UTC (permalink / raw)
  To: intel-gfx; +Cc: Daniel Vetter

On Wed, Nov 29, 2017 at 11:59:23AM -0000, Patchwork wrote:
> == Series Details ==
> 
> Series: series starting with lockdep: finer-grained completion key for kthread (rev2)
> URL   : https://patchwork.freedesktop.org/series/34603/
> State : success
> 
> == Summary ==
> 
> Series 34603v2 series starting with lockdep: finer-grained completion key for kthread
> https://patchwork.freedesktop.org/api/1.0/series/34603/revisions/2/mbox/
> 
> Test debugfs_test:
>         Subgroup read_all_entries:
>                 dmesg-warn -> PASS       (fi-bdw-gvtdvm) fdo#103938 +1
> Test kms_pipe_crc_basic:
>         Subgroup read-crc-pipe-b:
>                 fail       -> PASS       (fi-skl-6700k) fdo#103191
>         Subgroup suspend-read-crc-pipe-b:
>                 incomplete -> PASS       (fi-snb-2520m) fdo#103713
> 
> fdo#103938 https://bugs.freedesktop.org/show_bug.cgi?id=103938
> fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
> fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713

This indeed seems to fix the perf_pmu lockdep splat, so put into
topic/core-for-CI with Chris' and Tvrtko's acks.
-Daniel

> 
> fi-bdw-5557u     total:288  pass:267  dwarn:0   dfail:0   fail:0   skip:21  time:444s
> fi-bdw-gvtdvm    total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  time:445s
> fi-blb-e6850     total:288  pass:223  dwarn:1   dfail:0   fail:0   skip:64  time:384s
> fi-bsw-n3050     total:288  pass:242  dwarn:0   dfail:0   fail:0   skip:46  time:516s
> fi-bwr-2160      total:288  pass:183  dwarn:0   dfail:0   fail:0   skip:105 time:283s
> fi-bxt-dsi       total:288  pass:258  dwarn:0   dfail:0   fail:0   skip:30  time:505s
> fi-bxt-j4205     total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  time:508s
> fi-byt-j1900     total:288  pass:253  dwarn:0   dfail:0   fail:0   skip:35  time:492s
> fi-byt-n2820     total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  time:474s
> fi-elk-e7500     total:288  pass:229  dwarn:0   dfail:0   fail:0   skip:59  time:430s
> fi-gdg-551       total:288  pass:178  dwarn:1   dfail:0   fail:1   skip:108 time:272s
> fi-glk-1         total:288  pass:260  dwarn:0   dfail:0   fail:0   skip:28  time:540s
> fi-hsw-4770      total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:363s
> fi-hsw-4770r     total:288  pass:224  dwarn:0   dfail:0   fail:0   skip:64  time:264s
> fi-ivb-3520m     total:288  pass:259  dwarn:0   dfail:0   fail:0   skip:29  time:486s
> fi-kbl-7500u     total:288  pass:263  dwarn:1   dfail:0   fail:0   skip:24  time:484s
> fi-kbl-7560u     total:288  pass:269  dwarn:0   dfail:0   fail:0   skip:19  time:528s
> fi-kbl-7567u     total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:478s
> fi-kbl-r         total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:534s
> fi-pnv-d510      total:288  pass:222  dwarn:1   dfail:0   fail:0   skip:65  time:598s
> fi-skl-6260u     total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:463s
> fi-skl-6600u     total:288  pass:261  dwarn:0   dfail:0   fail:0   skip:27  time:540s
> fi-skl-6700hq    total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:569s
> fi-skl-6700k     total:288  pass:264  dwarn:0   dfail:0   fail:0   skip:24  time:521s
> fi-skl-6770hq    total:288  pass:268  dwarn:0   dfail:0   fail:0   skip:20  time:503s
> fi-skl-gvtdvm    total:288  pass:265  dwarn:0   dfail:0   fail:0   skip:23  time:453s
> fi-snb-2520m     total:288  pass:249  dwarn:0   dfail:0   fail:0   skip:39  time:557s
> fi-snb-2600      total:288  pass:248  dwarn:0   dfail:0   fail:0   skip:40  time:419s
> Blacklisted hosts:
> fi-cfl-s2        total:288  pass:262  dwarn:0   dfail:0   fail:0   skip:26  time:611s
> 
> c544c30501259c15ced047e547e787d546c24a43 drm-tip: 2017y-11m-29d-08h-19m-47s UTC integration manifest
> c7410e9c26c2 lockdep: Up MAX_LOCKDEP_CHAINS
> 68049d7ef928 lockdep: finer-grained completion key for kthread
> 
> == Logs ==
> 
> For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_7338/

-- 
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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
  2017-11-30  7:47     ` Peter Zijlstra
@ 2017-11-30  8:08       ` Daniel Vetter
  -1 siblings, 0 replies; 19+ messages in thread
From: Daniel Vetter @ 2017-11-30  8:08 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Daniel Vetter, LKML, Ingo Molnar, Thomas Gleixner,
	Intel Graphics Development, Tejun Heo, Kees Cook, Tvrtko Ursulin,
	Marta Lofstedt, 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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
@ 2017-11-30  8:08       ` Daniel Vetter
  0 siblings, 0 replies; 19+ messages in thread
From: Daniel Vetter @ 2017-11-30  8:08 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Kees Cook, Daniel Vetter, Intel Graphics Development, LKML,
	Ingo Molnar, Tejun Heo, Daniel Vetter, Thomas Gleixner

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
  2017-11-29 15:41   ` Daniel Vetter
@ 2017-11-30  7:47     ` Peter Zijlstra
  -1 siblings, 0 replies; 19+ messages in thread
From: Peter Zijlstra @ 2017-11-30  7:47 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: LKML, Ingo Molnar, Thomas Gleixner, Intel Graphics Development,
	Tejun Heo, Kees Cook, Tvrtko Ursulin, Marta Lofstedt,
	Daniel Vetter

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).

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
@ 2017-11-30  7:47     ` Peter Zijlstra
  0 siblings, 0 replies; 19+ messages in thread
From: Peter Zijlstra @ 2017-11-30  7:47 UTC (permalink / raw)
  To: Daniel Vetter
  Cc: Kees Cook, Intel Graphics Development, LKML, Ingo Molnar,
	Tejun Heo, Daniel Vetter, Thomas Gleixner

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
  2017-11-29 15:41 [PATCH 0/2] lockdep cross-release fallout from -rc1 Daniel Vetter
@ 2017-11-29 15:41   ` Daniel Vetter
  0 siblings, 0 replies; 19+ messages in thread
From: Daniel Vetter @ 2017-11-29 15:41 UTC (permalink / raw)
  To: LKML, Peter Zijlstra, Ingo Molnar, Thomas Gleixner
  Cc: Intel Graphics Development, Tejun Heo, Kees Cook, Daniel Vetter,
	Tvrtko Ursulin, Marta Lofstedt, 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

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
@ 2017-11-29 15:41   ` Daniel Vetter
  0 siblings, 0 replies; 19+ messages in thread
From: Daniel Vetter @ 2017-11-29 15:41 UTC (permalink / raw)
  To: LKML, Peter Zijlstra, Ingo Molnar, Thomas Gleixner
  Cc: Kees Cook, Daniel Vetter, Intel Graphics Development, Tejun Heo,
	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

^ permalink raw reply related	[flat|nested] 19+ messages in thread

* Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
  2017-11-28 17:22   ` Chris Wilson
@ 2017-11-29  8:02     ` Daniel Vetter
  0 siblings, 0 replies; 19+ messages in thread
From: Daniel Vetter @ 2017-11-29  8:02 UTC (permalink / raw)
  To: Chris Wilson; +Cc: Daniel Vetter, Intel Graphics Development, 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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* Re: [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
  2017-11-28 17:07 ` [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS Daniel Vetter
@ 2017-11-28 17:22   ` Chris Wilson
  2017-11-29  8:02     ` Daniel Vetter
  0 siblings, 1 reply; 19+ messages in thread
From: Chris Wilson @ 2017-11-28 17:22 UTC (permalink / raw)
  To: Intel Graphics Development; +Cc: Daniel Vetter, Daniel Vetter

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

^ permalink raw reply	[flat|nested] 19+ messages in thread

* [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS
  2017-11-28 17:07 [PATCH 1/2] lockdep: finer-grained completion key for kthread Daniel Vetter
@ 2017-11-28 17:07 ` Daniel Vetter
  2017-11-28 17:22   ` Chris Wilson
  0 siblings, 1 reply; 19+ messages in thread
From: Daniel Vetter @ 2017-11-28 17:07 UTC (permalink / raw)
  To: Intel Graphics Development; +Cc: Daniel Vetter, 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

^ permalink raw reply related	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2017-11-30  8:08 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-11-29  9:46 [PATCH 1/2] lockdep: finer-grained completion key for kthread Daniel Vetter
2017-11-29  9:46 ` [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS Daniel Vetter
2017-11-29  9:57   ` Chris Wilson
2017-11-29 10:01     ` Chris Wilson
2017-11-29 10:27       ` Daniel Vetter
2017-11-29 10:03 ` ✗ Fi.CI.BAT: failure for series starting with [1/2] lockdep: finer-grained completion key for kthread Patchwork
2017-11-29 11:29 ` [PATCH] " Daniel Vetter
2017-11-29 11:59 ` ✓ Fi.CI.BAT: success for series starting with lockdep: finer-grained completion key for kthread (rev2) Patchwork
2017-11-29 16:36   ` Daniel Vetter
2017-11-29 13:30 ` ✓ Fi.CI.IGT: " Patchwork
  -- strict thread matches above, loose matches on Subject: below --
2017-11-29 15:41 [PATCH 0/2] lockdep cross-release fallout from -rc1 Daniel Vetter
2017-11-29 15:41 ` [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS Daniel Vetter
2017-11-29 15:41   ` Daniel Vetter
2017-11-30  7:47   ` Peter Zijlstra
2017-11-30  7:47     ` Peter Zijlstra
2017-11-30  8:08     ` Daniel Vetter
2017-11-30  8:08       ` Daniel Vetter
2017-11-28 17:07 [PATCH 1/2] lockdep: finer-grained completion key for kthread Daniel Vetter
2017-11-28 17:07 ` [PATCH 2/2] lockdep: Up MAX_LOCKDEP_CHAINS Daniel Vetter
2017-11-28 17:22   ` Chris Wilson
2017-11-29  8:02     ` Daniel Vetter

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.