All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] btrfs: safely advance counter when looking up bio csums
@ 2020-01-08 14:40 David Sterba
  2020-01-08 15:01 ` Josef Bacik
  0 siblings, 1 reply; 2+ messages in thread
From: David Sterba @ 2020-01-08 14:40 UTC (permalink / raw)
  To: linux-btrfs; +Cc: David Sterba, Dan Carpenter

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>
Signed-off-by: David Sterba <dsterba@suse.com>
---
 fs/btrfs/file-item.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

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 @@ blk_status_t btrfs_lookup_bio_sums(struct inode *inode, struct bio *bio,
 		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;
-- 
2.24.0


^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] btrfs: safely advance counter when looking up bio csums
  2020-01-08 14:40 [PATCH] btrfs: safely advance counter when looking up bio csums David Sterba
@ 2020-01-08 15:01 ` Josef Bacik
  0 siblings, 0 replies; 2+ messages in thread
From: Josef Bacik @ 2020-01-08 15:01 UTC (permalink / raw)
  To: David Sterba, linux-btrfs; +Cc: Dan Carpenter

On 1/8/20 9:40 AM, David Sterba wrote:
> 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>
> Signed-off-by: David Sterba <dsterba@suse.com>

Reviewed-by: Josef Bacik <josef@toxicpanda.com>

Thanks,

Josef

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-01-08 15:01 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-08 14:40 [PATCH] btrfs: safely advance counter when looking up bio csums David Sterba
2020-01-08 15:01 ` Josef Bacik

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.