Message ID | 20220201105305.155511-1-hbathini@linux.ibm.com (mailing list archive) |
---|---|
State | Accepted |
Headers | show |
Series | [RESEND,v2] powerpc/fadump: register for fadump as early as possible | expand |
Context | Check | Description |
---|---|---|
snowpatch_ozlabs/github-powerpc_ppctests | success | Successfully ran 8 jobs. |
snowpatch_ozlabs/github-powerpc_selftests | success | Successfully ran 8 jobs. |
snowpatch_ozlabs/github-powerpc_sparse | success | Successfully ran 4 jobs. |
snowpatch_ozlabs/github-powerpc_clang | success | Successfully ran 7 jobs. |
snowpatch_ozlabs/github-powerpc_kernel_qemu | success | Successfully ran 24 jobs. |
On Tue, 1 Feb 2022 16:23:05 +0530, Hari Bathini wrote: > Crash recovery (fadump) is setup in the userspace by some service. > This service rebuilds initrd with dump capture capability, if it is > not already dump capture capable before proceeding to register for > firmware assisted dump (echo 1 > /sys/kernel/fadump/registered). But > arming the kernel with crash recovery support does not have to wait > for userspace configuration. So, register for fadump while setting > it up itself. This can at worst lead to a scenario, where /proc/vmcore > is ready afer crash but the initrd does not know how/where to offload > it, which is always better than not having a /proc/vmcore at all due > to incomplete configuration in the userspace at the time of crash. > > [...] Applied to powerpc/next. [1/1] powerpc/fadump: register for fadump as early as possible https://git.kernel.org/powerpc/c/607451ce0aa9bdff590db4d087173edba6d7a29d cheers
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c index d03e488cfe9c..97d80df4563f 100644 --- a/arch/powerpc/kernel/fadump.c +++ b/arch/powerpc/kernel/fadump.c @@ -1637,9 +1637,11 @@ int __init setup_fadump(void) if (fw_dump.ops->fadump_process(&fw_dump) < 0) fadump_invalidate_release_mem(); } - /* Initialize the kernel dump memory structure for FAD registration. */ - else if (fw_dump.reserve_dump_area_size) + /* Initialize the kernel dump memory structure and register with f/w */ + else if (fw_dump.reserve_dump_area_size) { fw_dump.ops->fadump_init_mem_struct(&fw_dump); + register_fadump(); + } /* * In case of panic, fadump is triggered via ppc_panic_event() @@ -1651,7 +1653,12 @@ int __init setup_fadump(void) return 1; } -subsys_initcall(setup_fadump); +/* + * Replace subsys_initcall() with subsys_initcall_sync() as there is dependency + * with crash_save_vmcoreinfo_init() to ensure vmcoreinfo initialization is done + * before regisering with f/w. + */ +subsys_initcall_sync(setup_fadump); #else /* !CONFIG_PRESERVE_FA_DUMP */ /* Scan the Firmware Assisted dump configuration details. */
Crash recovery (fadump) is setup in the userspace by some service. This service rebuilds initrd with dump capture capability, if it is not already dump capture capable before proceeding to register for firmware assisted dump (echo 1 > /sys/kernel/fadump/registered). But arming the kernel with crash recovery support does not have to wait for userspace configuration. So, register for fadump while setting it up itself. This can at worst lead to a scenario, where /proc/vmcore is ready afer crash but the initrd does not know how/where to offload it, which is always better than not having a /proc/vmcore at all due to incomplete configuration in the userspace at the time of crash. Commit 0823c68b054b ("powerpc/fadump: re-register firmware-assisted dump if already registered") ensures this change does not break userspace. Signed-off-by: Hari Bathini <hbathini@linux.ibm.com> --- * Resending the patch after rebasing on latest code. Changes in V2: * Updated the changelog with bit more explanation about userspace issue with/without this change. * Added a comment in the code for why setup_fadump function is changed from subsys_init() to subsys_init_sync() call. arch/powerpc/kernel/fadump.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-)