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