On Thu, Jul 17, 2014 at 11:44:14AM +0800, Wang Shilong wrote: > btrfs_next_leaf() will use current leaf's last key to search > and then return a bigger one. So it may still return a file extent > item that is smaller than expected value and we will > get an overflow here for @em->len. > > This is easy to reproduce for Btrfs Direct writting, it did not > cause any problem, because writting will re-insert right mapping later. > > However, by hacking code to make DIO support compression, wrong extent > mapping is kept and it encounter merging failure(EEXIST) quickly. So this cannot happen normally (because compression and DIO do not work together)? > Fix this problem by looping to find next file extent item that is bigger > than @start or we could not find anything more. > > Signed-off-by: Wang Shilong <wangsl.fnst@xxxxxxxxxxxxxx> Reviewed-by: David Sterba <dsterba@xxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
