[PATCH] handle pages which alter their ->mapping
Patch from Hugh Dickins <hugh@veritas.com> tmpfs failed fsx+swapout tests after many hours, a page found zeroed. Not a truncate problem, but mirror image of earlier truncate problems: swap goes through mpage_writepages, which must therefore allow for a sudden swizzle back to file identity. Second time this caught us, so I've audited the tree for other places which might be surprised by such swizzling. The only others I found were (perhaps) in the parisc and sparc64 flush_dcache_page called from do_generic_mapping_read on a looped tmpfs file which is also mmapped; but that's a very marginal case, I wanted to understand it better before making any edit, and now realize that hch's sendfile in loop eliminates it (now go through do_shmem_file_read instead: similar but crucially this locks the page when raising its count, which is enough to keep vmscan from interfering).
Showing
Please register or sign in to comment