Re: [PATCH v3 09/12] mm, swap: use the swap table to track the swap count

Re: [PATCH v3 09/12] mm, swap: use the swap table to track the swap count

[Breno Leitao]

Hello Kairui,

On Wed, Feb 18, 2026 at 04:06:34AM +0800, Kairui Song wrote:
> @@ -479,6 +469,7 @@ static void swap_cluster_assert_empty(struct swap_cluster_info *ci,
>  	} while (++ci_off < ci_end);
>  
>  	WARN_ON_ONCE(bad_slots != (swapoff ? ci->count : 0));
> +	WARN_ON_ONCE(nr == SWAPFILE_CLUSTER && ci->extend_table);

On my automatic tests with 7.1 kernel I am seeing the following warning.

The test was running on commit 74fe02ce122a6103f20 ("Merge tag
'wq-for-7.1-rc2-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq").

This happened only once so far.

   WARNING: mm/swapfile.c:471 at swap_cluster_assert_empty+0x1b6/0x1d0, CPU#2: swapoff/1265108  ^[[36m[warn]^[[0m
   Modules linked in: sunrpc(E) squashfs(E) sch_fq(E) act_gact(E) tcp_diag(E) inet_diag(E) cls_bpf(E) intel_uncore_frequency(E) intel_uncore_frequency_common(E) skx_edac(E) skx_edac_common(E) nfit(E) x86_pkg_temp_thermal(E) intel_powerclamp(E) coretemp(E) kvm_intel(E) kvm(E) evdev(E) iTCO_wdt(E) ipmi_si(E) irqbypass(E) ipmi_devintf(E) xhci_pci(E) acpi_cpufreq(E) wmi(E) ipmi_msghandler(E) button(E) i2c_i801(E) xhci_hcd(E) i2c_smbus(E) sch_fq_codel(E) ip_tables(E) ip6_tables(E) vhost_net(E) tun(E) vhost(E) vhost_iotlb(E) tap(E) tls(E) mpls_gso(E) bpf_preload(E) mpls_iptunnel(E) mpls_router(E) fou(E) drm(E) loop(E) backlight(E) drm_panel_orientation_quirks(E) autofs4(E) raid0(E) efivarfs(E) dm_crypt(E)
   CPU: 2 UID: 0 PID: 1265108 Comm: swapoff Tainted: G S          E       7.1.0-0_fbk701_debugnightly_rc0_upstream_76_g74fe02ce122a #1 PREEMPTLAZY 
   Tainted: [S]=CPU_OUT_OF_SPEC, [E]=UNSIGNED_MODULE
   Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09M3A09 07/03/2023
   RIP: 0010:swap_cluster_assert_empty+0x1b6/0x1d0
   Code: e8 03 48 b9 00 00 00 00 00 fc ff df 0f b6 04 08 84 c0 75 1a 41 0f b7 07 39 c3 74 99 0f 0b 81 7c 24 08 00 02 00 00 74 97 eb be <0f> 0b eb ba 44 89 f9 80 e1 07 fe c1 38 c1 7c da 4c 89 ff e8 12 46
   RSP: 0018:ffff8882a2257a48 EFLAGS: 00010286
   RAX: 1ffff1106956192d RBX: 0000000000000000 RCX: dffffc0000000000
   RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffff8884dbeeaff8
   RBP: ffff8884dbeeaff8 R08: ffff8884dbeeafff R09: 1ffff1109b7dd5ff
   R10: dffffc0000000000 R11: ffffed109b7dd600 R12: ffff88834ab0c960
   R13: 0000000000000200 R14: ffff88834ab0c968 R15: 0000000000000200
   FS:  00007fab994cf800(0000) GS:ffff88909c8c0000(0000) knlGS:0000000000000000
   CR2: 00007f789da9b110 CR3: 00000004bdc63001 CR4: 00000000007726f0
   PKRU: 55555554
   Call Trace:
    <TASK>
    __free_cluster+0x2f/0x180
    swap_cache_del_folio+0x120/0x240
    folio_free_swap+0x51b/0x630
    ? folio_free_swap+0x2e6/0x630
    try_to_unuse+0x216d/0x2470
    ? try_to_unuse+0xbc9/0x2470
    __se_sys_swapoff+0x3fb/0x8e0
    do_syscall_64+0xfa/0x990
    ? irqentry_exit+0x102/0x770
    ? trace_irq_disable+0x64/0x1c0
    ? entry_SYSCALL_64_after_hwframe+0x4b/0x53
    entry_SYSCALL_64_after_hwframe+0x4b/0x53
   RIP: 0033:0x7fab996ac08b
   Code: 0f 1e fa 48 83 fe 01 48 8b 15 89 ad 0c 00 19 c0 83 e0 f0 83 c0 26 64 89 02 b8 ff ff ff ff c3 f3 0f 1e fa b8 a8 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 5d ad 0c 00 f7 d8 64 89 01 48
   RSP: 002b:00007fff9cde2488 EFLAGS: 00000202 ORIG_RAX: 00000000000000a8
   RAX: ffffffffffffffda RBX: 00007fff9cde3e98 RCX: 00007fab996ac08b
   RDX: 0000000000000001 RSI: 0000000000000c00 RDI: 000055bfaf2199b0
   RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001
   R10: 00000000000000bf R11: 0000000000000202 R12: 0000000000000000
   R13: 000055bfaf211479 R14: 000055bfaf212b00 R15: 000055bfaf212ad8
    </TASK>
   irq event stamp: 0
   hardirqs last  enabled at (0): [<0000000000000000>] 0x0
   hardirqs last disabled at (0): [<ffffffff81441ab3>] copy_process+0x833/0x32b0
   softirqs last  enabled at (0): [<ffffffff81441ab3>] copy_process+0x833/0x32b0
   softirqs last disabled at (0): [<0000000000000000>] 0x0


Decodeding the stack, I see the following file:lines (against the same
commit as above (74fe02ce122a6103f20))

  swap_cluster_assert_empty+0x1b6   mm/swapfile.c:471   WARN: nr == SWAPFILE_CLUSTER && ci->extend_table
  __free_cluster+0x2f               mm/swapfile.c:585   (return from swap_cluster_assert_empty)
                                        then swap_cluster_free_table at line 586
  swap_cache_del_folio+0x120        mm/swap_state.c:298 __swap_cache_del_folio()
                                        (chain __swap_cluster_free_entries → free_cluster → __free_cluster all inlined)
  folio_free_swap+0x51b             mm/swapfile.c:2037  swap_cache_del_folio(folio)
  folio_free_swap+0x2e6             mm/swapfile.c:2034  if (folio_maybe_swapped(folio))
  try_to_unuse+0x216d               mm/swapfile.c:2628
  try_to_unuse+0xbc9                mm/swapfile.c:2592  unuse_mm() chain
  __se_sys_swapoff+0x3fb            mm/swapfile.c:2903
  do_syscall_64+0xfa                arch/x86/entry/syscall_64.c

Does it ring a bell?
--breno

Re: [PATCH v3 09/12] mm, swap: use the swap table to track the swap count

[Kairui Song]

On Mon, May 11, 2026 at 7:21 PM Breno Leitao <leitao@debian.org> wrote:
>
> Hello Kairui,
>

Hello Breno,

Thanks for the report.

This information is very helpful. I think I know the problem now, it
seems we might left a dangling `ci->extend_table` if
`swap_retry_table_alloc` is called during fork, and somehow the swap
count is decreased during that period. Fortunately, it's not a serious
issue and a self healing one. The `ci->extend_table` will be cleaned
up the next time the cluster is used, so it's not really a leak and
the higher-than-expected memory usage is quite undercontrol.

I'll verify this and post a fix later. Thanks again for the helpful feedback!