Re: [PATCH v2] btrfs: scrub: report the failing sector's address, not the stripe base

On Sun, Aug 16, 2026 at 07:43:47AM +0930, Qu Wenruo wrote:
> Great that the mystery got solved!

Thanks for applying it. Here is what it turned out to be, for the archive. Not
a btrfs bug, no action wanted.

VMware's vmmon pins the pages of an mmapped file with
get_user_pages_fast(..., 0, ...) and registers no mmu_notifier, so the guest
keeps writing through EPT after folio_mkclean() has write-protected the PTEs.
btrfs checksums a page that is still changing. Nothing was corrupt; the
checksums described bytes that were already stale.

This is not an old build: Workstation 26.0.0 build 25388281 (26H1), the
current release.

The file is /tmp/vmware-<user>/ramNNN - despite the name, ~25 MB of device
emulation state, not guest RAM. It only lands on btrfs because /tmp here is a
subvolume rather than tmpfs, an openSUSE layout inherited from 15.x. Fresh
Leap 16 installs get tmpfs and are immune.

Storage-independent - I hit it on btrfs/LVM/md-RAID1 and on btrfs directly over
a 3ware hardware-RAID LU, one device as far as Linux is concerned.

What I found interesting: mm/gup.c already refuses this.
writable_file_mapping_allowed() rejects a long-term writable pin of a
dirty-tracked file mapping, and pin_user_pages.rst CASE 5 names this exact code
shape as the INCORRECT pattern. But with gup_flags = 0, check_vma_flags()
computes write = (gup_flags & FOLL_WRITE) = 0 and never reaches the check.
Declaring FOLL_PIN|FOLL_LONGTERM|FOLL_WRITE would have failed -EFAULT at VM
start instead of surfacing months later as apparent corruption. Reporting that
to the vendor.

Possibly useful for triage, since it makes the symptom look impossible: on md
the same page mutation leaves the mirrors holding different bytes, because
raid1_write_request() clones the bio and the clones point at the same pages.

    logical 0x19AF05000     stored csum   c615d429
      nvme2n1  327e401c
      nvme0n1  327e401c
      nvme1n1  c615d429     <- matches the stored checksum

mismatch_cnt was 2176; the RAID6 array on the same host reads 0. Invisible on
hardware RAID, where mirroring happens below Linux. So if a report here ever
describes csum errors on btrfs-over-md-RAID1, reading each member directly is
worth doing before believing the filesystem.

The intermittency I reported earlier in this thread was just extent churn - the
file is rewritten constantly, so flagged extents get freed and reallocated.

This may also be worth a second look:

  https://lore.kernel.org/linux-btrfs/[email protected]/

Lionel Bouton (cc'd), June 2024 - "scrub reports uncorrectable csum errors linked to
readable file (data: single)". Same profile as mine: uncorrectable csum=N with
corrected=0, all errors on one file, the count multiplied by snapshots, and the
file reading back perfectly fine. That thread ends with "Let me dig deeper to
find out why" and no conclusion. His setup was different - a QEMU/KVM guest on
Ceph RBD rather than a VMware host - so I am not claiming the same cause, only
that the symptom profile is identical and an unmanaged writer would produce it.

Which connects to 7ca3e84980ef ("btrfs: reject out-of-band dirty folios during
writeback"): "This used to be a problem related to get_user_page(), but with the
introduction of pin_user_pages*(), we should no longer hit such case anymore."
That assumption has at least one shipping counterexample.

Cc'ing Boris since the fixup worker has just been reinstated via dirty_folio().

Workaround is chattr +C on /tmp and on every pre-existing directory beneath it,
since the flag is inherited at creation only.

Thanks,
James