From: Boqun Feng <boqun.feng@gmail.com>
To: Vincent Whitchurch <vincent.whitchurch@axis.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
kernel@axis.com, Waiman Long <longman@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] lockdep: Panic on warning if panic_on_warn is set
Date: Thu, 18 Aug 2022 14:49:17 -0700 [thread overview]
Message-ID: <Yv6z3SlfpmN+ZeV1@boqun-archlinux> (raw)
In-Reply-To: <20220818114259.2203505-1-vincent.whitchurch@axis.com>
Hi,
On Thu, Aug 18, 2022 at 01:42:58PM +0200, Vincent Whitchurch wrote:
> There does not seem to be any way to get the system to panic if a
> lockdep warning is emitted, since those warnings don't use the normal
> WARN() infrastructure. Panicking on any lockdep warning can be
> desirable when the kernel is being run in a controlled environment
> solely for the purpose of testing. Make lockdep respect panic_on_warn
> to allow this, similar to KASAN and others.
>
I'm not completely against this, but could you explain why you want to
panic on lockdep warning? I assume you want to have a kdump so that you
can understand the lock bugs closely? But lockdep discovers lock issue
possiblity, so it's not an after-the-fact detector. In other words, when
lockdep warns, the deadlock cases don't happen in the meanwhile. And
also lockdep tries very hard to print useful information to locate the
issues.
This patch add lockdep_panic() to a few places, and it's a pain for
maintaining. So why do you want to panic on lockdep warning?
Regards,
Boqun
> Signed-off-by: Vincent Whitchurch <vincent.whitchurch@axis.com>
> ---
> kernel/locking/lockdep.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> index 64a13eb56078..d184bba02630 100644
> --- a/kernel/locking/lockdep.c
> +++ b/kernel/locking/lockdep.c
> @@ -124,6 +124,12 @@ static __always_inline bool lockdep_enabled(void)
> return true;
> }
>
> +static void lockdep_panic(void)
> +{
> + if (panic_on_warn)
> + panic("panic_on_warn set ...\n");
> +}
> +
> /*
> * lockdep_lock: protects the lockdep graph, the hashes and the
> * class/list/hash allocators.
> @@ -977,6 +983,7 @@ static bool assign_lock_key(struct lockdep_map *lock)
> pr_err("you didn't initialize this object before use?\n");
> pr_err("turning off the locking correctness validator.\n");
> dump_stack();
> + lockdep_panic();
> return false;
> }
>
> @@ -2051,6 +2058,7 @@ static noinline void print_circular_bug(struct lock_list *this,
>
> printk("\nstack backtrace:\n");
> dump_stack();
> + lockdep_panic();
> }
>
> static noinline void print_bfs_bug(int ret)
> @@ -2607,6 +2615,7 @@ print_bad_irq_dependency(struct task_struct *curr,
>
> pr_warn("\nstack backtrace:\n");
> dump_stack();
> + lockdep_panic();
> }
>
> static const char *state_names[] = {
> @@ -2986,6 +2995,7 @@ print_deadlock_bug(struct task_struct *curr, struct held_lock *prev,
>
> pr_warn("\nstack backtrace:\n");
> dump_stack();
> + lockdep_panic();
> }
>
> /*
> @@ -3583,6 +3593,7 @@ static void print_collision(struct task_struct *curr,
>
> pr_warn("\nstack backtrace:\n");
> dump_stack();
> + lockdep_panic();
> }
> #endif
>
> @@ -3959,6 +3970,7 @@ print_usage_bug(struct task_struct *curr, struct held_lock *this,
>
> pr_warn("\nstack backtrace:\n");
> dump_stack();
> + lockdep_panic();
> }
>
> /*
> @@ -4038,6 +4050,7 @@ print_irq_inversion_bug(struct task_struct *curr,
>
> pr_warn("\nstack backtrace:\n");
> dump_stack();
> + lockdep_panic();
> }
>
> /*
> @@ -4703,6 +4716,7 @@ print_lock_invalid_wait_context(struct task_struct *curr,
>
> pr_warn("stack backtrace:\n");
> dump_stack();
> + lockdep_panic();
>
> return 0;
> }
> @@ -4892,6 +4906,7 @@ print_lock_nested_lock_not_held(struct task_struct *curr,
>
> pr_warn("\nstack backtrace:\n");
> dump_stack();
> + lockdep_panic();
> }
>
> static int __lock_is_held(const struct lockdep_map *lock, int read);
> @@ -5104,6 +5119,7 @@ static void print_unlock_imbalance_bug(struct task_struct *curr,
>
> pr_warn("\nstack backtrace:\n");
> dump_stack();
> + lockdep_panic();
> }
>
> static noinstr int match_held_lock(const struct held_lock *hlock,
> @@ -5795,6 +5811,7 @@ static void print_lock_contention_bug(struct task_struct *curr,
>
> pr_warn("\nstack backtrace:\n");
> dump_stack();
> + lockdep_panic();
> }
>
> static void
> @@ -6420,6 +6437,7 @@ print_freed_lock_bug(struct task_struct *curr, const void *mem_from,
>
> pr_warn("\nstack backtrace:\n");
> dump_stack();
> + lockdep_panic();
> }
>
> static inline int not_in_range(const void* mem_from, unsigned long mem_len,
> @@ -6475,6 +6493,7 @@ static void print_held_locks_bug(void)
> lockdep_print_held_locks(current);
> pr_warn("\nstack backtrace:\n");
> dump_stack();
> + lockdep_panic();
> }
>
> void debug_check_no_locks_held(void)
> @@ -6593,5 +6612,6 @@ void lockdep_rcu_suspicious(const char *file, const int line, const char *s)
> lockdep_print_held_locks(curr);
> pr_warn("\nstack backtrace:\n");
> dump_stack();
> + lockdep_panic();
> }
> EXPORT_SYMBOL_GPL(lockdep_rcu_suspicious);
> --
> 2.34.1
>
next prev parent reply other threads:[~2022-08-18 21:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-18 11:42 Vincent Whitchurch
2022-08-18 21:49 ` Boqun Feng [this message]
2022-08-19 10:59 ` Vincent Whitchurch
2022-08-20 5:18 ` Boqun Feng
2022-08-22 12:16 ` Vincent Whitchurch
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=Yv6z3SlfpmN+ZeV1@boqun-archlinux \
--to=boqun.feng@gmail.com \
--cc=kernel@axis.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=vincent.whitchurch@axis.com \
--cc=will@kernel.org \
/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
Powered by JetHome