Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 7 Mar 2022 11:15:57 +0530
From:   Ritesh Harjani <riteshh@linux.ibm.com>
To:     Tadeusz Struk <tadeusz.struk@linaro.org>
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
Message-ID: <20220307054557.v4qqm4ushmm55v4y@riteshh-domain>
References: <48308b02-149b-1c47-115a-1a268dac6e24@linaro.org>
 <20220225171016.zwhp62b3yzgewk6l@riteshh-domain>
 <25749d7d-7036-0b71-3dd8-7b04dcc430e4@linaro.org>
 <346904fd-112a-8d57-9221-b5c729ea6056@linaro.org>
 <20220303145651.ackek7wotphg26gm@riteshh-domain>
 <995d8b3c-44ee-e190-42ae-75f2562b8d6b@linaro.org>
 <20220303200804.hugwhtqovxiutkfd@riteshh-domain>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20220303200804.hugwhtqovxiutkfd@riteshh-domain>
Precedence: bulk

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)

-ritesh