* Re: [PATCH v3 5/5] ext4: fix possible null-ptr-deref in mbt_kunit_exit()
From: Ritesh Harjani @ 2026-03-14 12:36 UTC (permalink / raw)
To: Ye Bin, tytso, adilger.kernel, linux-ext4; +Cc: jack
In-Reply-To: <20260314074903.1314851-6-yebin@huaweicloud.com>
Ye Bin <yebin@huaweicloud.com> writes:
> From: Ye Bin <yebin10@huawei.com>
>
> There's issue as follows:
> # test_new_blocks_simple: failed to initialize: -12
> KASAN: null-ptr-deref in range [0x0000000000000638-0x000000000000063f]
> Tainted: [E]=UNSIGNED_MODULE, [N]=TEST
> RIP: 0010:mbt_kunit_exit+0x5e/0x3e0 [ext4_test]
> Call Trace:
> <TASK>
> kunit_try_run_case_cleanup+0xbc/0x100 [kunit]
> kunit_generic_run_threadfn_adapter+0x89/0x100 [kunit]
> kthread+0x408/0x540
> ret_from_fork+0xa76/0xdf0
> ret_from_fork_asm+0x1a/0x30
>
> If mbt_kunit_init() init testcase failed will lead to null-ptr-deref.
> So add test if 'sb' is inited success in mbt_kunit_exit().
>
LGTM.
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Fixes: 7c9fa399a369 ("ext4: add first unit test for ext4_mb_new_blocks_simple in mballoc")
> Signed-off-by: Ye Bin <yebin10@huawei.com>
> ---
> fs/ext4/mballoc-test.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ext4/mballoc-test.c b/fs/ext4/mballoc-test.c
> index c75b91ae0cf0..90ed505fa4b1 100644
> --- a/fs/ext4/mballoc-test.c
> +++ b/fs/ext4/mballoc-test.c
> @@ -362,7 +362,6 @@ static int mbt_kunit_init(struct kunit *test)
> return ret;
> }
>
> - test->priv = sb;
> kunit_activate_static_stub(test,
> ext4_read_block_bitmap_nowait,
> ext4_read_block_bitmap_nowait_stub);
> @@ -383,6 +382,8 @@ static int mbt_kunit_init(struct kunit *test)
> return -ENOMEM;
> }
>
> + test->priv = sb;
> +
> return 0;
> }
>
> @@ -390,6 +391,9 @@ static void mbt_kunit_exit(struct kunit *test)
> {
> struct super_block *sb = (struct super_block *)test->priv;
>
> + if (!sb)
> + return;
> +
> mbt_mb_release(sb);
> mbt_ctx_release(sb);
> mbt_ext4_free_super_block(sb);
> --
> 2.34.1
^ permalink raw reply
* Re: [PATCH 1/1] filefrag: fix fibmap error message
From: Ritesh Harjani @ 2026-03-14 12:48 UTC (permalink / raw)
To: David Timber, linux-ext4; +Cc: David Timber
In-Reply-To: <20260303115637.453629-2-dxdt@dev.snart.me>
David Timber <dxdt@dev.snart.me> writes:
> When an errno other than EINVAL, ENOTTY or EPERM is returned from FIBMAP
> ioctl, the negative errno is passsed to strerror(), which only accepts
> positive errno values.
>
LGTM.
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
> Signed-off-by: David Timber <dxdt@dev.snart.me>
> ---
> misc/filefrag.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/misc/filefrag.c b/misc/filefrag.c
> index 4641714c..d45288cd 100644
> --- a/misc/filefrag.c
> +++ b/misc/filefrag.c
> @@ -517,7 +517,7 @@ static int frag_report(const char *filename)
> filename);
> } else {
> fprintf(stderr, "%s: FIBMAP error: %s",
> - filename, strerror(expected));
> + filename, strerror(-expected));
> }
> rc = expected;
> goto out_close;
> --
> 2.53.0.1.ga224b40d3f.dirty
^ permalink raw reply
* [PATCH] crypto: tegra - Add missing CRYPTO_ALG_ASYNC
From: Eric Biggers @ 2026-03-14 16:55 UTC (permalink / raw)
To: Herbert Xu, linux-crypto
Cc: linux-ext4, linux-fscrypt, Thierry Reding, Jonathan Hunter,
Eric Biggers, Zorro Lang, stable, Akhil R
The tegra crypto driver failed to set the CRYPTO_ALG_ASYNC on its
asynchronous algorithms, causing the crypto API to select them for users
that request only synchronous algorithms. This causes crashes (at
least). Fix this by adding the flag like what the other drivers do.
Reported-by: Zorro Lang <zlang@redhat.com>
Closes: https://lore.kernel.org/r/20260314080937.pghb4aa7d4je3mhh@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com
Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver")
Cc: stable@vger.kernel.org
Cc: Akhil R <akhilrajeev@nvidia.com>
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---
This patch is targeting crypto/master
drivers/crypto/tegra/tegra-se-aes.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/tegra/tegra-se-aes.c b/drivers/crypto/tegra/tegra-se-aes.c
index 0e07d0523291a..cb97a59084519 100644
--- a/drivers/crypto/tegra/tegra-se-aes.c
+++ b/drivers/crypto/tegra/tegra-se-aes.c
@@ -592,10 +592,11 @@ static struct tegra_se_alg tegra_aes_algs[] = {
.ivsize = AES_BLOCK_SIZE,
.base = {
.cra_name = "xts(aes)",
.cra_driver_name = "xts-aes-tegra",
.cra_priority = 500,
+ .cra_flags = CRYPTO_ALG_ASYNC,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct tegra_aes_ctx),
.cra_alignmask = (__alignof__(u64) - 1),
.cra_module = THIS_MODULE,
},
@@ -1920,10 +1921,11 @@ static struct tegra_se_alg tegra_aead_algs[] = {
.ivsize = GCM_AES_IV_SIZE,
.base = {
.cra_name = "gcm(aes)",
.cra_driver_name = "gcm-aes-tegra",
.cra_priority = 500,
+ .cra_flags = CRYPTO_ALG_ASYNC,
.cra_blocksize = 1,
.cra_ctxsize = sizeof(struct tegra_aead_ctx),
.cra_alignmask = 0xf,
.cra_module = THIS_MODULE,
},
@@ -1942,10 +1944,11 @@ static struct tegra_se_alg tegra_aead_algs[] = {
.chunksize = AES_BLOCK_SIZE,
.base = {
.cra_name = "ccm(aes)",
.cra_driver_name = "ccm-aes-tegra",
.cra_priority = 500,
+ .cra_flags = CRYPTO_ALG_ASYNC,
.cra_blocksize = 1,
.cra_ctxsize = sizeof(struct tegra_aead_ctx),
.cra_alignmask = 0xf,
.cra_module = THIS_MODULE,
},
@@ -1969,11 +1972,11 @@ static struct tegra_se_alg tegra_cmac_algs[] = {
.halg.statesize = sizeof(struct tegra_cmac_reqctx),
.halg.base = {
.cra_name = "cmac(aes)",
.cra_driver_name = "tegra-se-cmac",
.cra_priority = 300,
- .cra_flags = CRYPTO_ALG_TYPE_AHASH,
+ .cra_flags = CRYPTO_ALG_TYPE_AHASH | CRYPTO_ALG_ASYNC,
.cra_blocksize = AES_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct tegra_cmac_ctx),
.cra_alignmask = 0,
.cra_module = THIS_MODULE,
.cra_init = tegra_cmac_cra_init,
base-commit: 1c9982b4961334c1edb0745a04cabd34bc2de675
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 2/9] fstests: add _mkfs_scratch_clone() helper
From: Zorro Lang @ 2026-03-14 17:04 UTC (permalink / raw)
To: Anand Jain; +Cc: Anand Jain, fstests, linux-btrfs, linux-ext4, linux-xfs
In-Reply-To: <43710dd2-4282-4475-a29d-983295fab86f@gmail.com>
On Wed, Mar 11, 2026 at 10:32:18AM +0800, Anand Jain wrote:
>
> > What about if ${#devs[@]} > 2 ?
>
> On purpose- so tests using _scratch_mkfs_sized_clone() don't
> pick a random higher number. If a test needs more than two
> devices, opens an opportunity to critically review this function.
> >> + fi
> >> +
> >> + case "$FSTYP" in
> >> + "btrfs")
> >> + _scratch_mkfs_sized $size
> >> + _scratch_mount
> >> + $BTRFS_UTIL_PROG subvolume create $SCRATCH_MNT/sv1
> >> + _scratch_unmount
> >> + ;;
> >> + "xfs"|"ext4")
> >> + _scratch_mkfs_sized $size
> >> + ;;
> >> + *)
> >> + _notrun "fstests clone op unsupported for FS $FSTYP"
> >> + ;;
> >> + esac
> >> +
> >> + # clone SCRATCH_DEV devs[0] to devs[1].
> >> + dd if=$SCRATCH_DEV of=${devs[1]} bs=$size status=none count=1 || \
> >> + _fail "Clone failed"
> >
> > I'm wondering if we absolutely need to use SCRATCH_DEV_POOL for this test. Could we clone SCRATCH_DEV
> > to an image file instead? Or would it be feasible to simply run the test using two image files?
>
> Using a config file and testing directly on block devices lets
> us cover a wider range of devices.
>
> When I wrote this test case, I was also considering whether a
> serial-number–based mount without extra mount option, would be
> better in the kernel.
>
> The downside is that xfs/ext4 testers now need to use
> SCRATCH_DEV_POOL. Let me know what you prefer.
I'm concerned that testers from other filesystems might not be familiar
with SCRATCH_DEV_POOL, as it's typically not a requirement for their
testing. I'm not sure if they would be willing to configure and switch
to SCRATCH_DEV_POOL, just for these few test cases. If we can avoid making
the pool to be a hard requirement, it might be more user-friendly for other
fs list. Welcome feedback and review points from other filesystem mailing
lists :)
Thanks,
Zorro
>
>
>
>
^ permalink raw reply
* Re: [Bug report][xfstests ext4/024 crash on ext4&fscrypt] kernel BUG at lib/list_debug.c:32!
From: Eric Biggers @ 2026-03-14 17:04 UTC (permalink / raw)
To: Zorro Lang; +Cc: linux-ext4, linux-fscrypt
In-Reply-To: <20260314080937.pghb4aa7d4je3mhh@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com>
On Sat, Mar 14, 2026 at 04:09:37PM +0800, Zorro Lang wrote:
> [ 859.430320] KASAN: probably user-memory-access in range [0x00000004e3534580-0x00000004e3534587]
> [ 859.439808] crypto_transfer_skcipher_request_to_engine+0x1c/0x38 [crypto_engine]
> [ 859.439816] tegra_aes_crypt+0x17c/0x308 [tegra_se]
> [ 859.443046] Mem abort info:
> [ 859.450307] tegra_aes_encrypt+0x1c/0x28 [tegra_se]
> [ 859.450316] crypto_skcipher_encrypt+0xe0/0x158
> [ 859.457490] ESR = 0x000000008600000f
> [ 859.464835] fscrypt_crypt_data_unit+0x21c/0x2d0
> [ 859.472193] EC = 0x21: IABT (current EL), IL = 32 bits
> [ 859.479359] fscrypt_encrypt_pagecache_blocks+0x1e8/0x350
> [ 859.479366] ext4_bio_write_folio+0x8e4/0x1128 [ext4]
Thanks. fscrypt isn't supposed to be using the tegra crypto driver.
But that driver is actually so broken that it doesn't even set its flags
correctly, causing the crypto_skcipher API to select it anyway.
https://lore.kernel.org/linux-fscrypt/20260314165515.9678-1-ebiggers@kernel.org/
fixes this by making the driver set the correct flags.
I'm looking forward to lib/crypto/ offering all the algorithms that
fscrypt needs so that we don't have to use crypto_skcipher.
- Eric
^ permalink raw reply
* Re: [PATCH v3 1/5] ext4: call deactivate_super() in extents_kunit_exit()
From: Ojaswin Mujoo @ 2026-03-15 5:39 UTC (permalink / raw)
To: Ye Bin; +Cc: tytso, adilger.kernel, linux-ext4, jack
In-Reply-To: <20260314074903.1314851-2-yebin@huaweicloud.com>
On Sat, Mar 14, 2026 at 03:48:59PM +0800, Ye Bin wrote:
> From: Ye Bin <yebin10@huawei.com>
>
> Call deactivate_super() is called in extents_kunit_exit() to cleanup
> the file system resource.
>
> Fixes: cb1e0c1d1fad ("ext4: kunit tests for extent splitting and conversion")
> Signed-off-by: Ye Bin <yebin10@huawei.com>
> ---
> fs/ext4/extents-test.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/ext4/extents-test.c b/fs/ext4/extents-test.c
> index 5496b2c8e2cd..e3d23e3cda87 100644
> --- a/fs/ext4/extents-test.c
> +++ b/fs/ext4/extents-test.c
> @@ -146,6 +146,7 @@ static void extents_kunit_exit(struct kunit *test)
> struct ext4_sb_info *sbi = sb->s_fs_info;
>
> ext4_es_unregister_shrinker(sbi);
> + deactivate_super(sbi->s_sb);
> kfree(sbi);
> kfree(k_ctx.k_ei);
> kfree(k_ctx.k_data);
> --
> 2.34.1
Hi,
We need to keep this patch after Patch 2 because else there is a
deadlock:
extents_kunit_init()
sget
down_write(s_umount)
extents_kunit_exit()
deactivate_super
down_write(s_umount)
Regards,
ojaswin
^ permalink raw reply
* Re: [PATCH v3 2/5] ext4: fix miss unlock 'sb->s_umount' in extents_kunit_init()
From: Ojaswin Mujoo @ 2026-03-15 5:40 UTC (permalink / raw)
To: Ye Bin; +Cc: tytso, adilger.kernel, linux-ext4, jack
In-Reply-To: <20260314074903.1314851-3-yebin@huaweicloud.com>
On Sat, Mar 14, 2026 at 03:49:00PM +0800, Ye Bin wrote:
> From: Ye Bin <yebin10@huawei.com>
>
> There's warning as follows when do ext4 kunit test:
> WARNING: kunit_try_catch/15923 still has locks held!
> 7.0.0-rc3-next-20260309-00028-g73f965a1bbb1-dirty #281 Tainted: G E N
> 1 lock held by kunit_try_catch/15923:
> #0: ffff888139f860e0 (&type->s_umount_key#70/1){+.+.}-{4:4}, at: alloc_super.constprop.0+0x172/0xa90
> Call Trace:
> <TASK>
> dump_stack_lvl+0x180/0x1b0
> debug_check_no_locks_held+0xc8/0xd0
> do_exit+0x1502/0x2b20
> kthread+0x3a9/0x540
> ret_from_fork+0xa76/0xdf0
> ret_from_fork_asm+0x1a/0x30
>
> As sget() will return 'sb' which holds 's->s_umount' lock. However,
> "extents-test" miss unlock this lock.
> So unlock 's->s_umount' in the end of extents_kunit_init().
>
> Fixes: cb1e0c1d1fad ("ext4: kunit tests for extent splitting and conversion")
> Signed-off-by: Ye Bin <yebin10@huawei.com>
> ---
> fs/ext4/extents-test.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/fs/ext4/extents-test.c b/fs/ext4/extents-test.c
> index e3d23e3cda87..3d4663d99eb1 100644
> --- a/fs/ext4/extents-test.c
> +++ b/fs/ext4/extents-test.c
> @@ -310,6 +310,8 @@ static int extents_kunit_init(struct kunit *test)
> kunit_activate_static_stub(test, ext4_ext_zeroout, ext4_ext_zeroout_stub);
> kunit_activate_static_stub(test, ext4_issue_zeroout,
> ext4_issue_zeroout_stub);
> + up_write(&sb->s_umount);
> +
Looks good, feel free to add:
Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Just make sure to put this before patch 1 (more info in review to patch
1)
Regards,
ojaswin
> return 0;
> }
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v3 3/5] ext4: fix the error handling process in extents_kunit_init).
From: Ojaswin Mujoo @ 2026-03-15 6:12 UTC (permalink / raw)
To: Ye Bin; +Cc: tytso, adilger.kernel, linux-ext4, jack
In-Reply-To: <20260314074903.1314851-4-yebin@huaweicloud.com>
On Sat, Mar 14, 2026 at 03:49:01PM +0800, Ye Bin wrote:
> 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>
Looks good,
Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Regards,
ojaswin
> ---
> fs/ext4/extents-test.c | 44 ++++++++++++++++++++++++++++++------------
> 1 file changed, 32 insertions(+), 12 deletions(-)
>
> diff --git a/fs/ext4/extents-test.c b/fs/ext4/extents-test.c
> index 3d4663d99eb1..543236a31e13 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;
>
> 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,20 @@ 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;
> +
> + if (sbi->s_es_shrinker)
> + ext4_es_unregister_shrinker(sbi);
> + deactivate_locked_super(sb);
> + kfree(sbi);
> +
> + return err;
> }
>
> /*
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v3 4/5] ext4: fix possible null-ptr-deref in extents_kunit_exit()
From: Ojaswin Mujoo @ 2026-03-15 6:13 UTC (permalink / raw)
To: Ye Bin; +Cc: tytso, adilger.kernel, linux-ext4, jack
In-Reply-To: <20260314074903.1314851-5-yebin@huaweicloud.com>
On Sat, Mar 14, 2026 at 03:49:02PM +0800, Ye Bin wrote:
> From: Ye Bin <yebin10@huawei.com>
>
> There's issue as follows:
> KASAN: null-ptr-deref in range [0x00000000000002c0-0x00000000000002c7]
> Tainted: [E]=UNSIGNED_MODULE, [N]=TEST
> RIP: 0010:extents_kunit_exit+0x2e/0xc0 [ext4_test]
> Call Trace:
> <TASK>
> kunit_try_run_case_cleanup+0xbc/0x100 [kunit]
> kunit_generic_run_threadfn_adapter+0x89/0x100 [kunit]
> kthread+0x408/0x540
> ret_from_fork+0xa76/0xdf0
> ret_from_fork_asm+0x1a/0x30
>
> Above issue happens as extents_kunit_init() init testcase failed.
> So test if testcase is inited success.
>
> Fixes: cb1e0c1d1fad ("ext4: kunit tests for extent splitting and conversion")
> Signed-off-by: Ye Bin <yebin10@huawei.com>
> ---
> fs/ext4/extents-test.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ext4/extents-test.c b/fs/ext4/extents-test.c
> index 543236a31e13..6ae72986ca9c 100644
> --- a/fs/ext4/extents-test.c
> +++ b/fs/ext4/extents-test.c
> @@ -142,9 +142,12 @@ static struct file_system_type ext_fs_type = {
>
> static void extents_kunit_exit(struct kunit *test)
> {
> - struct super_block *sb = k_ctx.k_ei->vfs_inode.i_sb;
> - struct ext4_sb_info *sbi = sb->s_fs_info;
> + struct ext4_sb_info *sbi;
>
> + if (!k_ctx.k_ei)
> + return;
> +
> + sbi = k_ctx.k_ei->vfs_inode.i_sb->s_fs_info;
> ext4_es_unregister_shrinker(sbi);
> deactivate_super(sbi->s_sb);
> kfree(sbi);
Looks good, feel free to add:
Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Regards,
ojaswin
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v3 5/5] ext4: fix possible null-ptr-deref in mbt_kunit_exit()
From: Ojaswin Mujoo @ 2026-03-15 6:23 UTC (permalink / raw)
To: Ye Bin; +Cc: tytso, adilger.kernel, linux-ext4, jack
In-Reply-To: <20260314074903.1314851-6-yebin@huaweicloud.com>
On Sat, Mar 14, 2026 at 03:49:03PM +0800, Ye Bin wrote:
> From: Ye Bin <yebin10@huawei.com>
>
> There's issue as follows:
> # test_new_blocks_simple: failed to initialize: -12
> KASAN: null-ptr-deref in range [0x0000000000000638-0x000000000000063f]
> Tainted: [E]=UNSIGNED_MODULE, [N]=TEST
> RIP: 0010:mbt_kunit_exit+0x5e/0x3e0 [ext4_test]
> Call Trace:
> <TASK>
> kunit_try_run_case_cleanup+0xbc/0x100 [kunit]
> kunit_generic_run_threadfn_adapter+0x89/0x100 [kunit]
> kthread+0x408/0x540
> ret_from_fork+0xa76/0xdf0
> ret_from_fork_asm+0x1a/0x30
>
> If mbt_kunit_init() init testcase failed will lead to null-ptr-deref.
> So add test if 'sb' is inited success in mbt_kunit_exit().
>
> Fixes: 7c9fa399a369 ("ext4: add first unit test for ext4_mb_new_blocks_simple in mballoc")
> Signed-off-by: Ye Bin <yebin10@huawei.com>
Hi Ye, looks good.
Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Regards,
ojaswin
> ---
> fs/ext4/mballoc-test.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ext4/mballoc-test.c b/fs/ext4/mballoc-test.c
> index c75b91ae0cf0..90ed505fa4b1 100644
> --- a/fs/ext4/mballoc-test.c
> +++ b/fs/ext4/mballoc-test.c
> @@ -362,7 +362,6 @@ static int mbt_kunit_init(struct kunit *test)
> return ret;
> }
>
> - test->priv = sb;
> kunit_activate_static_stub(test,
> ext4_read_block_bitmap_nowait,
> ext4_read_block_bitmap_nowait_stub);
> @@ -383,6 +382,8 @@ static int mbt_kunit_init(struct kunit *test)
> return -ENOMEM;
> }
>
> + test->priv = sb;
> +
> return 0;
> }
>
> @@ -390,6 +391,9 @@ static void mbt_kunit_exit(struct kunit *test)
> {
> struct super_block *sb = (struct super_block *)test->priv;
>
> + if (!sb)
> + return;
> +
> mbt_mb_release(sb);
> mbt_ctx_release(sb);
> mbt_ext4_free_super_block(sb);
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 0/3] decoupling the ext4 test module
From: Ojaswin Mujoo @ 2026-03-15 6:44 UTC (permalink / raw)
To: Ye Bin; +Cc: tytso, adilger.kernel, linux-ext4, jack
In-Reply-To: <20260314075258.1317579-1-yebin@huaweicloud.com>
On Sat, Mar 14, 2026 at 03:52:55PM +0800, Ye Bin wrote:
> From: Ye Bin <yebin10@huawei.com>
>
> This patchset is split out from the "Fix some issues about ext4-test"
> patchset. It decouples mballoc-test.c and extents-test.c from the
> ext4 module, resolving the issue where these two tests could not be run
> when EXT4_KUNIT_TESTS is set to M.
>
> Ye Bin (3):
> ext4: introduce EXPORT_SYMBOL_FOR_EXT4_TEST() helper
> ext4: fix mballoc-test.c is not compiled when EXT4_KUNIT_TESTS=M
> ext4: fix extents-test.c is not compiled when EXT4_KUNIT_TESTS=M
Hi Ye,
So thinking about this a bit more, is there any reason we are not using
the VISIBLE_IF_KUNIT and EXPORT_SYMBOL_IF_KUNIT macros directly? Is
there any case that they don't handle?
[1] https://docs.kernel.org/dev-tools/kunit/usage.html#testing-static-functions
>
> fs/ext4/Makefile | 5 +-
> fs/ext4/ext4.h | 5 ++
> fs/ext4/ext4_extents.h | 12 +++++
> fs/ext4/extents-test.c | 8 ++--
> fs/ext4/extents.c | 39 +++++++++++++---
> fs/ext4/mballoc-test.c | 81 ++++++++++++++++----------------
> fs/ext4/mballoc.c | 102 +++++++++++++++++++++++++++++++++++++++--
> fs/ext4/mballoc.h | 30 ++++++++++++
> 8 files changed, 227 insertions(+), 55 deletions(-)
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH 16/53] ovl: drop dir lock for lookups in impure readdir
From: Amir Goldstein @ 2026-03-15 13:51 UTC (permalink / raw)
To: NeilBrown
Cc: Linus Torvalds, Alexander Viro, Christian Brauner, Jan Kara,
Jeff Layton, Trond Myklebust, Anna Schumaker, Carlos Maiolino,
Miklos Szeredi, Jan Harkes, Hugh Dickins, Baolin Wang,
David Howells, Marc Dionne, Steve French, Namjae Jeon,
Sungjong Seo, Yuezhang Mo, Andreas Hindborg, Breno Leitao,
Theodore Ts'o, Andreas Dilger, Steven Rostedt,
Masami Hiramatsu, Ilya Dryomov, Alex Markuze, Viacheslav Dubeyko,
Tyler Hicks, Andreas Gruenbacher, Richard Weinberger,
Anton Ivanov, Johannes Berg, Jeremy Kerr, Ard Biesheuvel,
linux-fsdevel, linux-nfs, linux-xfs, linux-unionfs, coda,
linux-mm, linux-afs, linux-cifs, linux-ext4, linux-kernel,
linux-trace-kernel, ceph-devel, ecryptfs, gfs2, linux-um,
linux-efi
In-Reply-To: <20260312214330.3885211-17-neilb@ownmail.net>
On Thu, Mar 12, 2026 at 10:49 PM NeilBrown <neilb@ownmail.net> wrote:
>
> From: NeilBrown <neil@brown.name>
>
> When performing an "impure" readdir, ovl needs to perform a lookup on some
> of the names that it found.
> With proposed locking changes it will not be possible to perform this
> lookup (in particular, not safe to wait for d_alloc_parallel()) while
> holding a lock on the directory.
>
> ovl doesn't really need the lock at this point.
Not exactly. see below.
> It has already iterated
> the directory and has cached a list of the contents. It now needs to
> gather extra information about some contents. It can do this without
> the lock.
>
> After gathering that info it needs to retake the lock for API
> correctness. After doing this it must check IS_DEADDIR() again to
> ensure readdir always returns -ENOENT on a removed directory.
>
> Note that while ->iterate_shared is called with a shared lock, ovl uses
> WRAP_DIR_ITER() so an exclusive lock is held and so we drop and retake
> that exclusive lock.
>
> As the directory is no longer locked in ovl_cache_update() we need
> dget_parent() to get a reference to the parent.
>
> Signed-off-by: NeilBrown <neil@brown.name>
> ---
> fs/overlayfs/readdir.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/fs/overlayfs/readdir.c b/fs/overlayfs/readdir.c
> index 1dcc75b3a90f..d5123b37921c 100644
> --- a/fs/overlayfs/readdir.c
> +++ b/fs/overlayfs/readdir.c
> @@ -568,13 +568,12 @@ static int ovl_cache_update(const struct path *path, struct ovl_cache_entry *p,
> goto get;
> }
> if (p->len == 2) {
> - /* we shall not be moved */
> - this = dget(dir->d_parent);
> + this = dget_parent(dir);
> goto get;
> }
> }
> /* This checks also for xwhiteouts */
> - this = lookup_one(mnt_idmap(path->mnt), &QSTR_LEN(p->name, p->len), dir);
> + this = lookup_one_unlocked(mnt_idmap(path->mnt), &QSTR_LEN(p->name, p->len), dir);
ovl_cache_update() is also called from ovl_iterate_merged() where inode
is locked.
> if (IS_ERR_OR_NULL(this) || !this->d_inode) {
> /* Mark a stale entry */
> p->is_whiteout = true;
> @@ -666,11 +665,12 @@ static int ovl_dir_read_impure(const struct path *path, struct list_head *list,
> if (err)
> return err;
>
> + inode_unlock(path->dentry->d_inode);
> list_for_each_entry_safe(p, n, list, l_node) {
> if (!name_is_dot_dotdot(p->name, p->len)) {
> err = ovl_cache_update(path, p, true);
> if (err)
> - return err;
> + break;
> }
> if (p->ino == p->real_ino) {
> list_del(&p->l_node);
> @@ -680,14 +680,19 @@ static int ovl_dir_read_impure(const struct path *path, struct list_head *list,
> struct rb_node *parent = NULL;
>
> if (WARN_ON(ovl_cache_entry_find_link(p->name, p->len,
> - &newp, &parent)))
> - return -EIO;
> + &newp, &parent))) {
> + err = -EIO;
> + break;
> + }
>
> rb_link_node(&p->node, parent, newp);
> rb_insert_color(&p->node, root);
> }
> }
> - return 0;
> + inode_lock(path->dentry->d_inode);
> + if (IS_DEADDIR(path->dentry->d_inode))
> + err = -ENOENT;
> + return err;
> }
>
> static struct ovl_dir_cache *ovl_cache_get_impure(const struct path *path)
> --
You missed the fact that overlayfs uses the dir inode lock
to protect the readdir inode cache, so your patch introduces
a risk for storing a stale readdir cache when dir modify operations
invalidate the readdir cache version while lock is dropped
and also introduces memory leak when cache is stomped
without freeing cache created by a competing thread.
I think something like the untested patch below should fix this.
I did not look into ovl_iterate_merged() to see if it has a simple
fix and I am not 100% sure that this fix for impure dir is enough.
Thanks,
Amir.
diff --git a/fs/overlayfs/readdir.c b/fs/overlayfs/readdir.c
index d5123b37921c8..9e90064b252ce 100644
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -702,15 +702,13 @@ static struct ovl_dir_cache
*ovl_cache_get_impure(const struct path *path)
struct inode *inode = d_inode(dentry);
struct ovl_fs *ofs = OVL_FS(dentry->d_sb);
struct ovl_dir_cache *cache;
+ /* Snapshot version before ovl_dir_read_impure() drops i_rwsem */
+ u64 version = ovl_inode_version_get(inode);
cache = ovl_dir_cache(inode);
- if (cache && ovl_inode_version_get(inode) == cache->version)
+ if (cache && version == cache->version)
return cache;
- /* Impure cache is not refcounted, free it here */
- ovl_dir_cache_free(inode);
- ovl_set_dir_cache(inode, NULL);
-
cache = kzalloc_obj(struct ovl_dir_cache);
if (!cache)
return ERR_PTR(-ENOMEM);
@@ -721,6 +719,14 @@ static struct ovl_dir_cache
*ovl_cache_get_impure(const struct path *path)
kfree(cache);
return ERR_PTR(res);
}
+
+ /*
+ * Impure cache is not refcounted, free it here.
+ * Also frees cache stored by concurrent readdir during i_rwsem drop.
+ */
+ ovl_dir_cache_free(inode);
+ ovl_set_dir_cache(inode, NULL);
+
if (list_empty(&cache->entries)) {
/*
* A good opportunity to get rid of an unneeded "impure" flag.
@@ -736,7 +742,7 @@ static struct ovl_dir_cache
*ovl_cache_get_impure(const struct path *path)
return NULL;
}
- cache->version = ovl_inode_version_get(inode);
+ cache->version = version;
ovl_set_dir_cache(inode, cache);
return cache;
^ permalink raw reply related
* Re: [PATCH] crypto: tegra - Add missing CRYPTO_ALG_ASYNC
From: Zorro Lang @ 2026-03-15 15:55 UTC (permalink / raw)
To: Eric Biggers
Cc: Herbert Xu, linux-crypto, linux-ext4, linux-fscrypt,
Thierry Reding, Jonathan Hunter, stable, Akhil R
In-Reply-To: <20260314165515.9678-1-ebiggers@kernel.org>
On Sat, Mar 14, 2026 at 09:55:15AM -0700, Eric Biggers wrote:
> The tegra crypto driver failed to set the CRYPTO_ALG_ASYNC on its
> asynchronous algorithms, causing the crypto API to select them for users
> that request only synchronous algorithms. This causes crashes (at
> least). Fix this by adding the flag like what the other drivers do.
>
> Reported-by: Zorro Lang <zlang@redhat.com>
> Closes: https://lore.kernel.org/r/20260314080937.pghb4aa7d4je3mhh@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com
> Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver")
> Cc: stable@vger.kernel.org
> Cc: Akhil R <akhilrajeev@nvidia.com>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
Thanks for you quick response, Eric. This fix works on my side. With this patch,
same reproducer can't trigger that bug anymore.
Thanks,
Zorro
>
> This patch is targeting crypto/master
>
> drivers/crypto/tegra/tegra-se-aes.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/tegra/tegra-se-aes.c b/drivers/crypto/tegra/tegra-se-aes.c
> index 0e07d0523291a..cb97a59084519 100644
> --- a/drivers/crypto/tegra/tegra-se-aes.c
> +++ b/drivers/crypto/tegra/tegra-se-aes.c
> @@ -592,10 +592,11 @@ static struct tegra_se_alg tegra_aes_algs[] = {
> .ivsize = AES_BLOCK_SIZE,
> .base = {
> .cra_name = "xts(aes)",
> .cra_driver_name = "xts-aes-tegra",
> .cra_priority = 500,
> + .cra_flags = CRYPTO_ALG_ASYNC,
> .cra_blocksize = AES_BLOCK_SIZE,
> .cra_ctxsize = sizeof(struct tegra_aes_ctx),
> .cra_alignmask = (__alignof__(u64) - 1),
> .cra_module = THIS_MODULE,
> },
> @@ -1920,10 +1921,11 @@ static struct tegra_se_alg tegra_aead_algs[] = {
> .ivsize = GCM_AES_IV_SIZE,
> .base = {
> .cra_name = "gcm(aes)",
> .cra_driver_name = "gcm-aes-tegra",
> .cra_priority = 500,
> + .cra_flags = CRYPTO_ALG_ASYNC,
> .cra_blocksize = 1,
> .cra_ctxsize = sizeof(struct tegra_aead_ctx),
> .cra_alignmask = 0xf,
> .cra_module = THIS_MODULE,
> },
> @@ -1942,10 +1944,11 @@ static struct tegra_se_alg tegra_aead_algs[] = {
> .chunksize = AES_BLOCK_SIZE,
> .base = {
> .cra_name = "ccm(aes)",
> .cra_driver_name = "ccm-aes-tegra",
> .cra_priority = 500,
> + .cra_flags = CRYPTO_ALG_ASYNC,
> .cra_blocksize = 1,
> .cra_ctxsize = sizeof(struct tegra_aead_ctx),
> .cra_alignmask = 0xf,
> .cra_module = THIS_MODULE,
> },
> @@ -1969,11 +1972,11 @@ static struct tegra_se_alg tegra_cmac_algs[] = {
> .halg.statesize = sizeof(struct tegra_cmac_reqctx),
> .halg.base = {
> .cra_name = "cmac(aes)",
> .cra_driver_name = "tegra-se-cmac",
> .cra_priority = 300,
> - .cra_flags = CRYPTO_ALG_TYPE_AHASH,
> + .cra_flags = CRYPTO_ALG_TYPE_AHASH | CRYPTO_ALG_ASYNC,
> .cra_blocksize = AES_BLOCK_SIZE,
> .cra_ctxsize = sizeof(struct tegra_cmac_ctx),
> .cra_alignmask = 0,
> .cra_module = THIS_MODULE,
> .cra_init = tegra_cmac_cra_init,
>
> base-commit: 1c9982b4961334c1edb0745a04cabd34bc2de675
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v3 3/5] ext4: fix the error handling process in extents_kunit_init).
From: yebin (H) @ 2026-03-16 1:36 UTC (permalink / raw)
To: Ritesh Harjani (IBM), Ye Bin, tytso, adilger.kernel, linux-ext4; +Cc: jack
In-Reply-To: <h5qitwzt.ritesh.list@gmail.com>
On 2026/3/14 20:29, Ritesh Harjani (IBM) wrote:
> 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
>>
>
> Minor nit.
>
>> Fixes: cb1e0c1d1fad ("ext4: kunit tests for extent splitting and conversion")
>> Signed-off-by: Ye Bin <yebin10@huawei.com>
>> ---
>> fs/ext4/extents-test.c | 44 ++++++++++++++++++++++++++++++------------
>> 1 file changed, 32 insertions(+), 12 deletions(-)
>>
>> diff --git a/fs/ext4/extents-test.c b/fs/ext4/extents-test.c
>> index 3d4663d99eb1..543236a31e13 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;
>>
>> 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,20 @@ 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;
>> +
>> + if (sbi->s_es_shrinker)
>> + ext4_es_unregister_shrinker(sbi);
>
> I don't think this extra check is necessary.
> ext4_es_unregister_shrinker() already has checks in place.
>
I was mainly thinking about what abnormal behavior might be caused if
percpu_counter_destroy() is called before percpu_counter_init() is called.
> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>
>> + deactivate_locked_super(sb);
>> + kfree(sbi);
>> +
>> + return err;
>> }
>>
>> /*
>> --
>> 2.34.1
>
> .
>
^ permalink raw reply
* Re: [PATCH v2 0/3] decoupling the ext4 test module
From: yebin (H) @ 2026-03-16 1:41 UTC (permalink / raw)
To: Ojaswin Mujoo, Ye Bin; +Cc: tytso, adilger.kernel, linux-ext4, jack
In-Reply-To: <abZVUmszFisfOdmz@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>
On 2026/3/15 14:44, Ojaswin Mujoo wrote:
> On Sat, Mar 14, 2026 at 03:52:55PM +0800, Ye Bin wrote:
>> From: Ye Bin <yebin10@huawei.com>
>>
>> This patchset is split out from the "Fix some issues about ext4-test"
>> patchset. It decouples mballoc-test.c and extents-test.c from the
>> ext4 module, resolving the issue where these two tests could not be run
>> when EXT4_KUNIT_TESTS is set to M.
>>
>> Ye Bin (3):
>> ext4: introduce EXPORT_SYMBOL_FOR_EXT4_TEST() helper
>> ext4: fix mballoc-test.c is not compiled when EXT4_KUNIT_TESTS=M
>> ext4: fix extents-test.c is not compiled when EXT4_KUNIT_TESTS=M
>
> Hi Ye,
>
> So thinking about this a bit more, is there any reason we are not using
> the VISIBLE_IF_KUNIT and EXPORT_SYMBOL_IF_KUNIT macros directly? Is
> there any case that they don't handle?
>
A limitation of directly using the VISIBLE_IF_KUNIT and
EXPORT_SYMBOL_IF_KUNIT macros is that they rely entirely on the
CONFIG_KUNIT configuration being enabled. However, enabling
CONFIG_KUNIT does not necessarily mean that EXT4_KUNIT_TESTS is
enabled. If EXT4_KUNIT_TESTS is not enabled, there is no need to export
the symbols.
> [1] https://docs.kernel.org/dev-tools/kunit/usage.html#testing-static-functions
>>
>> fs/ext4/Makefile | 5 +-
>> fs/ext4/ext4.h | 5 ++
>> fs/ext4/ext4_extents.h | 12 +++++
>> fs/ext4/extents-test.c | 8 ++--
>> fs/ext4/extents.c | 39 +++++++++++++---
>> fs/ext4/mballoc-test.c | 81 ++++++++++++++++----------------
>> fs/ext4/mballoc.c | 102 +++++++++++++++++++++++++++++++++++++++--
>> fs/ext4/mballoc.h | 30 ++++++++++++
>> 8 files changed, 227 insertions(+), 55 deletions(-)
>>
>> --
>> 2.34.1
>>
>
>
> .
>
^ permalink raw reply
* Re: [PATCH] crypto: tegra - Add missing CRYPTO_ALG_ASYNC
From: Akhil R @ 2026-03-16 5:00 UTC (permalink / raw)
To: ebiggers
Cc: akhilrajeev, herbert, jonathanh, linux-crypto, linux-ext4,
linux-fscrypt, stable, thierry.reding, zlang
In-Reply-To: <20260314165515.9678-1-ebiggers@kernel.org>
On Sat, 14 Mar 2026 09:55:15 -0700, Eric Biggers wrote:
> The tegra crypto driver failed to set the CRYPTO_ALG_ASYNC on its
> asynchronous algorithms, causing the crypto API to select them for users
> that request only synchronous algorithms. This causes crashes (at
> least). Fix this by adding the flag like what the other drivers do.
>
> Reported-by: Zorro Lang <zlang@redhat.com>
> Closes: https://lore.kernel.org/r/20260314080937.pghb4aa7d4je3mhh@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com
> Fixes: 0880bb3b00c8 ("crypto: tegra - Add Tegra Security Engine driver")
> Cc: stable@vger.kernel.org
> Cc: Akhil R <akhilrajeev@nvidia.com>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
Thanks for the fix. Looks like CRYPTO_ALG_ASYNC is missing for the hash
algorithms in tegra-se-hash.c as well. Would you want to include those
in this patch? I can push a separate patch if you suggest.
Acked-by: Akhil R <akhilrajeev@nvidia.com>
>
> This patch is targeting crypto/master
>
> drivers/crypto/tegra/tegra-se-aes.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/tegra/tegra-se-aes.c b/drivers/crypto/tegra/tegra-se-aes.c
> index 0e07d0523291a..cb97a59084519 100644
> --- a/drivers/crypto/tegra/tegra-se-aes.c
> +++ b/drivers/crypto/tegra/tegra-se-aes.c
> @@ -592,10 +592,11 @@ static struct tegra_se_alg tegra_aes_algs[] = {
> .ivsize = AES_BLOCK_SIZE,
> .base = {
> .cra_name = "xts(aes)",
> .cra_driver_name = "xts-aes-tegra",
> .cra_priority = 500,
> + .cra_flags = CRYPTO_ALG_ASYNC,
> .cra_blocksize = AES_BLOCK_SIZE,
> .cra_ctxsize = sizeof(struct tegra_aes_ctx),
> .cra_alignmask = (__alignof__(u64) - 1),
> .cra_module = THIS_MODULE,
> },
> @@ -1920,10 +1921,11 @@ static struct tegra_se_alg tegra_aead_algs[] = {
> .ivsize = GCM_AES_IV_SIZE,
> .base = {
> .cra_name = "gcm(aes)",
> .cra_driver_name = "gcm-aes-tegra",
> .cra_priority = 500,
> + .cra_flags = CRYPTO_ALG_ASYNC,
> .cra_blocksize = 1,
> .cra_ctxsize = sizeof(struct tegra_aead_ctx),
> .cra_alignmask = 0xf,
> .cra_module = THIS_MODULE,
> },
> @@ -1942,10 +1944,11 @@ static struct tegra_se_alg tegra_aead_algs[] = {
> .chunksize = AES_BLOCK_SIZE,
> .base = {
> .cra_name = "ccm(aes)",
> .cra_driver_name = "ccm-aes-tegra",
> .cra_priority = 500,
> + .cra_flags = CRYPTO_ALG_ASYNC,
> .cra_blocksize = 1,
> .cra_ctxsize = sizeof(struct tegra_aead_ctx),
> .cra_alignmask = 0xf,
> .cra_module = THIS_MODULE,
> },
> @@ -1969,11 +1972,11 @@ static struct tegra_se_alg tegra_cmac_algs[] = {
> .halg.statesize = sizeof(struct tegra_cmac_reqctx),
> .halg.base = {
> .cra_name = "cmac(aes)",
> .cra_driver_name = "tegra-se-cmac",
> .cra_priority = 300,
> - .cra_flags = CRYPTO_ALG_TYPE_AHASH,
> + .cra_flags = CRYPTO_ALG_TYPE_AHASH | CRYPTO_ALG_ASYNC,
> .cra_blocksize = AES_BLOCK_SIZE,
> .cra_ctxsize = sizeof(struct tegra_cmac_ctx),
> .cra_alignmask = 0,
> .cra_module = THIS_MODULE,
> .cra_init = tegra_cmac_cra_init,
>
> base-commit: 1c9982b4961334c1edb0745a04cabd34bc2de675
Best Regards,
Akhil
^ permalink raw reply
* [PATCH] ext4: Fix possible NULL pointer dereference in ext4_group_desc_free()
From: Zqiang @ 2026-03-16 8:20 UTC (permalink / raw)
To: tytso, adilger.kernel; +Cc: linux-ext4, linux-kernel, qiang.zhang
This can happen if the kvmalloc_objs() fails and sbi->s_group_desc pointer
is NULL in the ext4_group_desc_init(), and then the ext4_group_desc_free()
is called, leading to a NULL group_desc pointer dereference.
This commit therefore adds a NULL check for sbi->s_group_desc before
accessing its internal members.
Signed-off-by: Zqiang <qiang.zhang@linux.dev>
---
fs/ext4/super.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 43f680c750ae..c4307dc04687 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1256,9 +1256,11 @@ static void ext4_group_desc_free(struct ext4_sb_info *sbi)
rcu_read_lock();
group_desc = rcu_dereference(sbi->s_group_desc);
- for (i = 0; i < sbi->s_gdb_count; i++)
- brelse(group_desc[i]);
- kvfree(group_desc);
+ if (group_desc) {
+ for (i = 0; i < sbi->s_gdb_count; i++)
+ brelse(group_desc[i]);
+ kvfree(group_desc);
+ }
rcu_read_unlock();
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 50/61] iommu: Prefer IS_ERR_OR_NULL over manual NULL check
From: Robin Murphy @ 2026-03-16 13:30 UTC (permalink / raw)
To: Philipp Hahn, amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel,
dri-devel, gfs2, intel-gfx, intel-wired-lan, iommu, kvm,
linux-arm-kernel, linux-block, linux-bluetooth, linux-btrfs,
linux-cifs, linux-clk, linux-erofs, linux-ext4, linux-fsdevel,
linux-gpio, linux-hyperv, linux-input, linux-kernel, linux-leds,
linux-media, linux-mips, linux-mm, linux-modules, linux-mtd,
linux-nfs, linux-omap, linux-phy, linux-pm, linux-rockchip,
linux-s390, linux-scsi, linux-sctp, linux-security-module,
linux-sh, linux-sound, linux-stm32, linux-trace-kernel, linux-usb,
linux-wireless, netdev, ntfs3, samba-technical, sched-ext,
target-devel, tipc-discussion, v9fs
Cc: Joerg Roedel, Will Deacon
In-Reply-To: <20260310-b4-is_err_or_null-v1-50-bd63b656022d@avm.de>
On 2026-03-10 11:49 am, Philipp Hahn wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
AFAICS it doesn't look possible for the argument to be anything other
than valid at both callsites, so *both* conditions here seem in fact to
be entirely redundant.
> Change generated with coccinelle.
Please use coccinelle responsibly. Mechanical changes are great for
scripted API updates, but for cleanup, whilst it's ideal for *finding*
areas of code that are worth looking at, the code then wants actually
looking at, in its whole context, because meaningful cleanup often goes
deeper than trivial replacement.
In particular, anywhere IS_ERR_OR_NULL() is genuinely relevant is
usually a sign of bad interface design, so if you're looking at this
then you really should be looking first and foremost to remove any
checks that are already unnecessary, and for the remainder, to see if
the thing being checked can be improved to not mix the two different
styles. That would be constructive and (usually) welcome cleanup. Simply
churning a bunch of code with this ugly macro that's arguably less
readable than what it replaces, not so much.
Thanks,
Robin.
> To: Joerg Roedel <joro@8bytes.org>
> To: Will Deacon <will@kernel.org>
> To: Robin Murphy <robin.murphy@arm.com>
> Cc: iommu@lists.linux.dev
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
> ---
> drivers/iommu/omap-iommu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
> index 8231d7d6bb6a9202025643639a6b28e6faa84659..500a42b57a997696ff37c76f028a717ab71d01f9 100644
> --- a/drivers/iommu/omap-iommu.c
> +++ b/drivers/iommu/omap-iommu.c
> @@ -881,7 +881,7 @@ static int omap_iommu_attach(struct omap_iommu *obj, u32 *iopgd)
> **/
> static void omap_iommu_detach(struct omap_iommu *obj)
> {
> - if (!obj || IS_ERR(obj))
> + if (IS_ERR_OR_NULL(obj))
> return;
>
> spin_lock(&obj->iommu_lock);
>
^ permalink raw reply
* Re: [PATCH] ext4: Fix possible NULL pointer dereference in ext4_group_desc_free()
From: Baokun Li @ 2026-03-16 15:49 UTC (permalink / raw)
To: Zqiang; +Cc: linux-ext4, linux-kernel, tytso, adilger.kernel, libaokun
In-Reply-To: <20260316082025.9574-1-qiang.zhang@linux.dev>
On 3/16/26 4:20 PM, Zqiang wrote:
> This can happen if the kvmalloc_objs() fails and sbi->s_group_desc pointer
> is NULL in the ext4_group_desc_init(), and then the ext4_group_desc_free()
> is called, leading to a NULL group_desc pointer dereference.
>
> This commit therefore adds a NULL check for sbi->s_group_desc before
> accessing its internal members.
>
> Signed-off-by: Zqiang <qiang.zhang@linux.dev>
> ---
> fs/ext4/super.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 43f680c750ae..c4307dc04687 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -1256,9 +1256,11 @@ static void ext4_group_desc_free(struct ext4_sb_info *sbi)
>
> rcu_read_lock();
> group_desc = rcu_dereference(sbi->s_group_desc);
> - for (i = 0; i < sbi->s_gdb_count; i++)
In ext4_group_desc_init(), s_gdb_count is only assigned after kvmalloc_array
allocation succeeds. Therefore, when kvmalloc_array fails, the
brelse(group_desc[i]) in ext4_group_desc_free() will not actually be
executed,
and thus this NULL pointer dereference issue will not be triggered.
Cheers,
Baokun
> - brelse(group_desc[i]);
> - kvfree(group_desc);
> + if (group_desc) {
> + for (i = 0; i < sbi->s_gdb_count; i++)
> + brelse(group_desc[i]);
> + kvfree(group_desc);
> + }
> rcu_read_unlock();
> }
>
^ permalink raw reply
* Re: [PATCH 2/9] fstests: add _mkfs_scratch_clone() helper
From: Christoph Hellwig @ 2026-03-16 16:15 UTC (permalink / raw)
To: Zorro Lang
Cc: Anand Jain, Anand Jain, fstests, linux-btrfs, linux-ext4,
linux-xfs
In-Reply-To: <20260314170422.a62qqwqe6agom443@dell-per750-06-vm-08.rhts.eng.pek2.redhat.com>
On Sun, Mar 15, 2026 at 01:04:22AM +0800, Zorro Lang wrote:
> I'm concerned that testers from other filesystems might not be familiar
> with SCRATCH_DEV_POOL, as it's typically not a requirement for their
> testing. I'm not sure if they would be willing to configure and switch
> to SCRATCH_DEV_POOL, just for these few test cases. If we can avoid making
> the pool to be a hard requirement, it might be more user-friendly for other
> fs list. Welcome feedback and review points from other filesystem mailing
> lists :)
Yes, doing this using loop devices or ramdisk is going to get us much
better coverage.
^ permalink raw reply
* Re: [PATCH] jbd2: gracefully abort on checkpointing state corruptions
From: Jan Kara @ 2026-03-16 17:34 UTC (permalink / raw)
To: Milos Nikic; +Cc: jack, tytso, linux-ext4, linux-kernel
In-Reply-To: <20260309230838.422074-1-nikic.milos@gmail.com>
On Mon 09-03-26 16:08:38, Milos Nikic wrote:
> This patch targets two internal state machine invariants in checkpoint.c
> residing inside functions that natively return integer error codes.
>
> - In jbd2_cleanup_journal_tail(): A blocknr of 0 indicates a severely
> corrupted journal superblock. Replaced the J_ASSERT with a WARN_ON_ONCE
> and a graceful journal abort, returning -EUCLEAN.
>
> - In jbd2_log_do_checkpoint(): Replaced the J_ASSERT_BH checking for
> an unexpected buffer_jwrite state. If the warning triggers, we
> explicitly drop the just-taken get_bh() reference and call __flush_batch()
> to safely clean up any previously queued buffers in the j_chkpt_bhs array,
> preventing a memory leak before returning -EUCLEAN.
>
> Signed-off-by: Milos Nikic <nikic.milos@gmail.com>
Looks good. Feel free to add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> fs/jbd2/checkpoint.c | 17 +++++++++++++++--
> 1 file changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c
> index de89c5bef607..cdfbfd27afae 100644
> --- a/fs/jbd2/checkpoint.c
> +++ b/fs/jbd2/checkpoint.c
> @@ -267,7 +267,17 @@ int jbd2_log_do_checkpoint(journal_t *journal)
> */
> BUFFER_TRACE(bh, "queue");
> get_bh(bh);
> - J_ASSERT_BH(bh, !buffer_jwrite(bh));
> + if (WARN_ON_ONCE(buffer_jwrite(bh))) {
> + put_bh(bh); /* drop the ref we just took */
> + spin_unlock(&journal->j_list_lock);
> + jbd2_journal_abort(journal, -EUCLEAN);
> +
> + /* Clean up any previously batched buffers */
> + if (batch_count)
> + __flush_batch(journal, &batch_count);
> +
> + return -EUCLEAN;
> + }
> journal->j_chkpt_bhs[batch_count++] = bh;
> transaction->t_chp_stats.cs_written++;
> transaction->t_checkpoint_list = jh->b_cpnext;
> @@ -325,7 +335,10 @@ int jbd2_cleanup_journal_tail(journal_t *journal)
>
> if (!jbd2_journal_get_log_tail(journal, &first_tid, &blocknr))
> return 1;
> - J_ASSERT(blocknr != 0);
> + if (WARN_ON_ONCE(blocknr == 0)) {
> + jbd2_journal_abort(journal, -EUCLEAN);
> + return -EUCLEAN;
> + }
>
> /*
> * We need to make sure that any blocks that were recently written out
> --
> 2.53.0
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH] ext4: kunit: extents-test: Fix percpu_counters list corruption
From: Mark Brown @ 2026-03-16 17:50 UTC (permalink / raw)
To: Ojaswin Mujoo; +Cc: Ritesh Harjani (IBM), linux-ext4
In-Reply-To: <abPh6GX0t22m628D@li-dc0c254c-257c-11b2-a85c-98b6c1322444.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 349 bytes --]
On Fri, Mar 13, 2026 at 03:37:36PM +0530, Ojaswin Mujoo wrote:
> Hence this patch is needed for the immediate fix of linux-next. And then
> we can look into merging Ye's fixes separately, once the review is
> complete.
Given the disruption to other trees I've started carrying this as a fix
but that's not ideal, any news on getting this applied?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCHBLIZZARD v7] fuse/libfuse/e2fsprogs: containerize ext4 for safer operation
From: Joanne Koong @ 2026-03-16 17:56 UTC (permalink / raw)
To: Darrick J. Wong
Cc: linux-fsdevel, bpf, linux-ext4, Miklos Szeredi, Bernd Schubert,
Theodore Ts'o, Neal Gompa, Amir Goldstein, Christian Brauner,
Jeff Layton, John, demiobenour
In-Reply-To: <20260223224617.GA2390314@frogsfrogsfrogs>
On Mon, Feb 23, 2026 at 2:46 PM Darrick J. Wong <djwong@kernel.org> wrote:
>
> There are some warts remaining:
>
> a. I would like to continue the discussion about how the design review
> of this code should be structured, and how might I go about creating
> new userspace filesystem servers -- lightweight new ones based off
> the existing userspace tools? Or by merging lklfuse?
What do you mean by "merging lklfuse"?
Could you explain what the limitations of lklfuse are compared to the
fuse iomap approach in this patchset?
Thanks,
Joanne
>
> b. ext4 doesn't support out of place writes so I don't know if that
> actually works correctly.
>
> c. fuse2fs doesn't support the ext4 journal. Urk.
>
> d. There's a VERY large quantity of fuse2fs improvements that need to be
> applied before we get to the fuse-iomap parts. I'm not sending these
> (or the fstests changes) to keep the size of the patchbomb at
> "unreasonably large". :P As a result, the fstests and e2fsprogs
> postings are very targeted.
>
> e. I've dropped the fstests part of the patchbomb because v6 was just
> way too long.
>
> I would like to get the main parts of this submission reviewed for 7.1
> now that this has been collecting comments and tweaks in non-rfc status
> for 3.5 months.
>
> Kernel:
> https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=fuse-iomap-bpf
>
> libfuse:
> https://git.kernel.org/pub/scm/linux/kernel/git/djwong/libfuse.git/log/?h=fuse-iomap-bpf
>
> e2fsprogs:
> https://git.kernel.org/pub/scm/linux/kernel/git/djwong/e2fsprogs.git/log/?h=fuse-iomap-bpf
>
> fstests:
> https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/log/?h=fuse2fs
>
> --Darrick
^ permalink raw reply
* Re: [PATCHBLIZZARD v7] fuse/libfuse/e2fsprogs: containerize ext4 for safer operation
From: Darrick J. Wong @ 2026-03-16 18:04 UTC (permalink / raw)
To: Joanne Koong
Cc: linux-fsdevel, bpf, linux-ext4, Miklos Szeredi, Bernd Schubert,
Theodore Ts'o, Neal Gompa, Amir Goldstein, Christian Brauner,
Jeff Layton, John, demiobenour
In-Reply-To: <CAJnrk1Yd1J60-Ek=O7jzZQg454pbr3O=b71yZHzYbrWfqJr__w@mail.gmail.com>
On Mon, Mar 16, 2026 at 10:56:21AM -0700, Joanne Koong wrote:
> On Mon, Feb 23, 2026 at 2:46 PM Darrick J. Wong <djwong@kernel.org> wrote:
> >
> > There are some warts remaining:
> >
> > a. I would like to continue the discussion about how the design review
> > of this code should be structured, and how might I go about creating
> > new userspace filesystem servers -- lightweight new ones based off
> > the existing userspace tools? Or by merging lklfuse?
>
> What do you mean by "merging lklfuse"?
Merging the lklfuse project into upstream Linux, which involves running
the whole kit and caboodle through our review process, and then fixing
user-mode-linux to work anywhere other than x86.
> Could you explain what the limitations of lklfuse are compared to the
> fuse iomap approach in this patchset?
The ones I know about are:
1> There's no support for vmapped kernel memory in UML mode, so anyone
who requires a large contiguous memory buffer cannot assemble them out
of "physical" pages. This has been a stumbling block for XFS in the
past.
2> LKLFUSE still uses the classic fuse IO paths, which means that at
best you can directio the IO through the lklfuse kernel. At worst you
have to use the pagecache inside the lklfuse kernel, which is very
wasteful.
3> lklfuse hasn't been updated since 6.6.
--D
> Thanks,
> Joanne
>
> >
> > b. ext4 doesn't support out of place writes so I don't know if that
> > actually works correctly.
> >
> > c. fuse2fs doesn't support the ext4 journal. Urk.
> >
> > d. There's a VERY large quantity of fuse2fs improvements that need to be
> > applied before we get to the fuse-iomap parts. I'm not sending these
> > (or the fstests changes) to keep the size of the patchbomb at
> > "unreasonably large". :P As a result, the fstests and e2fsprogs
> > postings are very targeted.
> >
> > e. I've dropped the fstests part of the patchbomb because v6 was just
> > way too long.
> >
> > I would like to get the main parts of this submission reviewed for 7.1
> > now that this has been collecting comments and tweaks in non-rfc status
> > for 3.5 months.
> >
> > Kernel:
> > https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=fuse-iomap-bpf
> >
> > libfuse:
> > https://git.kernel.org/pub/scm/linux/kernel/git/djwong/libfuse.git/log/?h=fuse-iomap-bpf
> >
> > e2fsprogs:
> > https://git.kernel.org/pub/scm/linux/kernel/git/djwong/e2fsprogs.git/log/?h=fuse-iomap-bpf
> >
> > fstests:
> > https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfstests-dev.git/log/?h=fuse2fs
> >
> > --Darrick
^ permalink raw reply
* Warning Trace seen at https://elixir.bootlin.com/linux/v6.6.69/source/fs/ext4/ext4_jbd2.c#L73 post remount-ro
From: Shramana Chakraborty @ 2026-03-16 19:32 UTC (permalink / raw)
To: tytso, adilger.kernel, linux-ext4, linux-kernel
Hi All,
I am following up on this bug, https://bugzilla.kernel.org/show_bug.cgi?id=220299, I raised last year regarding warning traces seen during systemd shutdown.
Warning Trace seen at https://elixir.bootlin.com/linux/v6.6.69/source/fs/ext4/ext4_jbd2.c#L73 is hit by the writeback system even though there is nothing to write and the filesystem has been mounted as readonly.
An ext4 fs is mounted with journal=data and a large file is written to it. Then the fs is mounted as readonly-ro post a sync. At this point of time, data consistency is preserved through the sync itself followed by a sync from the remount-ro action.
All the dirty pages should be marked as clean in the cache. Yet post the remount-ro, it hits https://elixir.bootlin.com/linux/v6.6.69/source/fs/ext4/ext4_jbd2.c#L73 and prints the trace as the fs is readonly now.
Even though there is nothing to writeback, the wb_writeback is scheduled every 5 secs or so and the same trace can be seen if changed from WARN_ON_ONCE to WARN_ON.
I found that this was reported earlier as well via https://lkml.org/lkml/2024/5/17/983.
This is still seen on 6.6.x LTS kernel with rootfs mounted with data=journal option. I wonder whether/how this could be addressed.
Thanks and Regards
Shramana Chakraborty
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox