* [PATCH] btrfs: fix off-by-one chunk length calculation at contains_pending_extent()
@ 2024-02-29 10:50 fdmanana
2024-03-01 21:11 ` Josef Bacik
2024-03-02 0:35 ` Qu Wenruo
0 siblings, 2 replies; 3+ messages in thread
From: fdmanana @ 2024-02-29 10:50 UTC (permalink / raw)
To: linux-btrfs
From: Filipe Manana <fdmanana@suse.com>
At contains_pending_extent() the value of the end offset of a chunk we
found in the device's allocation state io tree is inclusive, so when
we calculate the length we pass to the in_range() macro, we must sum
1 to the expression "physical_end - physical_offset".
In practice the wrong calculation should be harmless as chunks sizes
are never 1 byte and we should never have 1 byte ranges of unallocated
space. Nevertheless fix the wrong calculation.
Fixes: 1c11b63eff2a ("btrfs: replace pending/pinned chunks lists with io tree")
Reported-by: Alex Lyakas <alex.lyakas@zadara.com>
Link: https://lore.kernel.org/linux-btrfs/CAOcd+r30e-f4R-5x-S7sV22RJPe7+pgwherA6xqN2_qe7o4XTg@mail.gmail.com/
Signed-off-by: Filipe Manana <fdmanana@suse.com>
---
fs/btrfs/volumes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 3cc947a42116..473fe92274d9 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -1401,7 +1401,7 @@ static bool contains_pending_extent(struct btrfs_device *device, u64 *start,
if (in_range(physical_start, *start, len) ||
in_range(*start, physical_start,
- physical_end - physical_start)) {
+ physical_end + 1 - physical_start)) {
*start = physical_end + 1;
return true;
}
--
2.40.1
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH] btrfs: fix off-by-one chunk length calculation at contains_pending_extent()
2024-02-29 10:50 [PATCH] btrfs: fix off-by-one chunk length calculation at contains_pending_extent() fdmanana
@ 2024-03-01 21:11 ` Josef Bacik
2024-03-02 0:35 ` Qu Wenruo
1 sibling, 0 replies; 3+ messages in thread
From: Josef Bacik @ 2024-03-01 21:11 UTC (permalink / raw)
To: fdmanana; +Cc: linux-btrfs
On Thu, Feb 29, 2024 at 10:50:03AM +0000, fdmanana@kernel.org wrote:
> From: Filipe Manana <fdmanana@suse.com>
>
> At contains_pending_extent() the value of the end offset of a chunk we
> found in the device's allocation state io tree is inclusive, so when
> we calculate the length we pass to the in_range() macro, we must sum
> 1 to the expression "physical_end - physical_offset".
>
> In practice the wrong calculation should be harmless as chunks sizes
> are never 1 byte and we should never have 1 byte ranges of unallocated
> space. Nevertheless fix the wrong calculation.
>
> Fixes: 1c11b63eff2a ("btrfs: replace pending/pinned chunks lists with io tree")
> Reported-by: Alex Lyakas <alex.lyakas@zadara.com>
> Link: https://lore.kernel.org/linux-btrfs/CAOcd+r30e-f4R-5x-S7sV22RJPe7+pgwherA6xqN2_qe7o4XTg@mail.gmail.com/
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
> ---
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Thanks,
Josef
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: [PATCH] btrfs: fix off-by-one chunk length calculation at contains_pending_extent()
2024-02-29 10:50 [PATCH] btrfs: fix off-by-one chunk length calculation at contains_pending_extent() fdmanana
2024-03-01 21:11 ` Josef Bacik
@ 2024-03-02 0:35 ` Qu Wenruo
1 sibling, 0 replies; 3+ messages in thread
From: Qu Wenruo @ 2024-03-02 0:35 UTC (permalink / raw)
To: fdmanana, linux-btrfs
在 2024/2/29 21:20, fdmanana@kernel.org 写道:
> From: Filipe Manana <fdmanana@suse.com>
>
> At contains_pending_extent() the value of the end offset of a chunk we
> found in the device's allocation state io tree is inclusive, so when
> we calculate the length we pass to the in_range() macro, we must sum
> 1 to the expression "physical_end - physical_offset".
>
> In practice the wrong calculation should be harmless as chunks sizes
> are never 1 byte and we should never have 1 byte ranges of unallocated
> space. Nevertheless fix the wrong calculation.
>
> Fixes: 1c11b63eff2a ("btrfs: replace pending/pinned chunks lists with io tree")
> Reported-by: Alex Lyakas <alex.lyakas@zadara.com>
> Link: https://lore.kernel.org/linux-btrfs/CAOcd+r30e-f4R-5x-S7sV22RJPe7+pgwherA6xqN2_qe7o4XTg@mail.gmail.com/
> Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Qu Wenruo <wqu@suse.com>
Thankfully it's mostly harmless.
Thanks,
Qu
> ---
> fs/btrfs/volumes.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> index 3cc947a42116..473fe92274d9 100644
> --- a/fs/btrfs/volumes.c
> +++ b/fs/btrfs/volumes.c
> @@ -1401,7 +1401,7 @@ static bool contains_pending_extent(struct btrfs_device *device, u64 *start,
>
> if (in_range(physical_start, *start, len) ||
> in_range(*start, physical_start,
> - physical_end - physical_start)) {
> + physical_end + 1 - physical_start)) {
> *start = physical_end + 1;
> return true;
> }
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-03-02 0:35 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-02-29 10:50 [PATCH] btrfs: fix off-by-one chunk length calculation at contains_pending_extent() fdmanana
2024-03-01 21:11 ` Josef Bacik
2024-03-02 0:35 ` Qu Wenruo
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.