From: "Zi Yan" <ziy@nvidia.com>
To: "Kairui Song" <ryncsn@gmail.com>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
"David Hildenbrand" <david@kernel.org>,
"Lorenzo Stoakes" <ljs@kernel.org>,
"Baolin Wang" <baolin.wang@linux.alibaba.com>,
"Liam R. Howlett" <liam@infradead.org>,
"Nico Pache" <nico.pache@linux.dev>,
"Ryan Roberts" <ryan.roberts@arm.com>,
"Dev Jain" <dev.jain@arm.com>,
"Lance Yang" <lance.yang@linux.dev>,
"Usama Arif" <usama.arif@linux.dev>,
"Vlastimil Babka" <vbabka@kernel.org>,
"Mike Rapoport" <rppt@kernel.org>,
"Suren Baghdasaryan" <surenb@google.com>,
"Michal Hocko" <mhocko@suse.com>, "Chris Li" <chrisl@kernel.org>,
"Kemeng Shi" <shikemeng@huaweicloud.com>,
"Nhat Pham" <nphamcs@gmail.com>,
"Baoquan He" <baoquan.he@linux.dev>,
"Barry Song" <baohua@kernel.org>,
"Youngjun Park" <youngjun.park@lge.com>
Subject: Re: [PATCH RFC 02/13] mm/huge_memory: fix rejection of swap cache folios with a mapping
Date: Sat, 08 Aug 2026 14:53:58 -0400 [thread overview]
Message-ID: <DKJSGGIVFJ93.23BV94A3F8JIP@nvidia.com> (raw)
In-Reply-To: <CAMgjq7AWE0nvoSqBvyU3id9BxLb1NRXcyPV_0yV6t_OTZ04V4g@mail.gmail.com>
On Sat Aug 8, 2026 at 2:14 PM EDT, Kairui Song wrote:
> On Sun, Aug 9, 2026 at 2:02 AM Zi Yan <ziy@nvidia.com> wrote:
>>
>> On Fri Aug 7, 2026 at 5:17 PM EDT, Kairui Song via B4 Relay wrote:
>> > From: Kairui Song <kasong@tencent.com>
>> >
>> > A folio in the swap cache cannot be split if it has a mapping (shmem).
>> > The split code only checks for this in __folio_freeze_and_split_unmapped,
>> > after the folio ref has been frozen and the NR_SHMEM_THPS/NR_FILE_THPS
>> > counters have been decremented, and returns -EINVAL without unfreezing
>> > the folio or restoring the counters. That error path is fragile: if it
>> > is ever taken, the folio is left frozen and stuck, the counters are
>> > skewed, and the VM_WARN_ON_ONCE_FOLIO would fire for a state that is
>> > actually legitimate.
>> >
>> > Check for this case up front in folio_check_splittable and return
>> > -EINVAL before any state is modified. Under DEBUG_VM, the existing
>> > "Tried to split an unsplittable folio" warning in __folio_split
>> > reports the rejection.
>>
>> Should we return -EBUSY instead? -EINVAL means the caller should not
>> split a swapcache shmem with a mapping and the caller needs to avoid
>> that. The Fixes tag tells me a caller can split a swapcache shmem with a
>> mapping, so with -EINVAL, we will want to add checks at callers to avoid
>> it from happening.
>>
>
> I can drop the Fixes tags. I meant that there is already some
If it can happen, we want to fix it.
> defensive code that trying to catch it and return -EINVAL, however,
> that defensive code itself is flawed. If this situation occurs due to
> a bug or future misuse, the flawed code will causes the folio to get
> stuck in a frozen state. The defensive code should at least not make
> things worse.
>
> Fortunately I think no one needs to split a hybrid shmem swap cache
> folio, returning -EINVAL here may help catch any potential future
> misuse.
Sounds reasonable to me.
--
Best Regards,
Yan, Zi
next prev parent reply other threads:[~2026-08-08 18:54 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 21:17 [PATCH RFC 00/13] mm/huge_memory: clean up folio split and lift swapcache split limits Kairui Song via B4 Relay
2026-08-07 21:17 ` Kairui Song
2026-08-07 21:17 ` [PATCH RFC 01/13] mm/swap: fix off-by-one in swap cache replace sanity check Kairui Song via B4 Relay
2026-08-07 21:17 ` Kairui Song
2026-08-08 17:07 ` Zi Yan
2026-08-07 21:17 ` [PATCH RFC 02/13] mm/huge_memory: fix rejection of swap cache folios with a mapping Kairui Song via B4 Relay
2026-08-07 21:17 ` Kairui Song
2026-08-08 18:01 ` Zi Yan
2026-08-08 18:14 ` Kairui Song
2026-08-08 18:53 ` Zi Yan [this message]
2026-08-07 21:17 ` [PATCH RFC 03/13] mm/huge_memory: invert folio_ref_freeze() check to reduce indentation Kairui Song via B4 Relay
2026-08-07 21:17 ` Kairui Song
2026-08-08 18:04 ` Zi Yan
2026-08-07 21:17 ` [PATCH RFC 04/13] mm/huge_memory: split the routine for splitting anon and file folio Kairui Song via B4 Relay
2026-08-07 21:17 ` Kairui Song
2026-08-08 18:52 ` Zi Yan
2026-08-08 20:19 ` Kairui Song
2026-08-07 21:17 ` [PATCH RFC 05/13] mm/huge_memory: consolidate irq and locking for folio split Kairui Song via B4 Relay
2026-08-07 21:17 ` Kairui Song
2026-08-09 1:54 ` Zi Yan
2026-08-10 3:35 ` Kairui Song
2026-08-07 21:17 ` [PATCH RFC 06/13] mm/huge_memory: move EOF trimming into the file split helper Kairui Song via B4 Relay
2026-08-07 21:17 ` Kairui Song
2026-08-09 1:59 ` Zi Yan
2026-08-07 21:17 ` [PATCH RFC 07/13] mm/huge_memory: move unmap and remap into the split helpers Kairui Song via B4 Relay
2026-08-07 21:17 ` Kairui Song
2026-08-09 2:13 ` Zi Yan
2026-08-07 21:17 ` [PATCH RFC 08/13] mm/huge_memory: move anon_vma and filemap management into " Kairui Song via B4 Relay
2026-08-07 21:17 ` Kairui Song
2026-08-09 2:22 ` Zi Yan
2026-08-07 21:17 ` [PATCH RFC 09/13] mm/huge_memory: move memcg switch into the file split helper Kairui Song via B4 Relay
2026-08-07 21:17 ` Kairui Song
2026-08-09 2:29 ` Zi Yan
2026-08-07 21:17 ` [PATCH RFC 10/13] mm/huge_memory: allow splitting mappingless swap cache folios Kairui Song via B4 Relay
2026-08-07 21:17 ` Kairui Song
2026-08-09 2:35 ` Zi Yan
2026-08-07 21:17 ` [PATCH RFC 11/13] mm/huge_memory: clean up after-split folio freeing in __folio_split Kairui Song via B4 Relay
2026-08-07 21:17 ` Kairui Song
2026-08-09 2:41 ` Zi Yan
2026-08-07 21:17 ` [PATCH RFC 12/13] mm/huge_memory: lift order-0 restriction for swapcache split Kairui Song via B4 Relay
2026-08-07 21:17 ` Kairui Song
2026-08-09 2:46 ` Zi Yan
2026-08-07 21:17 ` [PATCH RFC 13/13] mm/huge_memory: count only swap cache refs in anon folio split Kairui Song via B4 Relay
2026-08-07 21:17 ` Kairui Song
2026-08-09 2:49 ` Zi Yan
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=DKJSGGIVFJ93.23BV94A3F8JIP@nvidia.com \
--to=ziy@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=baoquan.he@linux.dev \
--cc=chrisl@kernel.org \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=nico.pache@linux.dev \
--cc=nphamcs@gmail.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=ryncsn@gmail.com \
--cc=shikemeng@huaweicloud.com \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.