All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Steve French <sfrench@samba.org>
Cc: linux-cifs@vger.kernel.org, kernel-janitors@vger.kernel.org,
	samba-technical@lists.samba.org, Josef Bacik <josef@redhat.com>
Subject: [patch] cifs: fix revalidation test in cifs_llseek()
Date: Thu, 19 Apr 2012 21:06:19 +0000	[thread overview]
Message-ID: <20120419210619.GA19074@elgon.mountain> (raw)

This test is always true so it means we revalidate the length every
time, which generates more network traffic.  This was introduced in
06222e491e "fs: handle SEEK_HOLE/SEEK_DATA properly in all fs's that
define their own llseek".

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
Josef, there were three other places that had this same problem but I
think they've all been fixed now.  Except that I had a question about
nfs_file_llseek().  Isn't that reversed?  It seems like it only
revalidates when it's not supposed to.  I chose to copy what
fuse_file_llseek() does instead.

diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
index d342128..97d26c7 100644
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -695,7 +695,7 @@ static loff_t cifs_llseek(struct file *file, loff_t offset, int origin)
 	 * origin = SEEK_END || SEEK_DATA || SEEK_HOLE => we must revalidate
 	 * the cached file length
 	 */
-	if (origin != SEEK_SET || origin != SEEK_CUR) {
+	if (origin = SEEK_SET || origin = SEEK_CUR) {
 		int rc;
 		struct inode *inode = file->f_path.dentry->d_inode;
 

WARNING: multiple messages have this Message-ID (diff)
From: Dan Carpenter <dan.carpenter@oracle.com>
To: Steve French <sfrench@samba.org>
Cc: linux-cifs@vger.kernel.org, kernel-janitors@vger.kernel.org,
	samba-technical@lists.samba.org, Josef Bacik <josef@redhat.com>
Subject: [patch] cifs: fix revalidation test in cifs_llseek()
Date: Fri, 20 Apr 2012 00:06:19 +0300	[thread overview]
Message-ID: <20120419210619.GA19074@elgon.mountain> (raw)

This test is always true so it means we revalidate the length every
time, which generates more network traffic.  This was introduced in
06222e491e "fs: handle SEEK_HOLE/SEEK_DATA properly in all fs's that
define their own llseek".

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
Josef, there were three other places that had this same problem but I
think they've all been fixed now.  Except that I had a question about
nfs_file_llseek().  Isn't that reversed?  It seems like it only
revalidates when it's not supposed to.  I chose to copy what
fuse_file_llseek() does instead.

diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
index d342128..97d26c7 100644
--- a/fs/cifs/cifsfs.c
+++ b/fs/cifs/cifsfs.c
@@ -695,7 +695,7 @@ static loff_t cifs_llseek(struct file *file, loff_t offset, int origin)
 	 * origin == SEEK_END || SEEK_DATA || SEEK_HOLE => we must revalidate
 	 * the cached file length
 	 */
-	if (origin != SEEK_SET || origin != SEEK_CUR) {
+	if (origin == SEEK_SET || origin == SEEK_CUR) {
 		int rc;
 		struct inode *inode = file->f_path.dentry->d_inode;
 

             reply	other threads:[~2012-04-19 21:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-19 21:06 Dan Carpenter [this message]
2012-04-19 21:06 ` [patch] cifs: fix revalidation test in cifs_llseek() Dan Carpenter
     [not found] ` <20120419210619.GA19074-mgFCXtclrQlZLf2FXnZxJA@public.gmane.org>
2012-04-27 12:59   ` Pavel Shilovsky
2012-04-27 12:59     ` Pavel Shilovsky
     [not found]     ` <CAKywueQrrHdqXXrHQbP=vjs_MLjksvR09cpax0iWw-PS6ms=fg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2012-04-27 13:08       ` Pankaj Baranwal
2012-04-27 13:20         ` Pankaj Baranwal
2012-04-27 13:40     ` Jeff Layton
2012-04-27 13:40       ` Jeff Layton
2012-04-30 14:36     ` [patch v2] " Dan Carpenter
2012-04-30 14:36       ` Dan Carpenter
2012-04-30 15:15       ` Jeff Layton
2012-04-30 15:15         ` Jeff Layton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120419210619.GA19074@elgon.mountain \
    --to=dan.carpenter@oracle.com \
    --cc=josef@redhat.com \
    --cc=kernel-janitors@vger.kernel.org \
    --cc=linux-cifs@vger.kernel.org \
    --cc=samba-technical@lists.samba.org \
    --cc=sfrench@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.