On Sat, Jun 23, 2018 at 09:06:24AM -0400, Brian Foster wrote:
> to reproduce after creating a new fs or using a largish fs. I think it's
> hit or miss based on the content of free space in the filesystem. The
> appended diff applied on top of Darrick's recent xfstests test[1] makes
> this reproduce reliably for me (with -bsize=1k).
Yes, I can reproduce the issue with that patch.
> The former returns zeroes for the post-eof (i_size == 0x21a20) portion
> of the page due to the (iblock < lblock) check in
> block_read_full_page(). If the block is post eof, get_block() isn't
> called, the bh is left unmapped and the portion of the page is
> explicitly zeroed in the same loop. The iomap code appears to read and
> expose whatever is on disk if the block is allocated. I'm guessing we at
> least need to consider doing something similar in iomap_readpage_actor()
> (or perhaps somewhere in that path that also covers the write path)..?
> I'm not sure it's sufficient to rely on writeback to zero the page and
> otherwise let it expose garbage until that point.
This:
if (iomap->type != IOMAP_MAPPED || pos >= i_size_read(inode)) {
zero_user(page, poff, plen);
iomap_set_range_uptodate(page, poff, plen);
goto done;
}
is supposed to do the equivalent zeroing code. I put a little tracing
code in and we get back a mapped extent from 0x21400:0x22000, which
makes sense. It seems like we have an actual problem with the
zero_page_rage code somehow. I'll need some more time to investigate
that.
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
