From: Askar Safin <safinaskar@gmail.com>
To: mpatocka@redhat.com
Cc: dm-devel@lists.linux.dev, linux-block@vger.kernel.org,
linux-lvm@lists.linux.dev, linux-mm@kvack.org,
linux-pm@vger.kernel.org, linux-raid@vger.kernel.org,
lvm-devel@lists.linux.dev, rafael@kernel.org,
Milan Broz <gmazyland@gmail.com>,
linux-fsdevel@vger.kernel.org,
James Bottomley <James.Bottomley@hansenpartnership.com>,
Luis Chamberlain <mcgrof@kernel.org>,
Christian Brauner <brauner@kernel.org>
Subject: Re: [RFC PATCH 2/2] swsusp: make it possible to hibernate to device mapper devices
Date: Sun, 30 Nov 2025 03:56:56 +0300 [thread overview]
Message-ID: <20251130005656.3644711-1-safinaskar@gmail.com> (raw)
In-Reply-To: <b32d0701-4399-9c5d-ecc8-071162df97a7@redhat.com>
Mikulas Patocka <mpatocka@redhat.com>:
https://lore.kernel.org/linux-pm/b32d0701-4399-9c5d-ecc8-071162df97a7@redhat.com/ :
> Askar Safin requires swap and hibernation on the dm-integrity device mapper
> target because he needs to protect his data.
>
> This hits two problems:
> 1. The kernel doesn't send the flush bio to the hibernation device after
> writing the image and before powering off - this is easy to fix
> 2. The dm-integrity target keeps parts of the device in-memory - it keeps
> a journal and a dm-bufio cache in memory. If we hibernate and resume,
> the content of memory no longer matches the data on the hibernate
> partition and that may cause spurious errors - this is hard to fix
Let me add some more info on this patchset.
First of all, I already solved the problem for me personally:
I wrote hackish patch, which fixes the problem. My patch is tested on
my real hardware under load. I successfully use it for 2 weeks
(I hibernated a lot of times during this period.)
The patch is absolutely rock solid, and I absolutely sure it is correct.
Unfortunately, it is not generic, it is tied to my particular configuration,
it hard codes paths (!!!), and hence is non-upstreamable.
Here is this patch for your information:
https://zerobin.net/?ad6142bd67df015a#68Az6yBUxHA3AXB7jY1+clSRnR745olFHAByxwPGM08= .
Feel free to use code from it.
So I personally is not in hurry, I already have solution, which works for me.
(But I am still available for testing.)
Your patch has a problem: after "notify_swap_device" call, the pages can
still be swapped out. "pm_restrict_gfp_mask" call in "hibernation_snapshot"
prevents further swapping. Thus "notify_swap_device" should be called
after "pm_restrict_gfp_mask" (but read on).
I attempted to create test case, which would expose this problem. And I was
unable to do so. Still I believe this is a real problem.
Also, our problem is very similar to reason of introducing "filesystems_freeze"
( https://elixir.bootlin.com/linux/v6.18-rc7/source/kernel/power/hibernate.c#L824 ).
See problem description here:
https://lore.kernel.org/all/0a76e074ef262ca857c61175dd3d0dc06b67ec42.camel@HansenPartnership.com/ .
See also https://lwn.net/Articles/1018341/ .
(See also this huge thread
https://lore.kernel.org/all/20250327140613.25178-1-James.Bottomley@HansenPartnership.com/ .)
"filesystems_freeze" logic is already implemented in mainline. It is gated
behind /sys/power/freeze_filesystems .
As you can see, authors of "filesystems_freeze" attempted to solve similar
problem. Thus, we should probably flush buffers in "filesystems_freeze" call.
Ideally, flushing of dm-integrity should be correctly ordered with freezing of filesystems
to support complex storage hierarchies (i. e. swap on dm-integrity on loop
device on some filesystem, etc).
But... call to "filesystems_freeze" happens before "pm_restrict_gfp_mask" call.
So... in this point I gave up, and I don't know what to do (i. e. what the upstream
kernel should do).
Feel free to ask any questions.
I changed CCs for further exposure.
--
Askar Safin
next prev parent reply other threads:[~2025-11-30 0:57 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-23 11:29 dm bug: hibernate to swap located on dm-integrity doesn't work (how to get data redundancy for swap?) Askar Safin
2025-10-23 20:42 ` Milan Broz
2025-10-24 16:31 ` Askar Safin
2025-10-24 17:50 ` Milan Broz
2025-10-25 5:26 ` Askar Safin
2025-10-27 8:08 ` Askar Safin
[not found] ` <4cd2d217-f97d-4923-b852-4f8746456704@mazyland.cz>
2025-10-24 10:23 ` [PATCH] pm-hibernate: flush block device cache when hibernating Mikulas Patocka
2025-10-27 8:42 ` Askar Safin
2025-10-31 19:29 ` Mikulas Patocka
2025-10-31 19:33 ` [PATCH 1/2] pm-hibernate: flush disk cache when suspending Mikulas Patocka
2025-11-03 15:53 ` Askar Safin
2025-11-22 13:51 ` Milan Broz
2025-11-22 20:33 ` Askar Safin
2025-11-22 22:47 ` Askar Safin
2025-11-24 19:51 ` Mikulas Patocka
2025-10-31 19:35 ` [RFC PATCH 2/2] swsusp: make it possible to hibernate to device mapper devices Mikulas Patocka
2025-11-30 0:56 ` Askar Safin [this message]
2025-10-29 13:31 ` [PATCH] pm-hibernate: flush block device cache when hibernating Rafael J. Wysocki
2025-10-29 14:38 ` Christoph Hellwig
2025-10-29 16:31 ` Mikulas Patocka
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=20251130005656.3644711-1-safinaskar@gmail.com \
--to=safinaskar@gmail.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=brauner@kernel.org \
--cc=dm-devel@lists.linux.dev \
--cc=gmazyland@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-lvm@lists.linux.dev \
--cc=linux-mm@kvack.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=lvm-devel@lists.linux.dev \
--cc=mcgrof@kernel.org \
--cc=mpatocka@redhat.com \
--cc=rafael@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).