On Tue, 27 Nov 2012 10:50:28 +0400 Pavel Shilovsky <[email protected]> wrote:
> If we have a read oplock and set a read lock in it, we can't write to the > locked area - so, filemap_fdatawrite may fail with a no information for a > userspace application even if we request a write to non-locked area. Fix > this by replacing it with filemap_write_and_wait call and sending non-page > write in a error case. > > While this may end up with two write requests to the server, we can be sure > that our data will be the same at the server and the page cache - the next > read > on this file gets the valid data. > > Signed-off-by: Pavel Shilovsky <[email protected]> > --- > fs/cifs/file.c | 10 ++++------ > 1 file changed, 4 insertions(+), 6 deletions(-) > > diff --git a/fs/cifs/file.c b/fs/cifs/file.c > index f8fe1bd..89efd85 100644 > --- a/fs/cifs/file.c > +++ b/fs/cifs/file.c > @@ -2511,14 +2511,12 @@ cifs_strict_writev(struct kiocb *iocb, const struct > iovec *iov, > */ > if (!cinode->clientCanCacheAll && cinode->clientCanCacheRead) { > ssize_t written; > - int rc; > > written = generic_file_aio_write(iocb, iov, nr_segs, pos); > - rc = filemap_fdatawrite(inode->i_mapping); > - if (rc) > - return (ssize_t)rc; > - > - return written; > + /* try page write at first */ > + if (!filemap_write_and_wait(inode->i_mapping)) > + return written; > + /* page write failed - try from pos to pos+len-1 */ > } > #endif > Bleh -- nasty. I guess this will work though... Wonder if there's some way to populate the cache and then just mark the pages clean without sending out writes? That would be a better solution IMO, but I guess we can live with this for now... Acked-by: Jeff Layton <[email protected]> -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
