Hi Christoph,
On 2024-05-27 20:20, Christoph Hellwig wrote:
> On Mon, May 27, 2024 at 11:06:11AM +0000, Sukrit.Bhatnagar@xxxxxxxx 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
