Linux EXT4 FS development
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: zhanchengbin <zhanchengbin1@huawei.com>
Cc: Jan Kara <jack@suse.cz>,
	tytso@mit.edu, jack@suse.com, linux-ext4@vger.kernel.org,
	yi.zhang@huawei.com, linfeilong@huawei.com,
	liuzhiqiang26@huawei.com, kernel test robot <lkp@intel.com>
Subject: Re: [PATCH v5 2/2] ext4: clear the verified flag of the modified leaf or idx if error
Date: Thu, 16 Feb 2023 14:03:05 +0100	[thread overview]
Message-ID: <20230216130305.nrbtd42tppxhbynn@quack3> (raw)
In-Reply-To: <6e6bb868-7107-3528-db6d-0ddc275f6326@huawei.com>

On Thu 16-02-23 15:25:23, zhanchengbin wrote:
> The last patch did not take into account path[0].p_bh == NULL, so I
> reworked the code.
> 
> diff --git a/fs/ext4/extents.c b/fs/ext4/extents.c
> index 0f95e857089e..05585afae0db 100644
> --- a/fs/ext4/extents.c
> +++ b/fs/ext4/extents.c
> @@ -1750,13 +1750,19 @@ static int ext4_ext_correct_indexes(handle_t
> *handle, struct inode *inode,
>                         break;
>                 err = ext4_ext_get_access(handle, inode, path + k);
>                 if (err)
> -                       break;
> +                       goto clean;
>                 path[k].p_idx->ei_block = border;
>                 err = ext4_ext_dirty(handle, inode, path + k);
>                 if (err)
> -                       break;
> +                       goto clean;
>         }
> +       return 0;
> 
> +clean:
> +       while (k++ < depth) {
> +               /* k here will not be 0, so don't consider the case where
> path[0].p_bh is NULL */

Please avoid the line over 80 characters.

> +               clear_buffer_verified(path[k].p_bh);
> +       }
>         return err;
>  }
> 
> @@ -2304,6 +2310,7 @@ static int ext4_ext_rm_idx(handle_t *handle, struct
> inode *inode,
>  {
>         int err;
>         ext4_fsblk_t leaf;
> +       int b_depth = depth;
> 
>         /* free index block */
>         depth--;
> @@ -2339,11 +2346,18 @@ static int ext4_ext_rm_idx(handle_t *handle, struct
> inode *inode,
>                 path--;
>                 err = ext4_ext_get_access(handle, inode, path);
>                 if (err)
> -                       break;
> +                       goto clean;
>                 path->p_idx->ei_block = (path+1)->p_idx->ei_block;
>                 err = ext4_ext_dirty(handle, inode, path);
>                 if (err)
> -                       break;
> +                       goto clean;
> +       }
> +       return 0;
> +
> +clean:
> +       while (depth++ < b_depth - 1) {
> +               /* depth here will not be 0, so don't consider the case
> where path[0].p_bh is NULL */

Again please avoid the overly long line.

> +               clear_buffer_verified(path[depth].p_bh);
>         }

I think this is still problematic because 'path' is being updated in the
above loop as well so this will still access beyond the end of the array.
So I think you first need to modify ext4_ext_rm_idx() to leave 'path' alone
and just index it like ext4_ext_correct_indexes() does it (separate patch
please) and then add this error recovery path.

> On 2023/2/14 20:52, Jan Kara wrote:
> > 
> > This would be more understandable as:
> > 
> > 	if (k >= 0)
> > 		while (k++ < depth)
> > 			...
> > 
> > Also the loop is IMO wrong because it will run with k == depth as well (due
> > to post-increment) and that is not initialized. Furthermore it will run
> > also if we exit the previous loop due to:
> > 
> >                  /* change all left-side indexes */
> >                  if (path[k+1].p_idx != EXT_FIRST_INDEX(path[k+1].p_hdr))
> >                          break;
> > 
> > which is unwanted as well. Which suggests that you didn't test your changes
> > much (if at all...). So please make sure your changes are tested next time.
> > Thank you!
> > 
> I only ran xfstest locally. Do you have any better suggestions?

Yes that's good. But that will not run your new error handling code at all,
will it? It would be good if you also ran the reproducer that presumably
triggered these fixes to exercise the new code...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

      reply	other threads:[~2023-02-16 13:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-13  8:05 [PATCH v5 0/2] fix extents need to be restored when ext4_ext_insert_extent failed zhanchengbin
2023-02-13  8:05 ` [PATCH v5 1/2] ext4: fix inode tree inconsistency caused by ENOMEM in ext4_split_extent_at zhanchengbin
2023-02-13  8:05 ` [PATCH v5 2/2] ext4: clear the verified flag of the modified leaf or idx if error zhanchengbin
2023-02-14 12:52   ` Jan Kara
2023-02-16  7:25     ` zhanchengbin
2023-02-16 13:03       ` Jan Kara [this message]

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=20230216130305.nrbtd42tppxhbynn@quack3 \
    --to=jack@suse.cz \
    --cc=jack@suse.com \
    --cc=linfeilong@huawei.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=liuzhiqiang26@huawei.com \
    --cc=lkp@intel.com \
    --cc=tytso@mit.edu \
    --cc=yi.zhang@huawei.com \
    --cc=zhanchengbin1@huawei.com \
    /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