Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 9 Jul 2019 15:59:43 +0100
From:   Daniel Thompson <daniel.thompson@linaro.org>
To:     Douglas Anderson <dianders@chromium.org>
Cc:     Jason Wessel <jason.wessel@windriver.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Martin Schwidefsky <schwidefsky@de.ibm.com>,
        Kees Cook <keescook@chromium.org>,
        kgdb-bugreport@lists.sourceforge.net, Borislav Petkov <bp@suse.de>,
        linux-kernel@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
        Feng Tang <feng.tang@intel.com>,
        YueHaibing <yuehaibing@huawei.com>,
        Sergey Senozhatsky <sergey.senozhatsky.work@gmail.com>,
        "Steven Rostedt (VMware)" <rostedt@goodmis.org>
Subject: Re: [PATCH] kgdb: Don't use a notifier to enter kgdb at panic; call
 directly
Message-ID: <20190709145943.zfwvs7inlngtxwfe@holly.lan>
References: <20190703170354.217312-1-dianders@chromium.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190703170354.217312-1-dianders@chromium.org>
User-Agent: NeoMutt/20180716
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, Jul 03, 2019 at 10:03:54AM -0700, Douglas Anderson wrote:
> Right now kgdb/kdb hooks up to debug panics by registering for the
> panic notifier.  This works OK except that it means that kgdb/kdb gets
> called _after_ the CPUs in the system are taken offline.  That means
> that if anything important was happening on those CPUs (like something
> that might have contributed to the panic) you can't debug them.
> 
> Specifically I ran into a case where I got a panic because a task was
> "blocked for more than 120 seconds" which was detected on CPU 2.  I
> nicely got shown stack traces in the kernel log for all CPUs including
> CPU 0, which was running 'PID: 111 Comm: kworker/0:1H' and was in the
> middle of __mmc_switch().
> 
> I then ended up at the kdb prompt where switched over to kgdb to try
> to look at local variables of the process on CPU 0.  I found that I
> couldn't.  Digging more, I found that I had no info on any tasks
> running on CPUs other than CPU 2 and that asking kdb for help showed
> me "Error: no saved data for this cpu".  This was because all the CPUs
> were offline.
> 
> Let's move the entry of kdb/kgdb to a direct call from panic() and
> stop using the generic notifier.  Putting a direct call in allows us
> to order things more properly and it also doesn't seem like we're
> breaking any abstractions by calling into the debugger from the panic
> function.
> 
> Signed-off-by: Douglas Anderson <dianders@chromium.org>

This patch changes the way kdump and kgdb interact with each other.
However it would seem rather odd to have both tools simultaneously
armed and, even if they were, the user still has the option to
use panic_timeout to force a kdump to happen. Thus I think the
change of order is acceptable:

Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org>


Daniel.


> diff --git a/kernel/panic.c b/kernel/panic.c
> index 4d9f55bf7d38..e2971168b059 100644
> --- a/kernel/panic.c
> +++ b/kernel/panic.c
> @@ -12,6 +12,7 @@
>  #include <linux/debug_locks.h>
>  #include <linux/sched/debug.h>
>  #include <linux/interrupt.h>
> +#include <linux/kgdb.h>
>  #include <linux/kmsg_dump.h>
>  #include <linux/kallsyms.h>
>  #include <linux/notifier.h>
> @@ -219,6 +220,13 @@ void panic(const char *fmt, ...)
>  		dump_stack();
>  #endif
>  
> +	/*
> +	 * If kgdb is enabled, give it a chance to run before we stop all
> +	 * the other CPUs or else we won't be able to debug processes left
> +	 * running on them.
> +	 */
> +	kgdb_panic(buf);
> +
>  	/*
>  	 * If we have crashed and we have a crash kernel loaded let it handle
>  	 * everything else.
> -- 
> 2.22.0.410.gd8fdbe21b5-goog
>