Re: Possible regression after NFS eof page pollution fix (ext4 checksum errors)

[Trond Myklebust <trondmy@kernel.org>]

On Sun, 2026-01-04 at 11:16 +0200, Mark Bloch wrote:
> Hi Trond,
> 
> We’ve recently started seeing filesystem issues in our internal
> regression runs, and we were able to bisect the problem down to
> the following commit:
> 
> commit b1817b18ff20e69f5accdccefaf78bf5454bede2
> Author: Trond Myklebust <trond.myklebust@hammerspace.com>
> Date:   Thu Sep 4 18:46:16 2025 -0400
> 
>     NFS: Protect against 'eof page pollution'
> 
>     This commit fixes the failing xfstest 'generic/363'.
> 
>     When the user mmaps() an area that extends beyond the end of
> file, and
>     proceeds to write data into the folio that straddles that eof,
> we're
>     required to discard that folio data if the user calls some
> function that
>     extends the file length.
> 
>     Signed-off-by: Trond Myklebust <trond.myklebust@hammerspace.com>
> 
> 
> After this change, we intermittently see EXT4 checksum-related errors
> during boot.
> A representative dmesg excerpt is below:
> 
>  [ 1908.365537] EXT4-fs warning (device vda2):
> ext4_dirblock_csum_verify:375: inode #263414: comm updatedb: No space
> for directory leaf checksum. Please run e2fsck -D.
>  [ 1908.375449] EXT4-fs error (device vda2): __ext4_find_entry:1624:
> inode #263414: comm updatedb: checksumming directory block 0
>  [ 1908.382985] EXT4-fs warning (device vda2):
> ext4_dirblock_csum_verify:375: inode #263414: comm updatedb: No space
> for directory leaf checksum. Please run e2fsck -D.
>  [ 1908.389289] EXT4-fs error (device vda2): __ext4_find_entry:1624:
> inode #263414: comm updatedb: checksumming directory block 0
>  [ 1909.598811] EXT4-fs warning (device vda2):
> ext4_dirblock_csum_verify:375: inode #423753: comm updatedb: No space
> for directory leaf checksum. Please run e2fsck -D.
>  [ 1909.604308] EXT4-fs error (device vda2):
> htree_dirblock_to_tree:1051: inode #423753: comm updatedb: Directory
> block failed checksum
>  [ 1909.958470] EXT4-fs warning (device vda2):
> ext4_dirblock_csum_verify:375: inode #423759: comm updatedb: No space
> for directory leaf checksum. Please run e2fsck -D.
>  [ 1909.963825] EXT4-fs error (device vda2):
> htree_dirblock_to_tree:1051: inode #423759: comm updatedb: Directory
> block failed checksum
>  [ 1909.985956] EXT4-fs warning (device vda2):
> ext4_dirblock_csum_verify:375: inode #303617: comm updatedb: No space
> for directory leaf checksum. Please run e2fsck -D.
>  [ 1909.991371] EXT4-fs error (device vda2): __ext4_find_entry:1624:
> inode #303617: comm updatedb: checksumming directory block 0
>  [ 1910.156415] EXT4-fs warning (device vda2):
> ext4_dirblock_csum_verify:375: inode #423761: comm updatedb: No space
> for directory leaf checksum. Please run e2fsck -D.
>  [ 1910.161959] EXT4-fs error (device vda2):
> htree_dirblock_to_tree:1051: inode #423761: comm updatedb: Directory
> block failed checksum
>  [ 1910.171364] EXT4-fs warning (device vda2):
> ext4_dirblock_csum_verify:375: inode #423735: comm updatedb: No space
> for directory leaf checksum. Please run e2fsck -D.
>  [ 1910.177292] EXT4-fs error (device vda2):
> htree_dirblock_to_tree:1051: inode #423735: comm updatedb: Directory
> block failed checksum
>  [ 1910.267721] EXT4-fs warning (device vda2):
> ext4_dirblock_csum_verify:375: inode #423744: comm updatedb: No space
> for directory leaf checksum. Please run e2fsck -D.
>  [ 1910.281838] EXT4-fs error (device vda2):
> htree_dirblock_to_tree:1051: inode #423744: comm updatedb: Directory
> block failed checksum
>  [ 1910.476906] EXT4-fs warning (device vda2):
> ext4_dirblock_csum_verify:375: inode #423751: comm updatedb: No space
> for directory leaf checksum. Please run e2fsck -D.
>  [ 1910.482403] EXT4-fs error (device vda2):
> htree_dirblock_to_tree:1051: inode #423751: comm updatedb: Directory
> block failed checksum
> 
> The issue has so far only been observed in tests that use a nested VM
> setup.
> It does not reproduce deterministically, roughly half of the nested
> VM boots trigger the problem.
> 
> Would you mind taking a look or pointing us in the right direction?
> Please let us know if additional information, testing,
> or instrumentation would be helpful.
> 
> Thanks,
> Mark

I'm having trouble seeing how those issues can be related unless ext4
and NFS are somehow sharing the same folios. Does reverting just 
commit b1817b18ff20 and b2036bb65114 actually fix the ext4 problem?

What does "nested VM" mean in this situation, and what is the storage
for the ext4 filesystem that is being corrupted?

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trondmy@kernel.org, trond.myklebust@hammerspace.com