mm/Kconfig | 14 ++ mm/Makefile | 1 + mm/huge_memory.c | 18 +- mm/tests/folio_split_kunit.c | 52 ++++ tools/testing/selftests/mm/Makefile | 2 + tools/testing/selftests/mm/run_vmtests.sh | 1 + .../selftests/mm/split_hwpoison_swapcache.sh | 57 +++++ .../selftests/mm/split_hwpoison_swapcache_test.c | 261 +++++++++++++++++++++ 8 files changed, 395 insertions(+), 11 deletions(-)
Large shmem folios lose their address-space mapping when they are written
to swap, but remain valid members of the swap cache. Folios read from swap
but not yet associated with an anon_vma can have the same mappingless
swapcache state. folio_check_splittable() currently mistakes both cases for
truncation and rejects the split with -EBUSY.
Implement the longstanding TODO for this state. Allow mappingless
swapcache folios to use the existing uniform order-0 swapcache split path,
while continuing to reject truly truncated folios and unsupported
higher-order or non-uniform swapcache splits.
memory_failure() is one caller affected by the restriction: it cannot
isolate a poisoned base page within a mappingless swapcache THP. The
end-to-end test uses this case to exercise the complete shmem pageout,
swapcache split, and swapin path.
The first patch contains the MM implementation. The second adds focused
KUnit coverage for the split eligibility checks. The third adds the
end-to-end hwpoison selftest, which pages out a shmem THP, poisons a tail
page, and verifies both isolation and the data read back from swap.
Tests:
- The split_hwpoison_swapcache kselftest passes under x86_64 QEMU
using virtme-ng 1.41 (2 GiB RAM, 4 KiB pages).
Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in>
---
Shivam Kalra (3):
mm/huge_memory: allow splitting mappingless swapcache folios
mm: add KUnit coverage for mappingless swapcache folios
selftests/mm: test hwpoison recovery of mappingless swapcache THPs
mm/Kconfig | 14 ++
mm/Makefile | 1 +
mm/huge_memory.c | 18 +-
mm/tests/folio_split_kunit.c | 52 ++++
tools/testing/selftests/mm/Makefile | 2 +
tools/testing/selftests/mm/run_vmtests.sh | 1 +
.../selftests/mm/split_hwpoison_swapcache.sh | 57 +++++
.../selftests/mm/split_hwpoison_swapcache_test.c | 261 +++++++++++++++++++++
8 files changed, 395 insertions(+), 11 deletions(-)
---
base-commit: 0b53bff4fa05ff0d3ffbd3d3bb10fae69dfab498
change-id: 20260722-b4-mappingless-swapcache-9badf123138a
Best regards,
--
Shivam Kalra <shivamkalra98@zohomail.in>
On 5 Aug 2026, at 7:18, Shivam Kalra via B4 Relay wrote: > Large shmem folios lose their address-space mapping when they are written > to swap, but remain valid members of the swap cache. Folios read from swap > but not yet associated with an anon_vma can have the same mappingless > swapcache state. folio_check_splittable() currently mistakes both cases for > truncation and rejects the split with -EBUSY. > > Implement the longstanding TODO for this state. Allow mappingless > swapcache folios to use the existing uniform order-0 swapcache split path, > while continuing to reject truly truncated folios and unsupported > higher-order or non-uniform swapcache splits. Thank you for your patches. As Kairui (cc’d) mentioned in [1] (see “A bit more details on this”), we might not need to implement this split. I will let Kairui to decide how we should deal with this patchset. [1] https://lore.kernel.org/all/CAMgjq7CHDG8JhesSPMkn1kzG8jKb0BXO756BvxMQC_MCn2eTyA@mail.gmail.com/ > > memory_failure() is one caller affected by the restriction: it cannot > isolate a poisoned base page within a mappingless swapcache THP. The > end-to-end test uses this case to exercise the complete shmem pageout, > swapcache split, and swapin path. > > The first patch contains the MM implementation. The second adds focused > KUnit coverage for the split eligibility checks. The third adds the > end-to-end hwpoison selftest, which pages out a shmem THP, poisons a tail > page, and verifies both isolation and the data read back from swap. > > Tests: > - The split_hwpoison_swapcache kselftest passes under x86_64 QEMU > using virtme-ng 1.41 (2 GiB RAM, 4 KiB pages). > > Signed-off-by: Shivam Kalra <shivamkalra98@zohomail.in> > --- > Shivam Kalra (3): > mm/huge_memory: allow splitting mappingless swapcache folios > mm: add KUnit coverage for mappingless swapcache folios > selftests/mm: test hwpoison recovery of mappingless swapcache THPs > > mm/Kconfig | 14 ++ > mm/Makefile | 1 + > mm/huge_memory.c | 18 +- > mm/tests/folio_split_kunit.c | 52 ++++ > tools/testing/selftests/mm/Makefile | 2 + > tools/testing/selftests/mm/run_vmtests.sh | 1 + > .../selftests/mm/split_hwpoison_swapcache.sh | 57 +++++ > .../selftests/mm/split_hwpoison_swapcache_test.c | 261 +++++++++++++++++++++ > 8 files changed, 395 insertions(+), 11 deletions(-) > --- > base-commit: 0b53bff4fa05ff0d3ffbd3d3bb10fae69dfab498 > change-id: 20260722-b4-mappingless-swapcache-9badf123138a > > Best regards, > -- > Shivam Kalra <shivamkalra98@zohomail.in> Best Regards, Yan, Zi
On Wed, Aug 05, 2026 at 08:03:33AM +0800, Zi Yan wrote: > On 5 Aug 2026, at 7:18, Shivam Kalra via B4 Relay wrote: > > > Large shmem folios lose their address-space mapping when they are written > > to swap, but remain valid members of the swap cache. Folios read from swap > > but not yet associated with an anon_vma can have the same mappingless > > swapcache state. folio_check_splittable() currently mistakes both cases for > > truncation and rejects the split with -EBUSY. > > > > Implement the longstanding TODO for this state. Allow mappingless > > swapcache folios to use the existing uniform order-0 swapcache split path, > > while continuing to reject truly truncated folios and unsupported > > higher-order or non-uniform swapcache splits. > > Thank you for your patches. > > As Kairui (cc’d) mentioned in [1] (see “A bit more details on this”), > we might not need to implement this split. I will let Kairui to decide > how we should deal with this patchset. > > [1] https://lore.kernel.org/all/CAMgjq7CHDG8JhesSPMkn1kzG8jKb0BXO756BvxMQC_MCn2eTyA@mail.gmail.com/ Thanks for the CC, this is actually not hard to implement as shown by Shivam, I just found the code more and more hard to follow and fragile as we add more logic to it. And we don't have to reject higher order split either which can be seen easily if the code is cleaner. Personally I think doing some cleanup first is better, I haven't post any code as right now there doesn't seem to be much user of this. It will be needed if more clean THP swapcache begin to show up due to things like THP readahead for swap, which isn't here yet. I think I can send an RFC tomorrow just for reference. I'm fine if we prefer to remove that TODO using this smaller change first :)
On Wed Aug 5, 2026 at 11:54 AM EDT, Kairui Song wrote: > On Wed, Aug 05, 2026 at 08:03:33AM +0800, Zi Yan wrote: >> On 5 Aug 2026, at 7:18, Shivam Kalra via B4 Relay wrote: >> >> > Large shmem folios lose their address-space mapping when they are written >> > to swap, but remain valid members of the swap cache. Folios read from swap >> > but not yet associated with an anon_vma can have the same mappingless >> > swapcache state. folio_check_splittable() currently mistakes both cases for >> > truncation and rejects the split with -EBUSY. >> > >> > Implement the longstanding TODO for this state. Allow mappingless >> > swapcache folios to use the existing uniform order-0 swapcache split path, >> > while continuing to reject truly truncated folios and unsupported >> > higher-order or non-uniform swapcache splits. >> >> Thank you for your patches. >> >> As Kairui (cc’d) mentioned in [1] (see “A bit more details on this”), >> we might not need to implement this split. I will let Kairui to decide >> how we should deal with this patchset. >> >> [1] https://lore.kernel.org/all/CAMgjq7CHDG8JhesSPMkn1kzG8jKb0BXO756BvxMQC_MCn2eTyA@mail.gmail.com/ > > Thanks for the CC, this is actually not hard to implement as shown by > Shivam, I just found the code more and more hard to follow and fragile > as we add more logic to it. And we don't have to reject higher order > split either which can be seen easily if the code is cleaner. > > Personally I think doing some cleanup first is better, I haven't post any > code as right now there doesn't seem to be much user of this. It will be > needed if more clean THP swapcache begin to show up due to things like > THP readahead for swap, which isn't here yet. I think I can send an RFC > tomorrow just for reference. I'm fine if we prefer to remove that TODO > using this smaller change first :) Thanks. Can you also help review this patchset? The changes looks good to me but I am not sure if I get all the details about swapcache handling. -- Best Regards, Yan, Zi
On Fri, Aug 07, 2026 at 10:18:05AM +0800, Zi Yan wrote: > On Wed Aug 5, 2026 at 11:54 AM EDT, Kairui Song wrote: > > On Wed, Aug 05, 2026 at 08:03:33AM +0800, Zi Yan wrote: > >> On 5 Aug 2026, at 7:18, Shivam Kalra via B4 Relay wrote: > >> > >> > Large shmem folios lose their address-space mapping when they are written > >> > to swap, but remain valid members of the swap cache. Folios read from swap > >> > but not yet associated with an anon_vma can have the same mappingless > >> > swapcache state. folio_check_splittable() currently mistakes both cases for > >> > truncation and rejects the split with -EBUSY. > >> > > >> > Implement the longstanding TODO for this state. Allow mappingless > >> > swapcache folios to use the existing uniform order-0 swapcache split path, > >> > while continuing to reject truly truncated folios and unsupported > >> > higher-order or non-uniform swapcache splits. > >> > >> Thank you for your patches. > >> > >> As Kairui (cc’d) mentioned in [1] (see “A bit more details on this”), > >> we might not need to implement this split. I will let Kairui to decide > >> how we should deal with this patchset. > >> > >> [1] https://lore.kernel.org/all/CAMgjq7CHDG8JhesSPMkn1kzG8jKb0BXO756BvxMQC_MCn2eTyA@mail.gmail.com/ > > > > Thanks for the CC, this is actually not hard to implement as shown by > > Shivam, I just found the code more and more hard to follow and fragile > > as we add more logic to it. And we don't have to reject higher order > > split either which can be seen easily if the code is cleaner. > > > > Personally I think doing some cleanup first is better, I haven't post any > > code as right now there doesn't seem to be much user of this. It will be > > needed if more clean THP swapcache begin to show up due to things like > > THP readahead for swap, which isn't here yet. I think I can send an RFC > > tomorrow just for reference. I'm fine if we prefer to remove that TODO > > using this smaller change first :) > > Thanks. Can you also help review this patchset? The changes looks good > to me but I am not sure if I get all the details about swapcache handling. > > -- > Best Regards, > Yan, Zi Hello, Thanks for the reminder, I got a bit busy so delayed for a day on that RFC. For this series I think it's functionally fine, just the split logic is a bit complex to follow and we still have restriction on swap cache for order 0 uniform split only. I'll have a closer look later. Also let me know how you think about that RFC.
On 8/7/26 23:22, Kairui Song wrote: > On Fri, Aug 07, 2026 at 10:18:05AM +0800, Zi Yan wrote: >> On Wed Aug 5, 2026 at 11:54 AM EDT, Kairui Song wrote: >>> >>> Thanks for the CC, this is actually not hard to implement as shown by >>> Shivam, I just found the code more and more hard to follow and fragile >>> as we add more logic to it. And we don't have to reject higher order >>> split either which can be seen easily if the code is cleaner. >>> >>> Personally I think doing some cleanup first is better, I haven't post any >>> code as right now there doesn't seem to be much user of this. It will be >>> needed if more clean THP swapcache begin to show up due to things like >>> THP readahead for swap, which isn't here yet. I think I can send an RFC >>> tomorrow just for reference. I'm fine if we prefer to remove that TODO >>> using this smaller change first :) >> >> Thanks. Can you also help review this patchset? The changes looks good >> to me but I am not sure if I get all the details about swapcache handling. >> >> -- >> Best Regards, >> Yan, Zi > > Hello, > > Thanks for the reminder, I got a bit busy so delayed for a day on that > RFC. > > For this series I think it's functionally fine, just the split logic is > a bit complex to follow and we still have restriction on swap cache > for order 0 uniform split only. I'll have a closer look later. Also > let me know how you think about that RFC. How does this patch set relate to your split cleanups? Is it still applicable independently? -- Cheers, David
On Fri Aug 7, 2026 at 5:22 PM EDT, Kairui Song wrote: > On Fri, Aug 07, 2026 at 10:18:05AM +0800, Zi Yan wrote: >> On Wed Aug 5, 2026 at 11:54 AM EDT, Kairui Song wrote: >> > On Wed, Aug 05, 2026 at 08:03:33AM +0800, Zi Yan wrote: >> >> On 5 Aug 2026, at 7:18, Shivam Kalra via B4 Relay wrote: >> >> >> >> > Large shmem folios lose their address-space mapping when they are written >> >> > to swap, but remain valid members of the swap cache. Folios read from swap >> >> > but not yet associated with an anon_vma can have the same mappingless >> >> > swapcache state. folio_check_splittable() currently mistakes both cases for >> >> > truncation and rejects the split with -EBUSY. >> >> > >> >> > Implement the longstanding TODO for this state. Allow mappingless >> >> > swapcache folios to use the existing uniform order-0 swapcache split path, >> >> > while continuing to reject truly truncated folios and unsupported >> >> > higher-order or non-uniform swapcache splits. >> >> >> >> Thank you for your patches. >> >> >> >> As Kairui (cc’d) mentioned in [1] (see “A bit more details on this”), >> >> we might not need to implement this split. I will let Kairui to decide >> >> how we should deal with this patchset. >> >> >> >> [1] https://lore.kernel.org/all/CAMgjq7CHDG8JhesSPMkn1kzG8jKb0BXO756BvxMQC_MCn2eTyA@mail.gmail.com/ >> > >> > Thanks for the CC, this is actually not hard to implement as shown by >> > Shivam, I just found the code more and more hard to follow and fragile >> > as we add more logic to it. And we don't have to reject higher order >> > split either which can be seen easily if the code is cleaner. >> > >> > Personally I think doing some cleanup first is better, I haven't post any >> > code as right now there doesn't seem to be much user of this. It will be >> > needed if more clean THP swapcache begin to show up due to things like >> > THP readahead for swap, which isn't here yet. I think I can send an RFC >> > tomorrow just for reference. I'm fine if we prefer to remove that TODO >> > using this smaller change first :) >> >> Thanks. Can you also help review this patchset? The changes looks good >> to me but I am not sure if I get all the details about swapcache handling. >> >> -- >> Best Regards, >> Yan, Zi > > Hello, > > Thanks for the reminder, I got a bit busy so delayed for a day on that > RFC. > > For this series I think it's functionally fine, just the split logic is > a bit complex to follow and we still have restriction on swap cache > for order 0 uniform split only. I'll have a closer look later. Also I agree. I wonder if it is possible that a shmem in swapcache could enter non uniform split, folio_split(). With Patch 1, folio_check_splittable() will return -EINVAL, causing a WARN. Hi Shivam, Can you check the above issue? If it is possible, we want to avoid it. > let me know how you think about that RFC. Sure, will take a look. -- Best Regards, Yan, Zi
On 08/08/26 22:32, Zi Yan wrote: > On Fri Aug 7, 2026 at 5:22 PM EDT, Kairui Song wrote: >> >> Hello, >> >> Thanks for the reminder, I got a bit busy so delayed for a day on that >> RFC. >> >> For this series I think it's functionally fine, just the split logic is >> a bit complex to follow and we still have restriction on swap cache >> for order 0 uniform split only. I'll have a closer look later. Also > > I agree. I wonder if it is possible that a shmem in swapcache could > enter non uniform split, folio_split(). With Patch 1, > folio_check_splittable() will return -EINVAL, causing a WARN. > > Hi Shivam, > > Can you check the above issue? If it is possible, we want to avoid it. > >> let me know how you think about that RFC. > > Sure, will take a look. Hi Zi, I checked the current folio_split() callers and this does not seem possible. The shmem swapout path unmaps the folio before clearing folio->mapping, with the folio locked. The non-uniform split callers either get the folio from an address_space or from a present page-table entry, so they cannot find a mappingless shmem folio in swapcache. The memory-failure path uses split_huge_page_to_order(), which performs a uniform split. So I don't think the WARN is reachable with the current callers. Thanks, Shivam
© 2016 - 2026 Red Hat, Inc.