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

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

Hi Christoph,

On 2024-05-27 20:20, Christoph Hellwig wrote:
> On Mon, May 27, 2024 at 11:06:11AM +0000, Sukrit.Bhatnagar@sony.com wrote:
>> We can pass the starting physical block offset of a swapfile into
>> /sys/power/resume_offset, and hibernate can directly read/write
>> into it using the swap extents information created by iomap during
>> swapon. On resume, the kernel would read this offset value from
>> the commandline parameters, and then access the swapfile.
> 
> Reading a physical address from userspace is not a proper interface.
> What is this code even trying to do with it?

I understand your point. Ideally, the low-level stuff such as finding
the physical block offset should not be handled in the userspace.

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.)
- When writing is finished, the swap header needs to be updated with some
  metadata, in the function mark_swapfiles().
  * Hibernate creates bio requests to read/write the header (which is the
    first page of swap) using that physical block offset.

Resume
- Hibernate gets the partition and offset values from kernel command-line
  parameters "resume" and "resume_offset" (which must be set from
  userspace, not ideal).
- It checks for valid hibernate swap signature by reading the swap header.
  * Hibernate creates bio requests again, using the physical block offset,
    but the one from kernel command-line this time.
- Then it restores image and resumes into the previously saved kernel.

--
Sukrit