mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com,
	stern@rowland.harvard.edu
Subject: Re: [PATCH 1/2] lockdep: lock_set_lock_cmp_fn()
Date: Mon, 20 Feb 2023 16:09:33 +0100	[thread overview]
Message-ID: <Y/ONLYqVrWPFyboF@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20230218032117.2372071-2-kent.overstreet@linux.dev>

On Fri, Feb 17, 2023 at 10:21:16PM -0500, Kent Overstreet wrote:

> @@ -2982,6 +2989,10 @@ print_deadlock_bug(struct task_struct *curr, struct held_lock *prev,
>  	pr_warn("\nbut task is already holding lock:\n");
>  	print_lock(prev);
>  
> +	if (class->cmp_fn)
> +		pr_warn("and the lock comparison function returns %i:\n",
> +			class->cmp_fn(prev->instance, next->instance));
> +

Please, use {} for any actual multi-line.

But is this sufficient data to debug a splat? Given an inversion on this
class, we'll get something like:

 A
 A -a
 A -b

vs

 A
 A c

which is I suppose sufficient to say that A messed up, but not much
more. With subclasses we would've gotten

 A/0
 A/1
 A/2

vs

 A/2
 A/0

which is much simpler to work with. Can we improve on this? Give the
cmp_fn an additinoal optional argument of a string pointer or so to fill
out with actual details to be printed?


>  	pr_warn("\nother info that might help us debug this:\n");
>  	print_deadlock_scenario(next, prev);
>  	lockdep_print_held_locks(curr);

> @@ -6597,3 +6623,26 @@ void lockdep_rcu_suspicious(const char *file, const int line, const char *s)
>  	dump_stack();
>  }
>  EXPORT_SYMBOL_GPL(lockdep_rcu_suspicious);
> +
> +#ifdef CONFIG_PROVE_LOCKING

Surely we can find an existing #ifdef block to squirrel this in?

> +void lockdep_set_lock_cmp_fn(struct lockdep_map *lock, lock_cmp_fn fn)
> +{
> +	struct lock_class *class = lock->class_cache[0];
> +	unsigned long flags;
> +
> +	raw_local_irq_save(flags);
> +	lockdep_recursion_inc();
> +
> +	if (!class)
> +		class = register_lock_class(lock, 0, 0);
> +
> +	WARN_ON(class && class->cmp_fn && class->cmp_fn != fn);
> +
> +	if (class)
> +		class->cmp_fn = fn;
> +
> +	lockdep_recursion_finish();
> +	raw_local_irq_restore(flags);
> +}
> +EXPORT_SYMBOL_GPL(lockdep_set_lock_cmp_fn);

However, the bigger question is if this should be part of the
lockdep_init_map_*() family. Perhaps something like below.

With the thinking that the comparator is very much part of the class.

diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 1f1099dac3f0..ab50a889991f 100644
--- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -181,8 +181,18 @@ extern void lockdep_unregister_key(struct lock_class_key *key);
  * to lockdep:
  */
 
-extern void lockdep_init_map_type(struct lockdep_map *lock, const char *name,
-	struct lock_class_key *key, int subclass, u8 inner, u8 outer, u8 lock_type);
+extern void
+lockdep_init_map_cmp(struct lockdep_map *lock, const char *name,
+		     struct lock_class_key *key, int subclass, u8 inner, u8 outer,
+		     u8 lock_type, lock_cmp_fn cmp_fn);
+
+static inline void
+lockdep_init_map_type(struct lockdep_map *lock, const char *name,
+		      struct lock_class_key *key, int subclass, u8 inner, u8 outer,
+		      u8 lock_type)
+{
+	lockdep_init_map_cmp(lock, name, key, subclass, inner, outer, lock_type, NULL);
+}
 
 static inline void
 lockdep_init_map_waits(struct lockdep_map *lock, const char *name,
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index e3375bc40dad..5a6c9512d5b2 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -4800,9 +4800,10 @@ static inline int check_wait_context(struct task_struct *curr,
 /*
  * Initialize a lock instance's lock-class mapping info:
  */
-void lockdep_init_map_type(struct lockdep_map *lock, const char *name,
-			    struct lock_class_key *key, int subclass,
-			    u8 inner, u8 outer, u8 lock_type)
+void lockdep_init_map_cmp(struct lockdep_map *lock, const char *name,
+			  struct lock_class_key *key, int subclass,
+			  u8 inner, u8 outer, u8 lock_type,
+			  lock_cmp_fn cmp_fn)
 {
 	int i;
 
@@ -4847,7 +4848,8 @@ void lockdep_init_map_type(struct lockdep_map *lock, const char *name,
 	if (unlikely(!debug_locks))
 		return;
 
-	if (subclass) {
+	if (subclass || cmp_fn) {
+		struct lock_class *class;
 		unsigned long flags;
 
 		if (DEBUG_LOCKS_WARN_ON(!lockdep_enabled()))
@@ -4855,7 +4857,9 @@ void lockdep_init_map_type(struct lockdep_map *lock, const char *name,
 
 		raw_local_irq_save(flags);
 		lockdep_recursion_inc();
-		register_lock_class(lock, subclass, 1);
+		class = register_lock_class(lock, subclass, 1);
+		if (!WARN_ON(!class || (class->cmp_fn && class->cmp_fn != cmp_fn)))
+			class->cmp_fn = cmp_fn;
 		lockdep_recursion_finish();
 		raw_local_irq_restore(flags);
 	}

  reply	other threads:[~2023-02-20 15:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-18  3:21 [PATCH 0/2] lockdep lock comparison function Kent Overstreet
2023-02-18  3:21 ` [PATCH 1/2] lockdep: lock_set_lock_cmp_fn() Kent Overstreet
2023-02-20 15:09   ` Peter Zijlstra [this message]
2023-02-20 22:45     ` Kent Overstreet
2023-02-20 23:51     ` Kent Overstreet
2023-02-23 13:01       ` Peter Zijlstra
2023-02-23 19:27         ` Kent Overstreet
2023-02-18  3:21 ` [PATCH 2/2] bcache: Convert to lock_cmp_fn Kent Overstreet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y/ONLYqVrWPFyboF@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=stern@rowland.harvard.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®