Re: BUG in ext4_ind_remove_space

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 3/6/22 21:45, Ritesh Harjani wrote:
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)

So in that case, in ext4_punch_hole(), what should be done is:

if offset + length > sbi->s_bitmap_maxbytes - inode->i_sb->s_blocksize

it either needs to update the length to:
length = sbi->s_bitmap_maxbytes - inode->i_sb->s_blocksize - offset;

or -ENOSPC should be returned, which would be more consistent with the `man 2 fallocate`:

"ERRORS:
...
ENOSPC There is not enough space left on the device containing the file referred to by fd."

Please let me know if my reckoning is correct, and if so which option you
prefer and I will follow with a patch.

--
Thanks,
Tadeusz



[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux