mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: torvalds@osdl.org, akpm@linux-foundation.org
Cc: linux-cachefs@redhat.com, linux-kernel@vger.kernel.org,
	Jan Beulich <jbeulich@novell.com>,
	David Howells <dhowells@redhat.com>,
	Suresh Jayaraman <sjayaraman@suse.de>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	stable@kernel.org
Subject: [PATCH] FS-Cache: Fix __fscache_uncache_all_inode_pages()'s outer loop
Date: Thu, 21 Jul 2011 15:02:43 +0100	[thread overview]
Message-ID: <20110721140243.21768.64949.stgit@warthog.procyon.org.uk> (raw)

From: Jan Beulich <JBeulich@novell.com>

The compiler, at least for ix86 and m68k, validly warns that the comparison:

	next <= (loff_t)-1

is always true (and it's always true also for x86-64 and probably all other
arches - as long as pgoff_t isn't wider than loff_t).  The intention appears
to be to avoid wrapping of "next", so rather than eliminating the pointless
comparison, fix the loop to indeed get exited when "next" would otherwise
wrap.

On m68k the following warning is observed:

fs/fscache/page.c: In function '__fscache_uncache_all_inode_pages':
fs/fscache/page.c:979: warning: comparison is always false due to
limited range of data type

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reported-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Cc: Suresh Jayaraman <sjayaraman@suse.de>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: stable@kernel.org
---

 fs/fscache/page.c |   14 +++++---------
 1 files changed, 5 insertions(+), 9 deletions(-)

diff --git a/fs/fscache/page.c b/fs/fscache/page.c
index 60315b3..ff1e68f 100644
--- a/fs/fscache/page.c
+++ b/fs/fscache/page.c
@@ -993,16 +993,12 @@ void __fscache_uncache_all_inode_pages(struct fscache_cookie *cookie,
 
 	pagevec_init(&pvec, 0);
 	next = 0;
-	while (next <= (loff_t)-1 &&
-	       pagevec_lookup(&pvec, mapping, next, PAGEVEC_SIZE)
-	       ) {
+	do {
+		if (!pagevec_lookup(&pvec, mapping, next, PAGEVEC_SIZE))
+			break;
 		for (i = 0; i < pagevec_count(&pvec); i++) {
 			struct page *page = pvec.pages[i];
-			pgoff_t page_index = page->index;
-
-			ASSERTCMP(page_index, >=, next);
-			next = page_index + 1;
-
+			next = page->index;
 			if (PageFsCache(page)) {
 				__fscache_wait_on_page_write(cookie, page);
 				__fscache_uncache_page(cookie, page);
@@ -1010,7 +1006,7 @@ void __fscache_uncache_all_inode_pages(struct fscache_cookie *cookie,
 		}
 		pagevec_release(&pvec);
 		cond_resched();
-	}
+	} while (++next);
 
 	_leave("");
 }


                 reply	other threads:[~2011-07-21 14:04 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20110721140243.21768.64949.stgit@warthog.procyon.org.uk \
    --to=dhowells@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=geert@linux-m68k.org \
    --cc=jbeulich@novell.com \
    --cc=linux-cachefs@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sjayaraman@suse.de \
    --cc=stable@kernel.org \
    --cc=torvalds@osdl.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®