>> Are writes to mmap()ed regions involved at all? They lead to pages >> being dirtied at unmapping and eventually hitting ->writepage, >> potentially after ->flush and ->release have been called. > > ->flush does filemap_fdatawrite(), which should take care of any dirty > pages (I believe). Not if they come from writes to mmap()ed pages. The page cache won't see them as dirty until they're unmapped and the page table dirty bits are transfered to the page cache page flags. unmapping to transfer dirty tracking from page tables to the page cache is done in a few places. look for calls to unmap_mapping_range() like this one from the O_DIRECT write path: /* * If it's a write, unmap all mmappings of the file up-front. This * will cause any pte dirty bits to be propagated into the pageframes * for the subsequent filemap_write_and_wait(). */ if (rw == WRITE) { write_len = iov_length(iov, nr_segs); if (mapping_mapped(mapping)) unmap_mapping_range(mapping, offset, write_len, 0); } I'd hope that dirty tracking is transferred from the page tables to the page cache *before* ->release is called. (put_vma() makes me think this is the case.) So I think you could use unmap_mapping_range() and filemap_fdatawrite() to at least initiate writeback on all dirty pages in ->release. That is, you should be able to stop ->writepages calls after ->release. But it's a really bad idea to try and assert that ->writepages can't be called after ->flush. But I still don't know if mmap() is involved in his current problem. - z - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html