From: Andrew Morton <akpm@linux-foundation.org>
To: Youngjun Park <youngjun.park@lge.com>
Cc: Chris Li <chrisl@kernel.org>, Kairui Song <kasong@tencent.com>,
Kemeng Shi <shikemeng@huaweicloud.com>,
Nhat Pham <nphamcs@gmail.com>, Baoquan He <baoquan.he@linux.dev>,
Barry Song <baohua@kernel.org>,
Jianyue Wu <wujianyue000@gmail.com>,
her0gyugyu@gmail.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/4] mm, swap: keep hibernation swap slots out of the swap cache
Date: Tue, 11 Aug 2026 11:46:22 -0700 [thread overview]
Message-ID: <20260811114622.6a04927b0c7ca0c2d6b39cce@linux-foundation.org> (raw)
In-Reply-To: <20260811132209.2862708-1-youngjun.park@lge.com>
On Tue, 11 Aug 2026 22:22:05 +0900 Youngjun Park <youngjun.park@lge.com> wrote:
> Cluster readahead walks a raw page_cluster sized window of offsets around
> the faulting entry. A hibernation slot looks like an ordinary swapped out
> slot, so __swap_cache_add_check() lets it in. Readahead reads the offset
> off the device into a folio and puts that folio in the swap table where the
> hibernation entry was. This has been possible for a long time. It only
> wasted a folio and a read.
>
> That changed with commit 0d6af9bcf383 ("mm, swap: use the swap table to
> track the swap count"). A slot with a folio in the swap cache should only
> be freed when the folio leaves the cache. swap_put_entries_cluster() still
> does that, but the conversion left swap_free_hibernation_slot() freeing the
> slot either way. Nothing points at the folio after that, and when reclaim
> drops it later, it writes to the table entry at the old offset, which
> someone else may own by then.
>
> Patch 1 is the fix and the only patch for stable. It puts the missing
> check back, so both free paths behave the same again.
Thanks.
When fixing things, please always take care to describe the
userspace-visible runtime effects of the bug, particularly when
proposing a -stable backport.
For [1/4] Gemini tells me "At a high level, this bug triggers silent
memory corruption, process crashes, or data instability across
completely unrelated userspace applications - typically occurring after a
system resumes from hibernation (suspend-to-disk)." Which is what I
figured too.
Do we have any reports of this? Reported-by/Closes?
I'd like to grab [1/4] only, and defer the other three until 7.3-rc1.
This might be mistaken, but from a quick read, it's not clear what
benefit those three patches offer our users.
And there's value in merging the backportable fix alone, to avoid the
risk that the other three patches accidentally fix misbehavior in
[1/4].
next prev parent reply other threads:[~2026-08-11 18:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-11 13:22 Youngjun Park
2026-08-11 13:22 ` [PATCH v3 1/4] mm, swap: don't free a hibernation slot that is in " Youngjun Park
2026-08-11 13:22 ` [PATCH v3 2/4] mm, swap: only allow swapped-out slots into " Youngjun Park
2026-08-11 13:22 ` [PATCH v3 3/4] mm, swap: give hibernation swap slots their own swap table entry type Youngjun Park
2026-08-11 16:48 ` Kairui Song
2026-08-11 13:22 ` [PATCH v3 4/4] mm, swap: drop the swap cache guard and reclaim in swap_free_hibernation_slot() Youngjun Park
2026-08-11 17:09 ` Kairui Song
2026-08-11 18:46 ` Andrew Morton [this message]
2026-08-12 12:13 ` [PATCH v3 0/4] mm, swap: keep hibernation swap slots out of the swap cache Youngjun Park
2026-08-12 20:56 ` 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=20260811114622.6a04927b0c7ca0c2d6b39cce@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baoquan.he@linux.dev \
--cc=chrisl@kernel.org \
--cc=her0gyugyu@gmail.com \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nphamcs@gmail.com \
--cc=shikemeng@huaweicloud.com \
--cc=wujianyue000@gmail.com \
--cc=youngjun.park@lge.com \
/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
all inboxes | Powered by JetHome®