From: Andrew Morton <akpm@linux-foundation.org>
To: Arjan van de Ven <arjan@infradead.org>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu
Subject: Re: PATCH] debug: add notifier chain debugging
Date: Tue, 19 Aug 2008 21:09:32 -0700 [thread overview]
Message-ID: <20080819210932.9bb348b9.akpm@linux-foundation.org> (raw)
In-Reply-To: <20080815152938.4bc9d48c@infradead.org>
On Fri, 15 Aug 2008 15:29:38 -0700 Arjan van de Ven <arjan@infradead.org> wrote:
> From: Arjan van de Ven <arjan@linux.intel.com>
> Subject: [PATCH] debug: add notifier chain debugging
>
> during some development we suspected a case where we left something
> in a notifier chain that was from a module that was unloaded already...
> and that sort of thing is rather hard to track down.
>
> This patch adds a very simple sanity check (which isn't all that
> expensive) to make sure the notifier we're about to call is
> actually from either the kernel itself of from a still-loaded
> module, avoiding a hard-to-chase-down crash.
>
> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
> ---
> kernel/notifier.c | 16 ++++++++++++++++
> lib/Kconfig.debug | 10 ++++++++++
> 2 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/notifier.c b/kernel/notifier.c
> index 823be11..143fdd7 100644
> --- a/kernel/notifier.c
> +++ b/kernel/notifier.c
> @@ -21,6 +21,10 @@ BLOCKING_NOTIFIER_HEAD(reboot_notifier_list);
> static int notifier_chain_register(struct notifier_block **nl,
> struct notifier_block *n)
> {
> + if (!kernel_text_address((unsigned long)n->notifier_call)) {
> + WARN(1, "Invalid notifier registered!");
> + return 0;
> + }
> while ((*nl) != NULL) {
> if (n->priority > (*nl)->priority)
> break;
> @@ -34,6 +38,10 @@ static int notifier_chain_register(struct notifier_block **nl,
> static int notifier_chain_cond_register(struct notifier_block **nl,
> struct notifier_block *n)
> {
> + if (!kernel_text_address((unsigned long)n->notifier_call)) {
> + WARN(1, "Invalid notifier registered!");
> + return 0;
> + }
Seems strange to add checks to the registration functions. What could
be that broken?
> while ((*nl) != NULL) {
> if ((*nl) == n)
> return 0;
> @@ -82,6 +90,14 @@ static int __kprobes notifier_call_chain(struct notifier_block **nl,
>
> while (nb && nr_to_call) {
> next_nb = rcu_dereference(nb->next);
> +
> +#ifdef CONFIG_DEBUG_NOTIFIERS
> + if (!kernel_text_address((unsigned long)nb->notifier_call)) {
> + WARN(1, "Invalid notifier called!");
> + nb = next_nb;
> + continue;
> + }
> +#endif
> ret = nb->notifier_call(nb, val, v);
>
> if (nr_calls)
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 800ac84..f4bb36e 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -536,6 +536,16 @@ config DEBUG_SG
>
> If unsure, say N.
>
> +config DEBUG_NOTIFIERS
> + bool "Debug notifier call chains"
> + depends on DEBUG_KERNEL
> + help
> + Enable this to turn on sanity checking for notifier call chains.
> + This is most useful for kernel developers to make sure that
> + modules properly unregister themselves from notifier chains.
> + This is a relatively cheap check but if you care about maximum
> + performance, say N.
> +
If we remove the first two checks then surely we can afford to add the
remaining check unconditionally and lose the new config option and its
ifdef.
next prev parent reply other threads:[~2008-08-20 4:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-15 22:29 PATCH] debug: add notifier chain debugging Arjan van de Ven
2008-08-15 22:53 ` Ingo Molnar
2008-08-20 4:09 ` Andrew Morton [this message]
2008-08-20 10:53 ` Ingo Molnar
2008-08-22 14:00 ` Arjan van de Ven
2008-08-22 14:45 ` Christoph Hellwig
2008-08-25 22:39 ` Tony Luck
2008-08-26 4:55 ` Arjan van de Ven
2008-08-26 5:08 ` Tony Luck
2008-08-26 13:46 ` Arjan van de Ven
2008-08-26 16:22 ` Arjan van de Ven
2008-08-27 6:39 ` Ingo Molnar
2008-08-27 10:55 ` Arjan van de Ven
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=20080819210932.9bb348b9.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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