From: Qu Wenruo <wqu@suse.com>
To: Daniel Vacek <neelx@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/2] btrfs: use proper inclusive end in extent_fiemap()
Date: Tue, 28 Jul 2026 18:50:01 +0930 [thread overview]
Message-ID: <982bfba1-d2e6-45ee-9204-0029bd9daa8d@suse.com> (raw)
In-Reply-To: <CAPjX3FenCVAukra4Djz8r4ShRi4M6DxpHH5-Lm1XyrsahFn=nQ@mail.gmail.com>
在 2026/7/28 18:47, Daniel Vacek 写道:
> On Tue, 28 Jul 2026 at 10:40, Qu Wenruo <wqu@suse.com> wrote:
>> 在 2026/7/28 17:35, Daniel Vacek 写道:
>>> On Tue, 28 Jul 2026 at 08:46, Qu Wenruo <wqu@suse.com> wrote:
>>>> The @end parameter for all extent io tree helpers is inclusive, but
>>>> the call site in extent_fiemap() is passing exclusive end.
>>>>
>>>> Fix it to follow the common pattern.
>>>>
>>>> Fixes: ac3c0d36a2a2 ("btrfs: make fiemap more efficient and accurate reporting extent sharedness")
>>>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>>>> ---
>>>> fs/btrfs/fiemap.c | 8 ++++----
>>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/fs/btrfs/fiemap.c b/fs/btrfs/fiemap.c
>>>> index ba6a360074c0..2f2ae0b76799 100644
>>>> --- a/fs/btrfs/fiemap.c
>>>> +++ b/fs/btrfs/fiemap.c
>>>> @@ -657,7 +657,7 @@ static int extent_fiemap(struct btrfs_inode *inode,
>>>>
>>>> restart:
>>>> range_start = round_down(start, sectorsize);
>>>> - range_end = round_up(start + len, sectorsize);
>>>> + range_end = round_up(start + len, sectorsize) - 1;
>>>> prev_extent_end = range_start;
>>>>
>>>> btrfs_lock_extent(&inode->io_tree, range_start, range_end, &cached_state);
>>>> @@ -710,7 +710,7 @@ static int extent_fiemap(struct btrfs_inode *inode,
>>>>
>>>> /* We have in implicit hole (NO_HOLES feature enabled). */
>>>> if (prev_extent_end < key.offset) {
>>>> - const u64 hole_end = min(key.offset, range_end) - 1;
>>>> + const u64 hole_end = min(key.offset - 1, range_end);
>>>>
>>>> ret = fiemap_process_hole(inode, fieinfo, &cache,
>>>> &delalloc_cached_state,
>>>> @@ -812,10 +812,10 @@ static int extent_fiemap(struct btrfs_inode *inode,
>>>> if (!stopped && prev_extent_end < range_end) {
>>>> ret = fiemap_process_hole(inode, fieinfo, &cache,
>>>> &delalloc_cached_state, backref_ctx,
>>>> - 0, 0, 0, prev_extent_end, range_end - 1);
>>>> + 0, 0, 0, prev_extent_end, range_end);
>>>> if (ret < 0)
>>>> goto out_unlock;
>>>> - prev_extent_end = range_end;
>>>> + prev_extent_end = range_end + 1;
>>>> }
>>>>
>>>> if (cache.cached && cache.offset + cache.len >= last_extent_end) {
>>>> --
>>>> 2.54.0
>>>
>>> I don't really get why you left out these:
>>>
>>> @@ -680,7 +680,7 @@ static int extent_fiemap(struct btrfs_inode *inode,
>>> goto check_eof_delalloc;
>>> }
>>>
>>> - while (prev_extent_end < range_end) {
>>> + while (prev_extent_end <= range_end) {
>>> struct extent_buffer *leaf = path->nodes[0];
>>> struct btrfs_file_extent_item *ei;
>>> struct btrfs_key key;
>>> @@ -809,13 +809,13 @@ static int extent_fiemap(struct btrfs_inode *inode,
>>> }
>>>
>>> check_eof_delalloc:
>>> - if (!stopped && prev_extent_end < range_end) {
>>> + if (!stopped && prev_extent_end <= range_end) {
>>> ret = fiemap_process_hole(inode, fieinfo, &cache,
>>> &delalloc_cached_state, backref_ctx,
>>>
>>> Am I missing something?
>>
>> Because we won't reach the == case at all.
>>
>> The start is always increased by a value aligned to sectorsize.
>
> I understand round_down() possibly decreases not increases. So if
> start and start + len - 1 fall into the same block you get the ==
> case. Am I wrong?
The only case when that happen is when @len is 0, which is already
rejected by fiemap_prep()
>
>> For inclusive range_end, we either completely pass it by 1, or smaller
>> than it.
>>
>> So that "==" will never be hit.>
>>> --nX
>>
next prev parent reply other threads:[~2026-07-28 9:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-28 6:39 [PATCH 0/2] btrfs: add basic alignment checks for extent_state Qu Wenruo
2026-07-28 6:39 ` [PATCH 1/2] btrfs: use proper inclusive end in extent_fiemap() Qu Wenruo
2026-07-28 7:35 ` Filipe Manana
2026-07-28 8:48 ` Qu Wenruo
2026-07-28 8:05 ` Daniel Vacek
2026-07-28 8:40 ` Qu Wenruo
2026-07-28 9:17 ` Daniel Vacek
2026-07-28 9:20 ` Qu Wenruo [this message]
2026-07-28 9:47 ` Daniel Vacek
2026-07-28 6:39 ` [PATCH 2/2] btrfs: add validation for extent states Qu Wenruo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=982bfba1-d2e6-45ee-9204-0029bd9daa8d@suse.com \
--to=wqu@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=neelx@suse.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox