All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tadeusz Struk <tadeusz.struk@linaro.org>
To: Ritesh Harjani <riteshh@linux.ibm.com>
Cc: Theodore Ts'o <tytso@mit.edu>,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	linux-ext4@vger.kernel.org
Subject: Re: BUG in ext4_ind_remove_space
Date: Tue, 8 Mar 2022 09:58:49 -0800	[thread overview]
Message-ID: <3a901543-60cf-6658-cb9f-45e567ae2151@linaro.org> (raw)
In-Reply-To: <20220307054557.v4qqm4ushmm55v4y@riteshh-domain>

On 3/6/22 21:45, Ritesh Harjani wrote:
> On 22/03/04 01:38AM, Ritesh Harjani wrote:
>> On 22/03/03 07:37AM, Tadeusz Struk wrote:
>>> On 3/3/22 06:56, Ritesh Harjani wrote:
>>>> On 22/03/02 03:14PM, Tadeusz Struk wrote:
>>>>> On 2/25/22 11:19, Tadeusz Struk wrote:
>>>>>>> I can verify this sometime next week when I get back to it.
>>>>>>> But thanks for reporting the issue :)
>>>>>>
>>>>>> Next week is perfectly fine. Thanks for looking into it.
>>>>>
>>>>> Hi Ritesh,
>>>>> Did you have chance to look into this?
>>>>> If you want I can send a patch that fixes the off by 1 calculation error.
>>>>
>>>> Hi Tadeusz,
>>>>
>>>> I wanted to look at that path a bit more before sending that patch.
>>>> Last analysis by me was more of a cursory look at the kernel dmesg log which you
>>>> had shared.
>>>>
>>>> In case if you want to pursue that issue and spend time on it, then feel free to
>>>> do it.
>>>>
>>>> I got pulled into number of other things last week and this week. So didn't get
>>>> a chance to look into it yet. I hope to look into this soon (if no one else
>>>> picks up :))
>>>
>>> I'm not familiar with the internals of ext4 implementation so I would rather
>>> have someone who knows it look at it.
>>
>> No problem. I am willing to look into this anyways.
>> btw, this issue could be seen easily with below cmd on non-extent ext4 FS.
>>
>> sudo xfs_io -f -c "truncate 0x4010040c000" -c "fsync" -c "fpunch 0x1000000 0xffefffff000" testfile
> 
> Just FYI - The change which we discussed to fix the max_block to max_end_block, is not correct.
> Since it will still leave 1 block at the end after punch operation, if the file has s_bitmap_maxbytes size.
> This is due to the fact that, "end" is expected to be 1 block after the end of last block.
> 
> Will try look into it to see how can we fix this.
> 
> 1210 /**
> 1211  *      ext4_ind_remove_space - remove space from the range
> 1212  *      @handle: JBD handle for this transaction
> 1213  *      @inode: inode we are dealing with
> 1214  *      @start: First block to remove
> 1215  *      @end:   One block after the last block to remove (exclusive)
> 1216  *
> 1217  *      Free the blocks in the defined range (end is exclusive endpoint of
> 1218  *      range). This is used by ext4_punch_hole().
> 1219  */
> 1220 int ext4_ind_remove_space(handle_t *handle, struct inode *inode,
> 1221                           ext4_lblk_t start, ext4_lblk_t end)
> 

Hi Ritesh,
Thanks for update. Let me know if I can be of any help to you.

-- 
Thanks,
Tadeusz

  reply	other threads:[~2022-03-08 17:58 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-25  1:12 BUG in ext4_ind_remove_space Tadeusz Struk
2022-02-25 17:10 ` Ritesh Harjani
2022-02-25 19:19   ` Tadeusz Struk
2022-03-02 23:14     ` Tadeusz Struk
2022-03-03 14:56       ` Ritesh Harjani
2022-03-03 15:37         ` Tadeusz Struk
2022-03-03 20:08           ` Ritesh Harjani
2022-03-07  5:45             ` Ritesh Harjani
2022-03-08 17:58               ` Tadeusz Struk [this message]
2022-03-14 21:27               ` Tadeusz Struk
2022-03-15 17:50               ` Tadeusz Struk
2022-03-15 19:15                 ` [PATCH] ext4: check if offset+length is within a valid range in fallocate Tadeusz Struk
2022-03-15 20:39                   ` Tadeusz Struk
2022-03-16  1:22                   ` kernel test robot
2022-03-16  1:22                   ` kernel test robot
2022-03-16  2:14                     ` Tadeusz Struk
2022-03-16  2:14                       ` Tadeusz Struk

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=3a901543-60cf-6658-cb9f-45e567ae2151@linaro.org \
    --to=tadeusz.struk@linaro.org \
    --cc=adilger.kernel@dilger.ca \
    --cc=linux-ext4@vger.kernel.org \
    --cc=riteshh@linux.ibm.com \
    --cc=tytso@mit.edu \
    /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 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.