linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: YoungJun Park <youngjun.park@lge.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Rafael J . Wysocki" <rafael@kernel.org>,
	Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>,
	Pavel Machek <pavel@kernel.org>,
	Kemeng Shi <shikemeng@huaweicloud.com>,
	Nhat Pham <nphamcs@gmail.com>, Baoquan He <bhe@redhat.com>,
	Barry Song <baohua@kernel.org>, Usama Arif <usama.arif@linux.dev>,
	linux-pm@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v8 0/2] mm/swap, PM: hibernate: fix swapoff race in uswsusp by pinning swap device
Date: Tue, 24 Mar 2026 11:51:12 +0900	[thread overview]
Message-ID: <acH8IKWyv9gW9YFU@yjaykim-PowerEdge-T330> (raw)
In-Reply-To: <20260323154833.045b732a5865b11b5b4e539e@linux-foundation.org>

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


  reply	other threads:[~2026-03-24  2:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-23 16:08 Youngjun Park
2026-03-23 16:08 ` [PATCH v8 1/2] " Youngjun Park
2026-03-24  5:53   ` Kairui Song
2026-03-24 12:48     ` YoungJun Park
2026-03-23 16:08 ` [PATCH v8 2/2] mm/swap: remove redundant swap device reference in alloc/free Youngjun Park
2026-03-24  6:49   ` Kairui Song
2026-03-23 22:48 ` [PATCH v8 0/2] mm/swap, PM: hibernate: fix swapoff race in uswsusp by pinning swap device Andrew Morton
2026-03-24  2:51   ` YoungJun Park [this message]
2026-03-24  3:03     ` Andrew Morton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=acH8IKWyv9gW9YFU@yjaykim-PowerEdge-T330 \
    --to=youngjun.park@lge.com \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=bhe@redhat.com \
    --cc=chrisl@kernel.org \
    --cc=kasong@tencent.com \
    --cc=linux-mm@kvack.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=nphamcs@gmail.com \
    --cc=pavel@kernel.org \
    --cc=rafael@kernel.org \
    --cc=shikemeng@huaweicloud.com \
    --cc=usama.arif@linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox