RE: [PATCH 0/2] Improve dmesg output for swapfile+hibernation

["Sukrit.Bhatnagar@sony.com" <Sukrit.Bhatnagar@sony.com>]

On 2024-05-27 21:58, Christoph Hellwig wrote:
> On Mon, May 27, 2024 at 12:51:07PM +0000, Sukrit.Bhatnagar@sony.com 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