[PATCH v3] PM: hibernate: call preallocate_image after freeze prepare

[PATCH v3] PM: hibernate: call preallocate_image after freeze prepare

[Matthew Leach]

Certain drivers release resources (pinned pages, etc.) into system
memory during the prepare freeze PM op, making them swappable.
Currently, hibernate_preallocate_memory is called before prepare freeze,
so those drivers have no opportunity to release resources first. If a
driver is holding a large amount of unswappable system RAM, this can
cause hibernate_preallocate_memory to fail.

Move the call to hibernate_preallocate_memory after prepare freeze.
According to the documentation for the prepare callback, devices should
be left in a usable state, so storage drivers should still be able to
service I/O requests. This allows drivers to release unswappable
resources prior to preallocation, so they can be swapped out through
hibernate_preallocate_memory's reclaim path. Also remove
shrink_shmem_memory since hibernate_preallocate_memory will have
reclaimed enough memory for the hibernation image.

Signed-off-by: Matthew Leach <matthew.leach@collabora.com>
---
Changes in v3:
- Changed error label names to 'Thaw' and 'Complete'.
- Link to v2: https://patch.msgid.link/20260326-hibernation-fixes-v2-1-f6707d82b7b9@collabora.com

Changes in v2:
- Removed shrink_shmem_memory.
- Fixed missing call to dpm_prepare in error path.
- Link to v1: https://lore.kernel.org/r/20260321-hibernation-fixes-v1-1-5fe9637b6ff9@collabora.com
---
 kernel/power/hibernate.c | 46 +++++++++-------------------------------------
 1 file changed, 9 insertions(+), 37 deletions(-)

diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
index af8d07bafe02..d2479c69d71a 100644
--- a/kernel/power/hibernate.c
+++ b/kernel/power/hibernate.c
@@ -392,23 +392,6 @@ static int create_image(int platform_mode)
 	return error;
 }
 
-static void shrink_shmem_memory(void)
-{
-	struct sysinfo info;
-	unsigned long nr_shmem_pages, nr_freed_pages;
-
-	si_meminfo(&info);
-	nr_shmem_pages = info.sharedram; /* current page count used for shmem */
-	/*
-	 * The intent is to reclaim all shmem pages. Though shrink_all_memory() can
-	 * only reclaim about half of them, it's enough for creating the hibernation
-	 * image.
-	 */
-	nr_freed_pages = shrink_all_memory(nr_shmem_pages);
-	pr_debug("requested to reclaim %lu shmem pages, actually freed %lu pages\n",
-			nr_shmem_pages, nr_freed_pages);
-}
-
 /**
  * hibernation_snapshot - Quiesce devices and create a hibernation image.
  * @platform_mode: If set, use platform driver to prepare for the transition.
@@ -425,14 +408,9 @@ int hibernation_snapshot(int platform_mode)
 	if (error)
 		goto Close;
 
-	/* Preallocate image memory before shutting down devices. */
-	error = hibernate_preallocate_memory();
-	if (error)
-		goto Close;
-
 	error = freeze_kernel_threads();
 	if (error)
-		goto Cleanup;
+		goto Close;
 
 	if (hibernation_test(TEST_FREEZER)) {
 
@@ -445,19 +423,13 @@ int hibernation_snapshot(int platform_mode)
 	}
 
 	error = dpm_prepare(PMSG_FREEZE);
-	if (error) {
-		dpm_complete(PMSG_RECOVER);
-		goto Thaw;
-	}
+	if (error)
+		goto Complete;
 
-	/*
-	 * Device drivers may move lots of data to shmem in dpm_prepare(). The shmem
-	 * pages will use lots of system memory, causing hibernation image creation
-	 * fail due to insufficient free memory.
-	 * This call is to force flush the shmem pages to swap disk and reclaim
-	 * the system memory so that image creation can succeed.
-	 */
-	shrink_shmem_memory();
+	/* Preallocate image memory before shutting down devices. */
+	error = hibernate_preallocate_memory();
+	if (error)
+		goto Complete;
 
 	console_suspend_all();
 	pm_restrict_gfp_mask();
@@ -492,10 +464,10 @@ int hibernation_snapshot(int platform_mode)
 	platform_end(platform_mode);
 	return error;
 
+ Complete:
+	dpm_complete(PMSG_RECOVER);
  Thaw:
 	thaw_kernel_threads();
- Cleanup:
-	swsusp_free();
 	goto Close;
 }
 

---
base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
change-id: 20260321-hibernation-fixes-69bca2ee5b65

Best regards,
--  
Matt

Re: [PATCH v3] PM: hibernate: call preallocate_image after freeze prepare

[Mario Limonciello]

On 4/3/26 2:36 AM, Matthew Leach wrote:
> [You don't often get email from matthew.leach@collabora.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> 
> Certain drivers release resources (pinned pages, etc.) into system
> memory during the prepare freeze PM op, making them swappable.
> Currently, hibernate_preallocate_memory is called before prepare freeze,
> so those drivers have no opportunity to release resources first. If a
> driver is holding a large amount of unswappable system RAM, this can
> cause hibernate_preallocate_memory to fail.
> 
> Move the call to hibernate_preallocate_memory after prepare freeze.
> According to the documentation for the prepare callback, devices should
> be left in a usable state, so storage drivers should still be able to
> service I/O requests. This allows drivers to release unswappable
> resources prior to preallocation, so they can be swapped out through
> hibernate_preallocate_memory's reclaim path. Also remove
> shrink_shmem_memory since hibernate_preallocate_memory will have
> reclaimed enough memory for the hibernation image.
> 
> Signed-off-by: Matthew Leach <matthew.leach@collabora.com>
LGTM.

Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
> ---
> Changes in v3:
> - Changed error label names to 'Thaw' and 'Complete'.
> - Link to v2: https://patch.msgid.link/20260326-hibernation-fixes-v2-1-f6707d82b7b9@collabora.com
> 
> Changes in v2:
> - Removed shrink_shmem_memory.
> - Fixed missing call to dpm_prepare in error path.
> - Link to v1: https://lore.kernel.org/r/20260321-hibernation-fixes-v1-1-5fe9637b6ff9@collabora.com
> ---
>   kernel/power/hibernate.c | 46 +++++++++-------------------------------------
>   1 file changed, 9 insertions(+), 37 deletions(-)
> 
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index af8d07bafe02..d2479c69d71a 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -392,23 +392,6 @@ static int create_image(int platform_mode)
>          return error;
>   }
> 
> -static void shrink_shmem_memory(void)
> -{
> -       struct sysinfo info;
> -       unsigned long nr_shmem_pages, nr_freed_pages;
> -
> -       si_meminfo(&info);
> -       nr_shmem_pages = info.sharedram; /* current page count used for shmem */
> -       /*
> -        * The intent is to reclaim all shmem pages. Though shrink_all_memory() can
> -        * only reclaim about half of them, it's enough for creating the hibernation
> -        * image.
> -        */
> -       nr_freed_pages = shrink_all_memory(nr_shmem_pages);
> -       pr_debug("requested to reclaim %lu shmem pages, actually freed %lu pages\n",
> -                       nr_shmem_pages, nr_freed_pages);
> -}
> -
>   /**
>    * hibernation_snapshot - Quiesce devices and create a hibernation image.
>    * @platform_mode: If set, use platform driver to prepare for the transition.
> @@ -425,14 +408,9 @@ int hibernation_snapshot(int platform_mode)
>          if (error)
>                  goto Close;
> 
> -       /* Preallocate image memory before shutting down devices. */
> -       error = hibernate_preallocate_memory();
> -       if (error)
> -               goto Close;
> -
>          error = freeze_kernel_threads();
>          if (error)
> -               goto Cleanup;
> +               goto Close;
> 
>          if (hibernation_test(TEST_FREEZER)) {
> 
> @@ -445,19 +423,13 @@ int hibernation_snapshot(int platform_mode)
>          }
> 
>          error = dpm_prepare(PMSG_FREEZE);
> -       if (error) {
> -               dpm_complete(PMSG_RECOVER);
> -               goto Thaw;
> -       }
> +       if (error)
> +               goto Complete;
> 
> -       /*
> -        * Device drivers may move lots of data to shmem in dpm_prepare(). The shmem
> -        * pages will use lots of system memory, causing hibernation image creation
> -        * fail due to insufficient free memory.
> -        * This call is to force flush the shmem pages to swap disk and reclaim
> -        * the system memory so that image creation can succeed.
> -        */
> -       shrink_shmem_memory();
> +       /* Preallocate image memory before shutting down devices. */
> +       error = hibernate_preallocate_memory();
> +       if (error)
> +               goto Complete;
> 
>          console_suspend_all();
>          pm_restrict_gfp_mask();
> @@ -492,10 +464,10 @@ int hibernation_snapshot(int platform_mode)
>          platform_end(platform_mode);
>          return error;
> 
> + Complete:
> +       dpm_complete(PMSG_RECOVER);
>    Thaw:
>          thaw_kernel_threads();
> - Cleanup:
> -       swsusp_free();
>          goto Close;
>   }
> 
> 
> ---
> base-commit: f338e77383789c0cae23ca3d48adcc5e9e137e3c
> change-id: 20260321-hibernation-fixes-69bca2ee5b65
> 
> Best regards,
> --
> Matt
> 

Re: [PATCH v3] PM: hibernate: call preallocate_image after freeze prepare

[Rafael J. Wysocki]

On Fri, Apr 3, 2026 at 9:36 AM Matthew Leach
<matthew.leach@collabora.com> wrote:
>
> Certain drivers release resources (pinned pages, etc.) into system
> memory during the prepare freeze PM op, making them swappable.
> Currently, hibernate_preallocate_memory is called before prepare freeze,
> so those drivers have no opportunity to release resources first. If a
> driver is holding a large amount of unswappable system RAM, this can
> cause hibernate_preallocate_memory to fail.
>
> Move the call to hibernate_preallocate_memory after prepare freeze.
> According to the documentation for the prepare callback, devices should
> be left in a usable state, so storage drivers should still be able to
> service I/O requests. This allows drivers to release unswappable
> resources prior to preallocation, so they can be swapped out through
> hibernate_preallocate_memory's reclaim path. Also remove
> shrink_shmem_memory since hibernate_preallocate_memory will have
> reclaimed enough memory for the hibernation image.
>
> Signed-off-by: Matthew Leach <matthew.leach@collabora.com>
> ---
> Changes in v3:
> - Changed error label names to 'Thaw' and 'Complete'.
> - Link to v2: https://patch.msgid.link/20260326-hibernation-fixes-v2-1-f6707d82b7b9@collabora.com
>
> Changes in v2:
> - Removed shrink_shmem_memory.
> - Fixed missing call to dpm_prepare in error path.
> - Link to v1: https://lore.kernel.org/r/20260321-hibernation-fixes-v1-1-5fe9637b6ff9@collabora.com
> ---
>  kernel/power/hibernate.c | 46 +++++++++-------------------------------------
>  1 file changed, 9 insertions(+), 37 deletions(-)
>
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index af8d07bafe02..d2479c69d71a 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -392,23 +392,6 @@ static int create_image(int platform_mode)
>         return error;
>  }
>
> -static void shrink_shmem_memory(void)
> -{
> -       struct sysinfo info;
> -       unsigned long nr_shmem_pages, nr_freed_pages;
> -
> -       si_meminfo(&info);
> -       nr_shmem_pages = info.sharedram; /* current page count used for shmem */
> -       /*
> -        * The intent is to reclaim all shmem pages. Though shrink_all_memory() can
> -        * only reclaim about half of them, it's enough for creating the hibernation
> -        * image.
> -        */
> -       nr_freed_pages = shrink_all_memory(nr_shmem_pages);
> -       pr_debug("requested to reclaim %lu shmem pages, actually freed %lu pages\n",
> -                       nr_shmem_pages, nr_freed_pages);
> -}
> -
>  /**
>   * hibernation_snapshot - Quiesce devices and create a hibernation image.
>   * @platform_mode: If set, use platform driver to prepare for the transition.
> @@ -425,14 +408,9 @@ int hibernation_snapshot(int platform_mode)
>         if (error)
>                 goto Close;
>
> -       /* Preallocate image memory before shutting down devices. */
> -       error = hibernate_preallocate_memory();
> -       if (error)
> -               goto Close;
> -
>         error = freeze_kernel_threads();
>         if (error)
> -               goto Cleanup;
> +               goto Close;
>
>         if (hibernation_test(TEST_FREEZER)) {
>
> @@ -445,19 +423,13 @@ int hibernation_snapshot(int platform_mode)
>         }
>
>         error = dpm_prepare(PMSG_FREEZE);
> -       if (error) {
> -               dpm_complete(PMSG_RECOVER);
> -               goto Thaw;
> -       }
> +       if (error)
> +               goto Complete;
>
> -       /*
> -        * Device drivers may move lots of data to shmem in dpm_prepare(). The shmem
> -        * pages will use lots of system memory, causing hibernation image creation
> -        * fail due to insufficient free memory.
> -        * This call is to force flush the shmem pages to swap disk and reclaim
> -        * the system memory so that image creation can succeed.
> -        */
> -       shrink_shmem_memory();
> +       /* Preallocate image memory before shutting down devices. */
> +       error = hibernate_preallocate_memory();
> +       if (error)
> +               goto Complete;
>
>         console_suspend_all();
>         pm_restrict_gfp_mask();
> @@ -492,10 +464,10 @@ int hibernation_snapshot(int platform_mode)
>         platform_end(platform_mode);
>         return error;
>
> + Complete:
> +       dpm_complete(PMSG_RECOVER);
>   Thaw:
>         thaw_kernel_threads();
> - Cleanup:
> -       swsusp_free();
>         goto Close;
>  }
>
>
> ---

Can you please have a look at

https://sashiko.dev/#/patchset/20260403-hibernation-fixes-v3-1-31bc9fa3ba2d%40collabora.com

and let me know what you think?

Re: [PATCH v3] PM: hibernate: call preallocate_image after freeze prepare

[Matthew Leach]

Hi Rafael,

"Rafael J. Wysocki" <rafael@kernel.org> writes:

> On Fri, Apr 3, 2026 at 9:36 AM Matthew Leach
> <matthew.leach@collabora.com> wrote:
>>

[...]

> Can you please have a look at
>
> https://sashiko.dev/#/patchset/20260403-hibernation-fixes-v3-1-31bc9fa3ba2d%40collabora.com

[pasting comment in-line here for comment]

> Does this relocation introduce a deadlock during memory reclaim?
> 
> hibernate_preallocate_memory() allocates a large amount of memory and
> triggers direct reclaim. Direct reclaim needs to write back dirty file
> pages and swap out anonymous pages.
> 
> Since freeze_kernel_threads() just ran, threads required for I/O
> completion (like kswapd, jbd2 for Ext4, or WQ_FREEZABLE workqueues) are
> currently frozen. Will the I/O for page reclaim block indefinitely
> waiting on these frozen threads?

The existing code already performs a memory reclaim after
freeze_kernel_threads(). The old shrink_shmem_memory() called
shrink_all_memory() in the same position, after both
freeze_kernel_threads() and dpm_prepare(). This isn't a new pattern
being introduced by this patch.

Nevertheless, the call chain looks like:

shrink_all_memory()
  -> do_try_to_free_pages()
    -> shrink_zones()
      -> shrink_node()
        -> shrink_folio_list()
          -> pageout()

pageout() only writes back shmem and anonymous folios to swap; so jdb2
and other FS threads being frozen isn't a concern. For the swap write
out, the I/O submission path is via submit_bio() which is also
synchronous.

> Additionally, because the OOM killer is already disabled by
> freeze_processes() earlier in the hibernation path, can the reclaim path
> get stuck permanently without being able to fall back to killing
> processes?

There's nothing new here regarding the OOM killer. freeze_processes()
disables it in hibernate() prior to calling hibernation_snapshot().
Since this patch is entirely contained within hibernation_snapshot()
that pattern hasn't changed.

Regards,
-- 
Matt

Re: [PATCH v3] PM: hibernate: call preallocate_image after freeze prepare

[Matthew Leach]

Hi Rafael,

Matthew Leach <matthew.leach@collabora.com> writes:

> Hi Rafael,
>
> "Rafael J. Wysocki" <rafael@kernel.org> writes:
>
>> On Fri, Apr 3, 2026 at 9:36 AM Matthew Leach
>> <matthew.leach@collabora.com> wrote:
>>>
>
> [...]
>
>> Can you please have a look at
>>
>> https://sashiko.dev/#/patchset/20260403-hibernation-fixes-v3-1-31bc9fa3ba2d%40collabora.com
>
> [pasting comment in-line here for comment]
>
>
>> Does this relocation introduce a deadlock during memory reclaim?
>> 
>> hibernate_preallocate_memory() allocates a large amount of memory and
>> triggers direct reclaim. Direct reclaim needs to write back dirty file
>> pages and swap out anonymous pages.
>> 
>> Since freeze_kernel_threads() just ran, threads required for I/O
>> completion (like kswapd, jbd2 for Ext4, or WQ_FREEZABLE workqueues) are
>> currently frozen. Will the I/O for page reclaim block indefinitely
>> waiting on these frozen threads?
>
> The existing code already performs a memory reclaim after
> freeze_kernel_threads(). The old shrink_shmem_memory() called
> shrink_all_memory() in the same position, after both
> freeze_kernel_threads() and dpm_prepare(). This isn't a new pattern
> being introduced by this patch.
>
> Nevertheless, the call chain looks like:
>
> shrink_all_memory()
>   -> do_try_to_free_pages()
>     -> shrink_zones()
>       -> shrink_node()
>         -> shrink_folio_list()
>           -> pageout()
>
> pageout() only writes back shmem and anonymous folios to swap; so jdb2
> and other FS threads being frozen isn't a concern. For the swap write
> out, the I/O submission path is via submit_bio() which is also
> synchronous.
>
>> Additionally, because the OOM killer is already disabled by
>> freeze_processes() earlier in the hibernation path, can the reclaim path
>> get stuck permanently without being able to fall back to killing
>> processes?
>
> There's nothing new here regarding the OOM killer. freeze_processes()
> disables it in hibernate() prior to calling hibernation_snapshot().
> Since this patch is entirely contained within hibernation_snapshot()
> that pattern hasn't changed.
>

Quick ping on this. Any throughts on the responses, or anything else
you'd like me to dig into?

Regards,
-- 
Matt

Re: [PATCH v3] PM: hibernate: call preallocate_image after freeze prepare

[Rafael J. Wysocki]

On Mon, May 18, 2026 at 3:37 PM Matthew Leach
<matthew.leach@collabora.com> wrote:
>
> Hi Rafael,
>
> Matthew Leach <matthew.leach@collabora.com> writes:
>
> > Hi Rafael,
> >
> > "Rafael J. Wysocki" <rafael@kernel.org> writes:
> >
> >> On Fri, Apr 3, 2026 at 9:36 AM Matthew Leach
> >> <matthew.leach@collabora.com> wrote:
> >>>
> >
> > [...]
> >
> >> Can you please have a look at
> >>
> >> https://sashiko.dev/#/patchset/20260403-hibernation-fixes-v3-1-31bc9fa3ba2d%40collabora.com
> >
> > [pasting comment in-line here for comment]
> >
> >
> >> Does this relocation introduce a deadlock during memory reclaim?
> >>
> >> hibernate_preallocate_memory() allocates a large amount of memory and
> >> triggers direct reclaim. Direct reclaim needs to write back dirty file
> >> pages and swap out anonymous pages.
> >>
> >> Since freeze_kernel_threads() just ran, threads required for I/O
> >> completion (like kswapd, jbd2 for Ext4, or WQ_FREEZABLE workqueues) are
> >> currently frozen. Will the I/O for page reclaim block indefinitely
> >> waiting on these frozen threads?
> >
> > The existing code already performs a memory reclaim after
> > freeze_kernel_threads(). The old shrink_shmem_memory() called
> > shrink_all_memory() in the same position, after both
> > freeze_kernel_threads() and dpm_prepare(). This isn't a new pattern
> > being introduced by this patch.
> >
> > Nevertheless, the call chain looks like:
> >
> > shrink_all_memory()
> >   -> do_try_to_free_pages()
> >     -> shrink_zones()
> >       -> shrink_node()
> >         -> shrink_folio_list()
> >           -> pageout()
> >
> > pageout() only writes back shmem and anonymous folios to swap; so jdb2
> > and other FS threads being frozen isn't a concern. For the swap write
> > out, the I/O submission path is via submit_bio() which is also
> > synchronous.
> >
> >> Additionally, because the OOM killer is already disabled by
> >> freeze_processes() earlier in the hibernation path, can the reclaim path
> >> get stuck permanently without being able to fall back to killing
> >> processes?
> >
> > There's nothing new here regarding the OOM killer. freeze_processes()
> > disables it in hibernate() prior to calling hibernation_snapshot().
> > Since this patch is entirely contained within hibernation_snapshot()
> > that pattern hasn't changed.
> >
>
> Quick ping on this. Any throughts on the responses, or anything else
> you'd like me to dig into?

Sorry for the delay, let me have a look at this again.

Re: [PATCH v3] PM: hibernate: call preallocate_image after freeze prepare

[Rafael J. Wysocki]

On Mon, May 18, 2026 at 3:44 PM Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Mon, May 18, 2026 at 3:37 PM Matthew Leach
> <matthew.leach@collabora.com> wrote:
> >
> > Hi Rafael,
> >
> > Matthew Leach <matthew.leach@collabora.com> writes:
> >
> > > Hi Rafael,
> > >
> > > "Rafael J. Wysocki" <rafael@kernel.org> writes:
> > >
> > >> On Fri, Apr 3, 2026 at 9:36 AM Matthew Leach
> > >> <matthew.leach@collabora.com> wrote:
> > >>>
> > >
> > > [...]
> > >
> > >> Can you please have a look at
> > >>
> > >> https://sashiko.dev/#/patchset/20260403-hibernation-fixes-v3-1-31bc9fa3ba2d%40collabora.com
> > >
> > > [pasting comment in-line here for comment]
> > >
> > >
> > >> Does this relocation introduce a deadlock during memory reclaim?
> > >>
> > >> hibernate_preallocate_memory() allocates a large amount of memory and
> > >> triggers direct reclaim. Direct reclaim needs to write back dirty file
> > >> pages and swap out anonymous pages.
> > >>
> > >> Since freeze_kernel_threads() just ran, threads required for I/O
> > >> completion (like kswapd, jbd2 for Ext4, or WQ_FREEZABLE workqueues) are
> > >> currently frozen. Will the I/O for page reclaim block indefinitely
> > >> waiting on these frozen threads?
> > >
> > > The existing code already performs a memory reclaim after
> > > freeze_kernel_threads(). The old shrink_shmem_memory() called
> > > shrink_all_memory() in the same position, after both
> > > freeze_kernel_threads() and dpm_prepare(). This isn't a new pattern
> > > being introduced by this patch.
> > >
> > > Nevertheless, the call chain looks like:
> > >
> > > shrink_all_memory()
> > >   -> do_try_to_free_pages()
> > >     -> shrink_zones()
> > >       -> shrink_node()
> > >         -> shrink_folio_list()
> > >           -> pageout()
> > >
> > > pageout() only writes back shmem and anonymous folios to swap; so jdb2
> > > and other FS threads being frozen isn't a concern. For the swap write
> > > out, the I/O submission path is via submit_bio() which is also
> > > synchronous.
> > >
> > >> Additionally, because the OOM killer is already disabled by
> > >> freeze_processes() earlier in the hibernation path, can the reclaim path
> > >> get stuck permanently without being able to fall back to killing
> > >> processes?
> > >
> > > There's nothing new here regarding the OOM killer. freeze_processes()
> > > disables it in hibernate() prior to calling hibernation_snapshot().
> > > Since this patch is entirely contained within hibernation_snapshot()
> > > that pattern hasn't changed.
> > >
> >
> > Quick ping on this. Any throughts on the responses, or anything else
> > you'd like me to dig into?
>
> Sorry for the delay, let me have a look at this again.

Applied as 7.2 material, thanks!