lists.openwall.net | 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
| ||
|
Date: Tue, 8 Mar 2022 09:58:49 -0800 From: Tadeusz Struk <tadeusz.struk@...aro.org> To: Ritesh Harjani <riteshh@...ux.ibm.com> Cc: Theodore Ts'o <tytso@....edu>, Andreas Dilger <adilger.kernel@...ger.ca>, linux-ext4@...r.kernel.org 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. -- Thanks, Tadeusz
Powered by blists - more mailing lists