From: ebiederm@xmission.com (Eric W. Biederman)
To: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: sashal@kernel.org, pmladek@suse.com, tony.luck@intel.com,
keescook@chromium.org, anton@enomsg.org,
kexec@lists.infradead.org, jmorris@namei.org,
linux-kernel@vger.kernel.org, tyhicks@linux.microsoft.com,
ccross@android.com
Subject: Re: [PATCH v2 1/1] kexec: dump kmessage before machine_kexec
Date: Thu, 28 Jan 2021 14:00:28 -0600 [thread overview]
Message-ID: <87lfcczvab.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20210126204125.313820-2-pasha.tatashin@soleen.com> (Pavel Tatashin's message of "Tue, 26 Jan 2021 15:41:25 -0500")
Pavel Tatashin <pasha.tatashin@soleen.com> writes:
> kmsg_dump(KMSG_DUMP_SHUTDOWN) is called before
> machine_restart(), machine_halt(), machine_power_off(), the only one that
> is missing is machine_kexec().
>
> The dmesg output that it contains can be used to study the shutdown
> performance of both kernel and systemd during kexec reboot.
>
> Here is example of dmesg data collected after kexec:
As long was we keep kmsg_dump out of the crash_kexec path where
it completely breaks kexec on panic this seems a reasonable thing to do.
On the ordinary kernel_kexec path everything is expected to be working.
Is kmsg_dump expected to work after all of the device drivers
are shut down? Otherwise this placement of kmsg_dump is too late.
Eric
> root@dplat-cp22:~# cat /sys/fs/pstore/dmesg-ramoops-0 | tail
> ...
> <6>[ 70.914592] psci: CPU3 killed (polled 0 ms)
> <5>[ 70.915705] CPU4: shutdown
> <6>[ 70.916643] psci: CPU4 killed (polled 4 ms)
> <5>[ 70.917715] CPU5: shutdown
> <6>[ 70.918725] psci: CPU5 killed (polled 0 ms)
> <5>[ 70.919704] CPU6: shutdown
> <6>[ 70.920726] psci: CPU6 killed (polled 4 ms)
> <5>[ 70.921642] CPU7: shutdown
> <6>[ 70.922650] psci: CPU7 killed (polled 0 ms)
>
> Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Petr Mladek <pmladek@suse.com>
> Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com>
> ---
> kernel/kexec_core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 4f8efc278aa7..e253c8b59145 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -37,6 +37,7 @@
> #include <linux/compiler.h>
> #include <linux/hugetlb.h>
> #include <linux/objtool.h>
> +#include <linux/kmsg_dump.h>
>
> #include <asm/page.h>
> #include <asm/sections.h>
> @@ -1180,6 +1181,7 @@ int kernel_kexec(void)
> machine_shutdown();
> }
>
> + kmsg_dump(KMSG_DUMP_SHUTDOWN);
> machine_kexec(kexec_image);
>
> #ifdef CONFIG_KEXEC_JUMP
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Pavel Tatashin <pasha.tatashin@soleen.com>
Cc: jmorris@namei.org, sashal@kernel.org,
tyhicks@linux.microsoft.com, pmladek@suse.com,
keescook@chromium.org, anton@enomsg.org, ccross@android.com,
tony.luck@intel.com, kexec@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/1] kexec: dump kmessage before machine_kexec
Date: Thu, 28 Jan 2021 14:00:28 -0600 [thread overview]
Message-ID: <87lfcczvab.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20210126204125.313820-2-pasha.tatashin@soleen.com> (Pavel Tatashin's message of "Tue, 26 Jan 2021 15:41:25 -0500")
Pavel Tatashin <pasha.tatashin@soleen.com> writes:
> kmsg_dump(KMSG_DUMP_SHUTDOWN) is called before
> machine_restart(), machine_halt(), machine_power_off(), the only one that
> is missing is machine_kexec().
>
> The dmesg output that it contains can be used to study the shutdown
> performance of both kernel and systemd during kexec reboot.
>
> Here is example of dmesg data collected after kexec:
As long was we keep kmsg_dump out of the crash_kexec path where
it completely breaks kexec on panic this seems a reasonable thing to do.
On the ordinary kernel_kexec path everything is expected to be working.
Is kmsg_dump expected to work after all of the device drivers
are shut down? Otherwise this placement of kmsg_dump is too late.
Eric
> root@dplat-cp22:~# cat /sys/fs/pstore/dmesg-ramoops-0 | tail
> ...
> <6>[ 70.914592] psci: CPU3 killed (polled 0 ms)
> <5>[ 70.915705] CPU4: shutdown
> <6>[ 70.916643] psci: CPU4 killed (polled 4 ms)
> <5>[ 70.917715] CPU5: shutdown
> <6>[ 70.918725] psci: CPU5 killed (polled 0 ms)
> <5>[ 70.919704] CPU6: shutdown
> <6>[ 70.920726] psci: CPU6 killed (polled 4 ms)
> <5>[ 70.921642] CPU7: shutdown
> <6>[ 70.922650] psci: CPU7 killed (polled 0 ms)
>
> Signed-off-by: Pavel Tatashin <pasha.tatashin@soleen.com>
> Reviewed-by: Kees Cook <keescook@chromium.org>
> Reviewed-by: Petr Mladek <pmladek@suse.com>
> Reviewed-by: Bhupesh Sharma <bhsharma@redhat.com>
> ---
> kernel/kexec_core.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index 4f8efc278aa7..e253c8b59145 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -37,6 +37,7 @@
> #include <linux/compiler.h>
> #include <linux/hugetlb.h>
> #include <linux/objtool.h>
> +#include <linux/kmsg_dump.h>
>
> #include <asm/page.h>
> #include <asm/sections.h>
> @@ -1180,6 +1181,7 @@ int kernel_kexec(void)
> machine_shutdown();
> }
>
> + kmsg_dump(KMSG_DUMP_SHUTDOWN);
> machine_kexec(kexec_image);
>
> #ifdef CONFIG_KEXEC_JUMP
next prev parent reply other threads:[~2021-01-28 20:02 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-26 20:41 [PATCH v2 0/1] dump kmessage before machine_kexec Pavel Tatashin
2021-01-26 20:41 ` Pavel Tatashin
2021-01-26 20:41 ` [PATCH v2 1/1] kexec: " Pavel Tatashin
2021-01-26 20:41 ` Pavel Tatashin
2021-01-28 5:22 ` Baoquan He
2021-01-28 5:22 ` Baoquan He
2021-01-28 20:00 ` Eric W. Biederman [this message]
2021-01-28 20:00 ` Eric W. Biederman
2021-01-28 21:43 ` Pavel Tatashin
2021-01-28 21:43 ` Pavel Tatashin
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=87lfcczvab.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=anton@enomsg.org \
--cc=ccross@android.com \
--cc=jmorris@namei.org \
--cc=keescook@chromium.org \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pasha.tatashin@soleen.com \
--cc=pmladek@suse.com \
--cc=sashal@kernel.org \
--cc=tony.luck@intel.com \
--cc=tyhicks@linux.microsoft.com \
/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 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.