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
next prev 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).