lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 8 Mar 2022 09:58:49 -0800
From:   Tadeusz Struk <>
To:     Ritesh Harjani <>
Cc:     Theodore Ts'o <>,
        Andreas Dilger <>,
Subject: Re: BUG in ext4_ind_remove_space

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.


Powered by blists - more mailing lists