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

[Nikolay Amiantov <ab@fmap.me>]

[-- 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 --]