Re: [PATCH v8 0/2] mm/swap, PM: hibernate: fix swapoff race in uswsusp by pinning swap device

YoungJun Park
2026-03-24T02:51:20Z

On Mon, Mar 23, 2026 at 03:48:33PM -0700, Andrew Morton wrote:
> On Tue, 24 Mar 2026 01:08:20 +0900 Youngjun Park <youngjun.park@lge.com> wrote:
>
> > Rebased onto mm-new per Andrew's suggestion [1]. The si->flags race
> > flagged by AI review in v7 (between SWP_HIBERNATION and cont_lock in
> > add_swap_count_continuation) and the proposed fixes discussed there
> > (atomic ops for si->flags, or serializing with swap_lock) are all moot
> > on mm-new since Kairui's series removed that code path entirely.
> > kernel/power/ changes are small, so Andrew proposed carrying everything
> > through mm-new.
> >
> > Rafael, could you ack the PM-side changes?
>
> Please.
>
> We'll hit a conflict in linux-next and Mark will tell us and we can
> flag that to Linus when merging into mainline, usual stuff.
>
> Or we can park this until the next cycle, depends on how serious the
> bug is. How serious is the bug?

Hi Andrew,

In my opinion, this bug is unlikely to occur and does not appear to be serious.
It may be better to park this for the next cycle.

I verified the behavior using suspend-utils. Below is a recap of the
reproduction scenarios I mentioned earlier in more detail.

Pre-condition
- swapon /dev/sdb (intended for hibernation)

Case 1

Process 1 (test program) Process 2
--------------------------- ----------------
ioctl(SNAPSHOT_SET_SWAP_AREA)
swapoff /dev/sdb
ioctl(SNAPSHOT_ALLOC_SWAP_PAGE)

- SNAPSHOT_ALLOC_SWAP_PAGE fails with -ENOSPC.
- The race window where swapoff /dev/sdb can occur is extremely
small, and such an intentional sequence is unlikely in practice.
- If SNAPSHOT_ALLOC_SWAP_PAGE succeeds, swapoff does not occur.

Case 2

Process 1 (test program) Process 2
--------------------------- ----------------
ioctl(SNAPSHOT_SET_SWAP_AREA)
swapoff /dev/sdb
swapon /dev/sdc
freeze processes
ioctl(SNAPSHOT_ALLOC_SWAP_PAGE)
create snapshot image

- In testing, snapshot boot from /dev/sdb succeeds.
- The swap block offset may be taken from an unexpected device,
but I/O to /dev/sdb itself succeeds.
- Since the actual allocated swap offset is not used for writing
the snapshot image, there is a theoretical risk of corruption if
I/O occurs at that offset on /dev/sdb during the window.
However, Processes are frozen before writing the snapshot image to /dev/sdb.
Therefore, while the issue is theoretically possible, the
probability of it occurring in practice appears extremely low.

Best regards,
Youngjun Park