Linux Btrfs filesystem development
 help / color / mirror / Atom feed
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
>>


  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