Re: [fuse-devel] Debugging a stale kernel cache during file growth

Nikolay Amiantov
2026-04-17T06:24:26Z

[-- Attachment #1: Type: text/plain, Size: 1270 bytes --]

On 4/17/26 06:19, Matthew Wilcox wrote:
> Yes, at this point, you've left the folio in an error state. I'm sure you
> didn't mean to do that, but the VFS interprets unlocked && !uptodate as
> "an error happened" (there is a minor exception to this involving failed
> readahead, but let's set that aside).

Thanks, I see!

To save my reasoning somewhere: another way to do this would be
NFS/CIFS-style, in a lazy way. They set a flag in `getattr` and
invalidate later in `read()` instead. This could avoid relocking the
spinlock; I still opted for invalidating inside `getattr` though since
FUSE already has invalidation later in the same call, and the cost of
relocking feels low to me in this case.

Any ideas on how to resolve the remaining race condition [1]? If I'm
correct it affects any network FS, and can't be fixed without changing
the common VFS code somehow. I'd like someone to confirm my conclusions
though.

I'm way over my head here though willing to learn; if someone is willing
to mentor me on designing the fix, I'd be happy to. My best uneducated
guess is to introduce another flag for a page and check it *after* we
get the inode size in `filemap_read()`; if it's set, retry reading.

1: https://github.com/abbradar/nfs_stale_cache_test

[-- Attachment #2: Type: text/html, Size: 1853 bytes --]