On 11.11.25 06:58, Garg, Shivank wrote:
On 11/10/2025 7:58 PM, Matthew Wilcox wrote:
On Mon, Nov 10, 2025 at 07:50:17PM +0530, Garg, Shivank wrote:
The issue is copying those binary to a freshly mounted filesystem.
The page cache folios remain dirty until background writeback completes.
Reproduces 100% for me: fresh XFS/EXT4 mount -> copy binary -> execute ->
MADV_COLLAPSE fails.
Yes, but this is an uncommon thing to do. Really, it's the kind of
thing you do when you're testing something (like, whether ext4 supports
large folios, and whether that yields a performance improvement).
It's more reasonable to change userspace than the kernel to solve this
problem you're having.
Fair point.
You're right that this is primarily a testing scenario, though it may also
potentially affect JIT compilers writing executables (also uncommon) but more
research is needed.
For userspace workarounds, calling fsync() before MADV_COLLAPSE works.
Right. But do we want document that any caller of MADV_COLLAPSE should
issue an fsync() if MADV_COLLAPSE fails to try again?
IMHO this just reveals a problem that might also be triggered in a
container that just got downloaded or after upgrading a package, no?
--
Cheers
David
