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, 15 Mar 2022 10:50:49 -0700 [thread overview]
Message-ID: <d153bb2e-5f95-47d0-43db-b95c577e2b91@linaro.org> (raw)
In-Reply-To: <20220307054557.v4qqm4ushmm55v4y@riteshh-domain>
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
next prev parent reply other threads:[~2022-03-15 17:50 UTC|newest]
Thread overview: 16+ 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
2022-03-14 21:27 ` Tadeusz Struk
2022-03-15 17:50 ` Tadeusz Struk [this message]
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
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=d153bb2e-5f95-47d0-43db-b95c577e2b91@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).