[PATCH 7/9] kexec_core: Add and update comments regarding the KEXEC_JUMP flow

David Woodhouse posted 9 patches 1 year ago
There is a newer version of this series
[PATCH 7/9] kexec_core: Add and update comments regarding the KEXEC_JUMP flow
Posted by David Woodhouse 1 year ago
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

The KEXEC_JUMP flow is analogous to hibernation flows occurring before
and after creating an image and before and after jumping from the
restore kernel to the image one, which is why it uses the same device
callbacks as those hibernation flows.

Add comments explaining that to the code in question and update an
existing comment in it which appears a bit out of context.

No functional changes.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
---
 kernel/kexec_core.c | 23 +++++++++++++++++------
 1 file changed, 17 insertions(+), 6 deletions(-)

diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index c0caa14880c3..7cf8437e0f38 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -1001,6 +1001,12 @@ int kernel_kexec(void)
 
 #ifdef CONFIG_KEXEC_JUMP
 	if (kexec_image->preserve_context) {
+		/*
+		 * This flow is analogous to hibernation flows that occur before
+		 * creating an image and before jumping from the restore kernel
+		 * to the image one, so it uses the same device device callbacks
+		 * as those two flows.
+		 */
 		pm_prepare_console();
 		error = freeze_processes();
 		if (error) {
@@ -1011,12 +1017,10 @@ int kernel_kexec(void)
 		error = dpm_suspend_start(PMSG_FREEZE);
 		if (error)
 			goto Resume_console;
-		/* At this point, dpm_suspend_start() has been called,
-		 * but *not* dpm_suspend_end(). We *must* call
-		 * dpm_suspend_end() now.  Otherwise, drivers for
-		 * some devices (e.g. interrupt controllers) become
-		 * desynchronized with the actual state of the
-		 * hardware at resume time, and evil weirdness ensues.
+		/*
+		 * dpm_suspend_end() must be called after dpm_suspend_start()
+		 * to complete the transition, like in the hibernation flows
+		 * mentioned above.
 		 */
 		error = dpm_suspend_end(PMSG_FREEZE);
 		if (error)
@@ -1052,6 +1056,13 @@ int kernel_kexec(void)
 
 #ifdef CONFIG_KEXEC_JUMP
 	if (kexec_image->preserve_context) {
+		/*
+		 * This flow is analogous to hibernation flows that occur after
+		 * creating an image and after the image hernel has got control
+		 * back, and in case the devices have been reset or otherwise
+		 * manipulated in the meantime, it uses the device callbacks
+		 * used by the latter.
+		 */
 		syscore_resume();
  Enable_irqs:
 		local_irq_enable();
-- 
2.47.0
Re: [PATCH 7/9] kexec_core: Add and update comments regarding the KEXEC_JUMP flow
Posted by Dave Young 11 months, 2 weeks ago
> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> index c0caa14880c3..7cf8437e0f38 100644
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -1001,6 +1001,12 @@ int kernel_kexec(void)
>
>  #ifdef CONFIG_KEXEC_JUMP
>         if (kexec_image->preserve_context) {
> +               /*
> +                * This flow is analogous to hibernation flows that occur before
> +                * creating an image and before jumping from the restore kernel
> +                * to the image one, so it uses the same device device callbacks

nitpick: s/device device/device

> +                * as those two flows.
> +                */
>                 pm_prepare_console();
>                 error = freeze_processes();
>                 if (error) {
Re: [PATCH 7/9] kexec_core: Add and update comments regarding the KEXEC_JUMP flow
Posted by David Woodhouse 11 months, 2 weeks ago
On Fri, 2025-01-03 at 17:24 +0800, Dave Young wrote:
> > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> > index c0caa14880c3..7cf8437e0f38 100644
> > --- a/kernel/kexec_core.c
> > +++ b/kernel/kexec_core.c
> > @@ -1001,6 +1001,12 @@ int kernel_kexec(void)
> > 
> >  #ifdef CONFIG_KEXEC_JUMP
> >         if (kexec_image->preserve_context) {
> > +               /*
> > +                * This flow is analogous to hibernation flows that occur before
> > +                * creating an image and before jumping from the restore kernel
> > +                * to the image one, so it uses the same device device callbacks
> 
> nitpick: s/device device/device

Thanks. Fixed up locally and will be in the resend.