Am curious how you noticed this problem? Did you have a test case? On Tue, Nov 27, 2012 at 12:50 AM, 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 > > -- > 1.7.10.4 > > -- > 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
-- Thanks, Steve -- 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
