Stale page cache reads after file truncation on local filesystems

When a file is truncated to a smaller size, the Linux kernel may leave existing page‑cache pages that cover the truncated region intact until they are reclaimed or explicitly invalidated. This can cause subsequent reads—either via regular read() or through a shared memory mapping—to return data that was written before the truncate, i.e., stale content. The invalidation is immediate for private mappings on most local filesystems, but it can be delayed when the file is mapped shared, when the underlying filesystem uses delayed allocation or writeback, or when the client is an NFS mount relying on attribute caching. The precise point at which the kernel discards the stale pages depends on factors such as the vm.dirty_ratio setting, page‑reclaim pressure, and kernel version (changes appeared between 4.14 and 5.4).

Under what circumstances does the kernel defer invalidation of page‑cache pages after truncate? How do shared memory mappings affect the visibility of stale data after truncate? Which kernel version ranges exhibit the deferred invalidation behavior?