summaryrefslogtreecommitdiffstats
path: root/fs/btrfs
diff options
context:
space:
mode:
authorDavid Sterba <dsterba@suse.com>2020-01-08 15:29:53 +0100
committerDavid Sterba <dsterba@suse.com>2020-01-20 16:41:01 +0100
commit4babad10198fa73fe73239d02c2e99e3333f5f5c (patch)
tree7f7160042a0f956aa9df99d2f5111402196cb1cc /fs/btrfs
parent94f8c46566485974c155c5cb4507f03873cf4d71 (diff)
downloadlinux-4babad10198fa73fe73239d02c2e99e3333f5f5c.tar.gz
linux-4babad10198fa73fe73239d02c2e99e3333f5f5c.tar.bz2
linux-4babad10198fa73fe73239d02c2e99e3333f5f5c.zip
btrfs: safely advance counter when looking up bio csums
Dan's smatch tool reports fs/btrfs/file-item.c:295 btrfs_lookup_bio_sums() warn: should this be 'count == -1' which points to the while (count--) loop. With count == 0 the check itself could decrement it to -1. There's a WARN_ON a few lines below that has never been seen in practice though. It turns out that the value of page_bytes_left matches the count (by sectorsize multiples). The loop never reaches the state where count would go to -1, because page_bytes_left == 0 is found first and this breaks out. For clarity, use only plain check on count (and only for positive value), decrement safely inside the loop. Any other discrepancy after the whole bio list processing should be reported by the exising WARN_ON_ONCE as well. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by: Josef Bacik <josef@toxicpanda.com> Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'fs/btrfs')
-rw-r--r--fs/btrfs/file-item.c3
1 files changed, 2 insertions, 1 deletions
diff --git a/fs/btrfs/file-item.c b/fs/btrfs/file-item.c
index bb374042d297..c2f365662d55 100644
--- a/fs/btrfs/file-item.c
+++ b/fs/btrfs/file-item.c
@@ -283,7 +283,8 @@ found:
csum += count * csum_size;
nblocks -= count;
next:
- while (count--) {
+ while (count > 0) {
+ count--;
disk_bytenr += fs_info->sectorsize;
offset += fs_info->sectorsize;
page_bytes_left -= fs_info->sectorsize;