]> git.baikalelectronics.ru Git - kernel.git/commit
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)
commit1dc0f210f487e170532691a2545b68457d7a3420
tree587d0b12dd206b5e6e475eb0fc95679208838f4d
parentef1e98428e45c718a4aa630159c5868e52210aee
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 3ced51da4378 ("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