| Message ID | 20190225132416.15840-2-jthumshirn@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v4,1/2] btrfs: factor our read/write stage off csum_tree_block() into its callers | expand |
On Mon, Feb 25, 2019 at 02:24:16PM +0100, Johannes Thumshirn wrote: > Since commit d2e174d5d3ee ("btrfs: document extent mapping assumptions in > checksum") we have a comment in place why map_private_extent_buffer() > can't return 1 in the csum_tree_block() case. > > Make this a bit more explicit and WARN_ON() in case this this assumption > breaks. > > Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> Reviewed-by: David Sterba <dsterba@suse.com>
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 8090e8f4ccc2..21407252eb44 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -285,7 +285,7 @@ static int csum_tree_block(struct extent_buffer *buf, */ err = map_private_extent_buffer(buf, offset, 32, &kaddr, &map_start, &map_len); - if (err) + if (WARN_ON(err)) return err; cur_len = min(len, map_len - (offset - map_start)); crc = btrfs_csum_data(kaddr + offset - map_start,
Since commit d2e174d5d3ee ("btrfs: document extent mapping assumptions in checksum") we have a comment in place why map_private_extent_buffer() can't return 1 in the csum_tree_block() case. Make this a bit more explicit and WARN_ON() in case this this assumption breaks. Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> --- fs/btrfs/disk-io.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)