Re: [BUG] shmem: FALLOC_FL_PUNCH_HOLE vs fault-around race corrupts page cache / rss counters

[Ayush Ranjan <ayushr@modal.com>]

On Thu, Sep 24, 2026 at 08:34 +0000, Pedro Falcato wrote:
> (please use the email I actually use for work, thanks; not sure how
> you got to that one)

Sorry about that. I put the Cc list together with the help of an AI
assistant, and it filled in the gmail address from your older list
postings; I should have checked it against MAINTAINERS. Using this
one from now on.

> >   - filemap_map_pages() samples mm_counter_file(folio) once per batch
> >     and applies it with add_mm_counter() after mapping; if the
> >     folio's swapbacked state changes while it is concurrently torn
>
> But that cannot happen? We hold the folio lock in filemap_map_pages().
> The folio (naturally) cannot be torn down while we have the folio lock.
[...]
> No, I don't think this paragraph is true. Page cache truncation (via
> truncate, or fallocate PUNCH_HOLE) takes the folio lock for each folio
> that is about to be truncated out. Mapping folios takes the folio lock
> as well, except in the fork() case where a myriad of weird interval tree
> + PTE lock interactions make it safe (AIUI).

You're right... Thanks for the correction.

One empirical hint that may help: the reproducer strictly requires
khugepaged to be re-collapsing the punched ranges (it never trips with
the default 10s scan interval), so the large-folio / partial-truncation
angle Jan raised elsewhere in the thread may be the more promising one.

> Awesome that you have a reproducer! Have you reproduced this on a
> mainline kernel? Enterprise kernels are not supported upstream.

Partially. The production workload trips both BUGs on:

  - 6.12.96 (Ubuntu 24.04, mainline stable build)
  - 6.18.46 + two writeback backports (31c1d19ead2c "writeback: use a
    per-sb counter to drain inode wb switches at umount" and
    f6988c90671e "writeback: bound cleanup_offline_cgwb() rescans by
    rotating scanned inodes") (Ubuntu 24.04)
  - 6.12.0-204.92.4.4.3.el9uek (Oracle Linux 9, UEK8)

The standalone reproducer, however, has so far only triggered the
rss-counter one, and only on the UEK8 kernel. Not on our 6.18.46
hosts, and it has never triggered the "Bad page cache" one for me.
So it clearly does not capture everything the production workload
does. The production workload which triggers this is gVisor, which
heavily utilizes memfd to implement application memory for the
sandboxed application and punches holes into it to decommit/release
memory on the host.

For completeness, here is a production capture of the "still mapped
when deleted" bug on the 6.18.46 kernel (the gVisor workload
mentioned in the report; the taint is from our out-of-tree module which
was not being used here):

  BUG: Bad page cache in process exe  pfn:1be0e380
  page: refcount:17 mapcount:1 mapping:00000000ceb7a77f index:0x153980 pfn:0x1be0e380
  head: order:3 mapcount:8 entire_mapcount:0 nr_pages_mapped:8 pincount:0
  memcg:ff25c58e86be5480
  aops:shmem_aops ino:3180f dentry name(?):"memfd:runsc-memory"
  flags: 0x57ffffd802006d(locked|referenced|uptodate|lru|head|swapbacked|node=1|zone=2|lastcpupid=0x1fffff)
  raw: 0057ffffd802006d ff8c38e33838e208 ff8c38e33838a008 ff25c5f1950be208
  raw: 0000000000153980 0000000000000000 0000001100000000 ff25c58e86be5480
  head: 0057ffffd802006d ff8c38e33838e208 ff8c38e33838a008 ff25c5f1950be208
  head: 0000000000153980 0000000000000000 0000001100000000 ff25c58e86be5480
  head: 0057ffffc0000203 ff8c38e33838e001 0000000800000007 00000000ffffffff
  head: ffffffff00000007 00000000000000d4 0000000000000000 0000000000000008
  page dumped because: still mapped when deleted
  CPU: 170 UID: 0 PID: 947113 Comm: exe Kdump: loaded Tainted: G           OE       6.18.46-modal2 #2 PREEMPT(voluntary)
  Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
  Hardware name: Oracle Corporation ORACLE SERVER E6-2c/Asm,MB+Tray,E6-2c, BIOS 89070200 04/03/2026
  Call Trace:
   <TASK>
   dump_stack_lvl+0x76/0xa0
   dump_stack+0x10/0x20
   filemap_unaccount_folio+0xf7/0x240
   __filemap_remove_folio+0x3c/0x1e0
   ? vma_interval_tree_iter_next+0xaa/0xc0
   ? unmap_mapping_folio+0x70/0x130
   ? __folio_cancel_dirty+0x29/0x110
   filemap_remove_folio+0x47/0xf0
   truncate_inode_partial_folio+0x15e/0x2d0
   shmem_undo_range+0x6bb/0x930
   shmem_fallocate+0x1ab/0x530
   vfs_fallocate+0x17b/0x3b0
   __x64_sys_fallocate+0x4a/0xc0
   x64_sys_call+0x1fe1/0x26a0
   do_syscall_64+0x82/0xf80
   ? seccomp_notify_ioctl+0x3dd/0x7a0
   ? __seccomp_filter+0x10b/0x610
   ? __x64_sys_ioctl+0xbf/0x100
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x40d00e
   </TASK>

followed later, when that process exited, by:

  BUG: Bad rss-counter state mm:00000000283589c7 type:MM_SHMEMPAGES val:40 Comm:exe Pid:939691

Thanks for taking a look.

Thanks,
Ayush