Btrfs: deal with existing encompassing extent map in btrfs_get_extent()
authorOmar Sandoval <osandov@fb.com>
Wed, 9 Nov 2016 23:26:50 +0000 (15:26 -0800)
committerDavid Sterba <dsterba@suse.com>
Wed, 30 Nov 2016 12:45:14 +0000 (13:45 +0100)
commit8e2bd3b7fac91b79a6115fd1511ca20b2a09696d
tree587d0b12dd206b5e6e475eb0fc95679208838f4d
parent939659dfd3ed4ff36dde532782207cfb0e5fbcf6
Btrfs: deal with existing encompassing extent map in btrfs_get_extent()

My QEMU VM was seeing inexplicable I/O errors that I tracked down to
errors coming from the qcow2 virtual drive in the host system. The qcow2
file is a nocow file on my Btrfs drive, which QEMU opens with O_DIRECT.
Every once in awhile, pread() or pwrite() would return EEXIST, which
makes no sense. This turned out to be a bug in btrfs_get_extent().

Commit 8dff9c853410 ("Btrfs: deal with duplciates during extent_map
insertion in btrfs_get_extent") fixed a case in btrfs_get_extent() where
two threads race on adding the same extent map to an inode's extent map
tree. However, if the added em is merged with an adjacent em in the
extent tree, then we'll end up with an existing extent that is not
identical to but instead encompasses the extent we tried to add. When we
call merge_extent_mapping() to find the nonoverlapping part of the new
em, the arithmetic overflows because there is no such thing. We then end
up trying to add a bogus em to the em_tree, which results in a EEXIST
that can bubble all the way up to userspace.

Fix it by extending the identical extent map special case.

Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/inode.c