[PATCH v1 0/2] kexec_core: Fix and cleanup for the KEXEC_JUMP flow

[PATCH v1 0/2] kexec_core: Fix and cleanup for the KEXEC_JUMP flow

[Rafael J. Wysocki]

Hi Everyone,

These two patches fix an error code path issue in the KEXEC_JUMP flow (patch
[1/2]) and clean it up a bit afterward (patch [2/2]).

Please see patch changelogs for details.

Thanks!

[PATCH v1 1/2] kexec_core: Fix error code path in the KEXEC_JUMP flow

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

If dpm_suspend_start() fails, dpm_resume_end() must be called to
recover devices whose suspend callbacks have been called, but this
does not happen in the KEXEC_JUMP flow's error path due to a confused
goto target label.

Address this by using the correct target label in the goto statement in
question.

Fixes: 2965faa5e03d ("kexec: split kexec_load syscall from kexec core code")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 kernel/kexec_core.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -1080,7 +1080,7 @@
 		console_suspend_all();
 		error = dpm_suspend_start(PMSG_FREEZE);
 		if (error)
-			goto Resume_console;
+			goto Resume_devices;
 		/*
 		 * dpm_suspend_end() must be called after dpm_suspend_start()
 		 * to complete the transition, like in the hibernation flows

[PATCH v1 2/2] kexec_core: Drop redundant pm_restore_gfp_mask() call

[Rafael J. Wysocki]

From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Drop the direct pm_restore_gfp_mask() call from the KEXEC_JUMP flow in
kernel_kexec() because it is redundant.  Namely, dpm_resume_end()
called beforehand in the same code path invokes that function and
it is sufficient to invoke it once.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 kernel/kexec_core.c |    1 -
 1 file changed, 1 deletion(-)

--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -1136,7 +1136,6 @@
  Resume_devices:
 		dpm_resume_end(PMSG_RESTORE);
  Resume_console:
-		pm_restore_gfp_mask();
 		console_resume_all();
 		thaw_processes();
  Restore_console:

Re: [PATCH v1 1/2] kexec_core: Fix error code path in the KEXEC_JUMP flow

[Baoquan He]

On 07/10/25 at 03:10pm, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> If dpm_suspend_start() fails, dpm_resume_end() must be called to
> recover devices whose suspend callbacks have been called, but this
> does not happen in the KEXEC_JUMP flow's error path due to a confused
> goto target label.
> 
> Address this by using the correct target label in the goto statement in
> question.

Sounds very reasonable, thanks for the fix.

Acked-by: Baoquan He <bhe@redhat.com>

> 
> Fixes: 2965faa5e03d ("kexec: split kexec_load syscall from kexec core code")
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>  kernel/kexec_core.c |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -1080,7 +1080,7 @@
>  		console_suspend_all();
>  		error = dpm_suspend_start(PMSG_FREEZE);
>  		if (error)
> -			goto Resume_console;
> +			goto Resume_devices;
>  		/*
>  		 * dpm_suspend_end() must be called after dpm_suspend_start()
>  		 * to complete the transition, like in the hibernation flows
> 
> 
> 

Re: [PATCH v1 2/2] kexec_core: Drop redundant pm_restore_gfp_mask() call

[Baoquan He]

On 07/10/25 at 03:12pm, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> 
> Drop the direct pm_restore_gfp_mask() call from the KEXEC_JUMP flow in
> kernel_kexec() because it is redundant.  Namely, dpm_resume_end()
> called beforehand in the same code path invokes that function and
> it is sufficient to invoke it once.
> 
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>  kernel/kexec_core.c |    1 -
>  1 file changed, 1 deletion(-)

LGTM,

Acked-by: Baoquan He <bhe@redhat.com>

> 
> --- a/kernel/kexec_core.c
> +++ b/kernel/kexec_core.c
> @@ -1136,7 +1136,6 @@
>   Resume_devices:
>  		dpm_resume_end(PMSG_RESTORE);
>   Resume_console:
> -		pm_restore_gfp_mask();
>  		console_resume_all();
>  		thaw_processes();
>   Restore_console:
> 
> 
> 

Re: [PATCH v1 1/2] kexec_core: Fix error code path in the KEXEC_JUMP flow

[Rafael J. Wysocki]

On Fri, Jul 11, 2025 at 8:16 AM Baoquan He <bhe@redhat.com> wrote:
>
> On 07/10/25 at 03:10pm, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > If dpm_suspend_start() fails, dpm_resume_end() must be called to
> > recover devices whose suspend callbacks have been called, but this
> > does not happen in the KEXEC_JUMP flow's error path due to a confused
> > goto target label.
> >
> > Address this by using the correct target label in the goto statement in
> > question.
>
> Sounds very reasonable, thanks for the fix.
>
> Acked-by: Baoquan He <bhe@redhat.com>

Thanks!

I've queued it up for 6.17 along with the [2/2].

> >
> > Fixes: 2965faa5e03d ("kexec: split kexec_load syscall from kexec core code")
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > ---
> >  kernel/kexec_core.c |    2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > --- a/kernel/kexec_core.c
> > +++ b/kernel/kexec_core.c
> > @@ -1080,7 +1080,7 @@
> >               console_suspend_all();
> >               error = dpm_suspend_start(PMSG_FREEZE);
> >               if (error)
> > -                     goto Resume_console;
> > +                     goto Resume_devices;
> >               /*
> >                * dpm_suspend_end() must be called after dpm_suspend_start()
> >                * to complete the transition, like in the hibernation flows
> >
> >
> >
>

Re: [PATCH v1 0/2] kexec_core: Fix and cleanup for the KEXEC_JUMP flow

[Mario Limonciello]

On 7/10/2025 9:08 AM, Rafael J. Wysocki wrote:
> Hi Everyone,
> 
> These two patches fix an error code path issue in the KEXEC_JUMP flow (patch
> [1/2]) and clean it up a bit afterward (patch [2/2]).
> 
> Please see patch changelogs for details.
> 
> Thanks!
> 
> 
> 

Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>