linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Cc: Christoph@sandeen.net, Hellwig@sandeen.net, hch@lst.de
Subject: [PATCH 2/3] iomap: don't search past page end in iomap_is_partially_uptodate
Date: Thu, 13 Dec 2018 16:25:28 -0600	[thread overview]
Message-ID: <1544739929-21651-3-git-send-email-sandeen@sandeen.net> (raw)
In-Reply-To: <1544739929-21651-1-git-send-email-sandeen@sandeen.net>

From: Eric Sandeen <sandeen@redhat.com>

iomap_is_partially_uptodate() is intended to check wither blocks within
the selected range of a not-uptodate page are uptodate; if the range we
care about is up to date, it's an optimization.

However, the iomap implementation continues to check all blocks up to
from+count, which is beyond the page, and can even be well beyond the
iop->uptodate bitmap.

I think the worst that will happen is that we may eventually find a zero
bit and return "not partially uptodate" when it would have otherwise
returned true, and skip the optimization.  Still, it's clearly an invalid
memory access that must be fixed.

So: fix this by limiting the search to within the page as is done in the
non-iomap variant, block_is_partially_uptodate().

Zorro noticed thiswhen KASAN went off for 512 byte blocks on a 64k
page system:

 BUG: KASAN: slab-out-of-bounds in iomap_is_partially_uptodate+0x1a0/0x1e0
 Read of size 8 at addr ffff800120c3a318 by task fsstress/22337

Reported-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
---
 fs/iomap.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/fs/iomap.c b/fs/iomap.c
index d6bc98a..ce837d9 100644
--- a/fs/iomap.c
+++ b/fs/iomap.c
@@ -492,16 +492,29 @@ struct iomap_readpage_ctx {
 }
 EXPORT_SYMBOL_GPL(iomap_readpages);
 
+/*
+ * iomap_is_partially_uptodate checks whether blocks within a page are
+ * uptodate or not.
+ *
+ * Returns true if all blocks which correspond to a file portion
+ * we want to read within the page are uptodate.
+ */
 int
 iomap_is_partially_uptodate(struct page *page, unsigned long from,
 		unsigned long count)
 {
 	struct iomap_page *iop = to_iomap_page(page);
 	struct inode *inode = page->mapping->host;
-	unsigned first = from >> inode->i_blkbits;
-	unsigned last = (from + count - 1) >> inode->i_blkbits;
+	unsigned len, first, last;
 	unsigned i;
 
+	/* Limit range to one page */
+	len = min_t(unsigned, PAGE_SIZE - from, count);
+
+	/* First and last blocks in range within page */
+	first = from >> inode->i_blkbits;
+	last = (from + len - 1) >> inode->i_blkbits;
+
 	if (iop) {
 		for (i = first; i <= last; i++)
 			if (!test_bit(i, iop->uptodate))
-- 
1.8.3.1

  parent reply	other threads:[~2018-12-13 22:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-13 22:25 [PATCH 0/3] iomap: 1 cleanup, 1 fix, 1 optimization Eric Sandeen
2018-12-13 22:25 ` [PATCH 1/3] iomap: use SECTOR_SIZE instead of 512 in iomap_page Eric Sandeen
2018-12-15 10:51   ` Christoph Hellwig
2018-12-17 23:45     ` Eric Sandeen
2018-12-18 18:06       ` Christoph Hellwig
2018-12-18 18:19         ` Darrick J. Wong
2018-12-18 18:20           ` Eric Sandeen
2018-12-13 22:25 ` Eric Sandeen [this message]
2018-12-14  2:57   ` [PATCH 2/3] iomap: don't search past page end in iomap_is_partially_uptodate Dave Chinner
2018-12-14 13:48     ` Eric Sandeen
2018-12-14 22:14   ` [PATCH 2/3 V2] mm: don't search past page end in is_partially_uptodate Eric Sandeen
2018-12-15 10:49     ` Christoph Hellwig
2018-12-13 22:25 ` [PATCH 3/3] iomap: optimize iomap_is_partially_uptodate for full page range Eric Sandeen
2018-12-14  3:05   ` Dave Chinner
2018-12-14 14:10     ` Eric Sandeen
2018-12-17 23:21       ` Dave Chinner
2018-12-13 22:27 ` [PATCH 0/3] iomap: 1 cleanup, 1 fix, 1 optimization Eric Sandeen

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=1544739929-21651-3-git-send-email-sandeen@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=Christoph@sandeen.net \
    --cc=Hellwig@sandeen.net \
    --cc=hch@lst.de \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).