From patchwork Tue Mar 31 13:21:53 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Pavel Shilovsky X-Patchwork-Id: 15365 Received: from lists.samba.org (mail.samba.org [66.70.73.150]) by demeter.kernel.org (8.14.2/8.14.2) with ESMTP id n2VDMN5v032295 for ; Tue, 31 Mar 2009 13:22:24 GMT Received: from dp.samba.org (localhost [127.0.0.1]) by lists.samba.org (Postfix) with ESMTP id 94541163D07 for ; Tue, 31 Mar 2009 13:22:06 +0000 (GMT) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on dp.samba.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=3.8 tests=BAYES_00 autolearn=ham version=3.1.7 X-Original-To: linux-cifs-client@lists.samba.org Delivered-To: linux-cifs-client@lists.samba.org Received: from mail.etersoft.ru (mail.etersoft.ru [87.249.47.46]) by lists.samba.org (Postfix) with ESMTP id 0636D163AE1 for ; Tue, 31 Mar 2009 13:21:49 +0000 (GMT) Received: from localhost (as.office.etersoft.ru [192.168.0.10]) by mail.etersoft.ru (Postfix) with ESMTP id 4584C2F9B20 for ; Tue, 31 Mar 2009 17:22:06 +0400 (MSD) X-Virus-Scanned: amavisd-new at office.etersoft.ru Received: from mail.etersoft.ru ([192.168.0.1]) by localhost (as.office.etersoft.ru [192.168.0.10]) (amavisd-new, port 10024) with LMTP id uel4KIS+R0T5 for ; Tue, 31 Mar 2009 17:22:05 +0400 (MSD) Message-ID: <49D218F1.3080006@etersoft.ru> Date: Tue, 31 Mar 2009 17:21:53 +0400 From: Pavel Shilovsky User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: linux-cifs-client@lists.samba.org Subject: [linux-cifs-client] [PATCH] non-direct reading X-BeenThere: linux-cifs-client@lists.samba.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Linux CIFS VFS client List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-cifs-client-bounces+patchwork-cifs-client=patchwork.kernel.org@lists.samba.org Errors-To: linux-cifs-client-bounces+patchwork-cifs-client=patchwork.kernel.org@lists.samba.org Hello! I found an interesting bug in cifs driver. When we don't use "direct" option during mounting, we read only from cache. My tests prove that it isn't right - if client don't keep oplock and inode->clientCanCacheRead == false, we should read from server if we want to get valid data. Here is patch, that provide reading from cache only if it's valid. static loff_t cifs_llseek(struct file *file, loff_t offset, int origin) { /* origin == SEEK_END => we must revalidate the cached file length */ @@ -733,7 +747,7 @@ const struct inode_operations cifs_symlink_inode_ops = { const struct file_operations cifs_file_ops = { .read = do_sync_read, .write = do_sync_write, - .aio_read = generic_file_aio_read, + .aio_read = cifs_file_aio_read, .aio_write = cifs_file_aio_write, .open = cifs_open, .release = cifs_close, Signed-off-by: Pavel Shilovsky --- Best regards, Pavel Shilovsky. diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c index 3ae62fb..7fe72d4 100644 --- a/fs/cifs/cifsfs.c +++ b/fs/cifs/cifsfs.c @@ -622,6 +622,20 @@ static ssize_t cifs_file_aio_write(struct kiocb *iocb, const struct iovec *iov, return written; } +static ssize_t cifs_file_aio_read(struct kiocb *iocb, const struct iovec *iov, + unsigned long nr_segs, loff_t pos) +{ + struct inode *inode = iocb->ki_filp->f_path.dentry->d_inode; + ssize_t read; + + if (CIFS_I(inode)->clientCanCacheRead) + read = generic_file_aio_read(iocb, iov, nr_segs, pos); + else + read = cifs_user_read(iocb->ki_filp, iov->iov_base, iov->iov_len, &pos); + return read; +} + +