Zach Brown wrote:
Steve French wrote:
Dave Kleikamp wrote:
Someone had reported a problem with a writepages call coming in on
with no open files (so presumably the file was closed, with dirty
pages not written).
So is the problem that you're getting a cifs_writepages() call after
cifs_close() returns?
Probably - I could not see any other path that could cause that cifs
error to be logged to dmesg
May be a case in which filemap_fdatawrite returns before the write(s) is
sent to the vfs and write races with close (although cifs will defer a
file close if a write is pending on that handle)?
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.
I don't think so - but the person reporting it did not give much
information, and the error
is not something that I have been seeing so I can't draw conclusions
about that.
I imagine you could force writeback of dirty pages in ->release so that
you don't wait for writeback to come around and hit them. Heck, it
might be doing this already. I didn't look very hard :).
filemap_fdatawrite is called in cifs flush (which I verified is called
just before close) and
close will be delayed (not sent over the network) if a write is pending
on that file handle but
there may be two possibilities:
1) the page gets dirty while it is being released (between
fput->->cifs_flush and fput->cifs_close)
2) filemap_fdatawrite did not flush the pages fast enough - and needs to
be changed to
the filemap write and wait variant of the call in this location.
-
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
