RE: [PATCH 0/2] Improve dmesg output for swapfile+hibernation
From: Sukrit.Bhatnagar@xxxxxxxx
Date: Fri May 31 2024 - 10:17:04 EST
On 2024-05-27 21:58, Christoph Hellwig wrote:
> On Mon, May 27, 2024 at 12:51:07PM +0000, Sukrit.Bhatnagar@xxxxxxxx wrote:
>> In my understanding, the resume offset in hibernate is used as follows.
>>
>> Suspend
>> - Hibernate looks up the swap/swapfile using the details we pass in the
>> sysfs entries, in the function swsusp_swap_check():
>> * /sys/power/resume - path/uuid/major:minor of the swap partition (or
>> non-swap partition for swapfile)
>> * /sys/power/resume_offset - physical offset of the swapfile in that
>> partition
>> * If no resume device is specified, it just uses the first available
>> swap! - It then proceeds to write the image to the specified swap.
>> (The allocation of swap pages is done by the swapfile code
>> internally.)
>
> Where "it" is userspace code? If so, that already seems unsafe for
> a swap device, but definitely is a no-go for a swapfile.
By "it", I meant the hibernate code running in kernel space.
Once userspace triggers hibernation by `echo disk > /sys/power/state`
or a systemd wrapper program etc., and userspace tasks are frozen,
everything happens within kernel context.
>> - Hibernate gets the partition and offset values from kernel command-line
>> parameters "resume" and "resume_offset" (which must be set from
>> userspace, not ideal).
>
> Or is it just for these parameters? In which case we "only" need to
> specify the swap file, which would then need code in the file system
> driver to resolve the logical to physical mapping as swap files don't
> need to be contiguous.
Yes, it is just for setting these parameters in sysfs entries and in kernel
commandline.
I think specifying the swapfile path *may* not work because when we resume
from hibernation, the filesystems are not yet mounted (except for the case
when someone is resuming from initramfs stage).
Using the block device + physical offset, this procedure becomes Independent
of the filesystem and the mounted status.
And since the system swap information is lost on reboot/shutdown, the kernel
which loads the hibernation image will not know what swaps were enabled
when the image was created.
--
Sukrit