From: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
To: Ye Bin <yebin@huaweicloud.com>,
tytso@mit.edu, adilger.kernel@dilger.ca,
linux-ext4@vger.kernel.org
Cc: jack@suse.cz, Ojaswin Mujoo <ojaswin@linux.ibm.com>
Subject: Re: [PATCH v4 3/5] ext4: fix the error handling process in extents_kunit_init).
Date: Fri, 20 Mar 2026 07:26:08 +0530 [thread overview]
Message-ID: <ldfnxo07.ritesh.list@gmail.com> (raw)
In-Reply-To: <20260319125434.333117-4-yebin@huaweicloud.com>
Ye Bin <yebin@huaweicloud.com> writes:
> From: Ye Bin <yebin10@huawei.com>
>
> The error processing in extents_kunit_init() is improper, causing
> resource leakage.
> Reconstruct the error handling process to prevent potential resource
> leaks
>
> Fixes: cb1e0c1d1fad ("ext4: kunit tests for extent splitting and conversion")
> Signed-off-by: Ye Bin <yebin10@huawei.com>
> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> ---
> fs/ext4/extents-test.c | 43 ++++++++++++++++++++++++++++++------------
> 1 file changed, 31 insertions(+), 12 deletions(-)
>
> diff --git a/fs/ext4/extents-test.c b/fs/ext4/extents-test.c
> index 3d4663d99eb1..4ce3f81f6409 100644
> --- a/fs/ext4/extents-test.c
> +++ b/fs/ext4/extents-test.c
> @@ -225,33 +225,37 @@ static int extents_kunit_init(struct kunit *test)
> (struct kunit_ext_test_param *)(test->param_value);
> int err;
>
> - sb = sget(&ext_fs_type, NULL, ext_set, 0, NULL);
> - if (IS_ERR(sb))
> - return PTR_ERR(sb);
> -
> - sb->s_blocksize = 4096;
> - sb->s_blocksize_bits = 12;
> -
> sbi = kzalloc_obj(struct ext4_sb_info);
> if (sbi == NULL)
> return -ENOMEM;
>
> + sb = sget(&ext_fs_type, NULL, ext_set, 0, NULL);
> + if (IS_ERR(sb)) {
> + kfree(sbi);
> + return PTR_ERR(sb);
> + }
> +
> sbi->s_sb = sb;
> sb->s_fs_info = sbi;
>
> + sb->s_blocksize = 4096;
> + sb->s_blocksize_bits = 12;
> +
> if (!param || !param->disable_zeroout)
> sbi->s_extent_max_zeroout_kb = 32;
>
> /* setup the mock inode */
> k_ctx.k_ei = kzalloc_obj(struct ext4_inode_info);
> - if (k_ctx.k_ei == NULL)
> - return -ENOMEM;
> + if (k_ctx.k_ei == NULL) {
> + err = -ENOMEM;
> + goto out_deactivate;
> + }
> ei = k_ctx.k_ei;
> inode = &ei->vfs_inode;
>
> err = ext4_es_register_shrinker(sbi);
> if (err)
> - return err;
> + goto out_deactivate;
Even though the patch looks ok, but still wanted to check if ...
Do you think we can move ext4_es_register_shrinker() before setting up
the mock inode and on error we simply return err?
That way, there won't be any ambiguity in the error handling for calling
ext4_es_unregister_shrinker()?
>
> ext4_es_init_tree(&ei->i_es_tree);
> rwlock_init(&ei->i_es_lock);
> @@ -267,8 +271,10 @@ static int extents_kunit_init(struct kunit *test)
> inode->i_sb = sb;
>
> k_ctx.k_data = kzalloc(EXT_DATA_LEN * 4096, GFP_KERNEL);
> - if (k_ctx.k_data == NULL)
> - return -ENOMEM;
> + if (k_ctx.k_data == NULL) {
> + err = -ENOMEM;
> + goto out_deactivate;
> + }
>
> /*
> * set the data area to a junk value
> @@ -313,6 +319,19 @@ static int extents_kunit_init(struct kunit *test)
> up_write(&sb->s_umount);
>
> return 0;
> +
> +out_deactivate:
> + kfree(k_ctx.k_ei);
> + k_ctx.k_ei = NULL;
> +
> + kfree(k_ctx.k_data);
> + k_ctx.k_data = NULL;
> +
> + ext4_es_unregister_shrinker(sbi);
-ritesh
next prev parent reply other threads:[~2026-03-20 2:04 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 12:54 [PATCH v4 0/5] Fix some issues about ext4-test Ye Bin
2026-03-19 12:54 ` [PATCH v4 1/5] ext4: fix miss unlock 'sb->s_umount' in extents_kunit_init() Ye Bin
2026-03-19 12:54 ` [PATCH v4 2/5] ext4: call deactivate_super() in extents_kunit_exit() Ye Bin
2026-03-21 7:54 ` Ojaswin Mujoo
2026-03-19 12:54 ` [PATCH v4 3/5] ext4: fix the error handling process in extents_kunit_init) Ye Bin
2026-03-20 1:56 ` Ritesh Harjani [this message]
2026-03-30 7:02 ` yebin (H)
2026-03-19 12:54 ` [PATCH v4 4/5] ext4: fix possible null-ptr-deref in extents_kunit_exit() Ye Bin
2026-03-19 12:54 ` [PATCH v4 5/5] ext4: fix possible null-ptr-deref in mbt_kunit_exit() Ye Bin
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=ldfnxo07.ritesh.list@gmail.com \
--to=ritesh.list@gmail.com \
--cc=adilger.kernel@dilger.ca \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=ojaswin@linux.ibm.com \
--cc=tytso@mit.edu \
--cc=yebin@huaweicloud.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.