* Re: [PATCHBLIZZARD v7] fuse/libfuse/e2fsprogs: containerize ext4 for safer operation
From: Darrick J. Wong @ 2026-03-19 16:08 UTC (permalink / raw)
To: Demi Marie Obenour
Cc: Joanne Koong, linux-fsdevel, bpf, linux-ext4, Miklos Szeredi,
Bernd Schubert, Theodore Ts'o, Neal Gompa, Amir Goldstein,
Christian Brauner, Jeff Layton, John
In-Reply-To: <c7866006-bd17-4fd8-a603-bd3016fdfeb0@gmail.com>
On Thu, Mar 19, 2026 at 03:28:21AM -0400, Demi Marie Obenour wrote:
> On 3/18/26 17:31, Darrick J. Wong wrote:
> > On Mon, Mar 16, 2026 at 08:20:29PM -0400, Demi Marie Obenour wrote:
> >> On 3/16/26 19:41, Darrick J. Wong wrote:
> >>> On Mon, Mar 16, 2026 at 04:08:55PM -0700, Joanne Koong wrote:
> >>>> On Mon, Mar 16, 2026 at 11:04 AM Darrick J. Wong <djwong@kernel.org> wrote:
> >>>>>
> >>>>> 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
> >>>>
> >>>> Gotcha, so it would basically be having to port this arch/lkl
> >>>> directory [1] into the linux tree
> >>>
> >>> Right.
> >>>
> >>>>> user-mode-linux to work anywhere other than x86.
> >>>>
> >>>> Are lklfuse and user-mode-linux (UML) two separate things or is
> >>>> lklfuse dependent on user-mode-linux?
> >>>
> >>> I was under the impression that lklfuse uses UML. Given the weird
> >>> things in arch/lkl/Kconfig:
> >>>
> >>> config 64BIT
> >>> bool "64bit kernel"
> >>> default y if OUTPUT_FORMAT = "pe-x86-64"
> >>> default $(success,$(srctree)/arch/lkl/scripts/cc-objdump-file-format.sh|grep -q '^elf64-') if OUTPUT_FORMAT != "pe-x86-64"
> >>>
> >>> I was kinda guessing x86_64 was the primary target of the developers?
> >>>
> >>> /me notes that he's now looked into libguestfs per Demi Marie's comments
> >>> and some curiosity on the part of ngompa and i>
> >>>
> >>> Whatever it is that libguestfs does to stand up unprivileged fs mounts
> >>> also could fit this bill. It's *really* slow to start because it takes
> >>> the booted kernel, creates a largeish initramfs, boots that combo via
> >>> libvirt, and then fires up a fuse server to talk to the vm kernel.
> >>>
> >>> I think all you'd have to do is change libguestfs to start the VM and
> >>> run the fuse server inside a systemd container instead of directly from
> >>> the CLI.
> >>
> >> The feedback I have gotten from ngompa is that libguestfs is just
> >> too slow for distros to use it to mount stuff.
> >
> > Yes, libguestfs is /verrrry/ slow to start up.
> >
> >>>>>> 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.
> >>>>
> >>>> For the security / isolation use cases you've described, is
> >>>> near-native performance a hard requirement?
> >>>
> >>> Not a hard requirement, just a means to convince people that they can
> >>> choose containment without completely collapsing performance.
> >>>
> >>>> As I understand it, the main use cases of this will be for mounting
> >>>> untrusted disk images and CI/filesystem testing, or are there broader
> >>>> use cases beyond this?
> >>>
> >>> That covers nearly all of it.
> >>
> >> It's worth noting that on ChromeOS and Android, the only trusted
> >> disk images are those that are read-only and protected by dm-verity.
> >> *Every* writable image is considered untrusted.
> >>
> >> I don't know if doing a full fsck at each boot is considered
> >> acceptable, but I suspect it would slow boot far too much.
> >
> > Not to mention that an attacker who gained control of the boot process
> > could inject malicious filesystem metadata after fsck completes
> > successfully but before the kernel mount occurs.
> >
> >> Yes, Google ought to be paying for the kernel changes to fix this mess.
> >>
> >>>>> 3> lklfuse hasn't been updated since 6.6.
> >>>>
> >>>> Gotcha. So if I'm understanding it correctly, the pros/cons come down to:
> >>>> lklfuse pros:
> >>>> - (arguably) easier setup cost. once it's setup (assuming it's
> >>>> possible to add support for the vmapped kernel memory thing you
> >>>> mentioned above), it'll automatically work for every filesystem vs.
> >>>> having to implement a fuse-iomap server for every filesystem
> >>>
> >>> Or even a good non-iomap fuse server for every filesystem. Admittedly
> >>> the weak part of fuse4fs is that libext2fs is not as robust as the
> >>> kernel is.
> >>>
> >>>> - easier to maintain vs. having to maintain each filesystem's
> >>>> userspace server implementation
> >>>
> >>> Yeah.
> >>>
> >>>> lklfuse cons:
> >>>> - worse (not sure by how much) performance
> >>>
> >>> Probably a lot, because now you have to run a full IO stack all the way
> >>> through lklfuse.
> >>
> >> How much is "a lot"? Is it "this is only useful for non-interactive
> >> overnight backups", "you will notice this in benchmarks but it's okay
> >> for normal use", or somewhere in between?
> >
> > Startup is painfully slow. Normal operation isn't noticeably bad, but I
> > didn't bother doing any performance comparisons.
> >
> >> Could lklfuse and iomap be combined?
> >
> > Probably, though you'd have to find a way to route the FUSE_IOMAP_*
> > requests to a filesystem driver. That's upside-down of the current
> > iomap model where filesystems have to opt into using iomap on a
> > per-IO-path basis, and then iomap calls the filesystem to find mappings.
>
> If it does get done it would be awesome. I don't think I'll be able to
> contribute, though.
I wonder if one could export a (pnfs) layout from the lklfuse kernel to
the real one, that's <cough> where struct iomap came from. A huge
downside to that solution is that layouts don't support out of place
writes because pnfs doesn't support out of place writes.
> >>>> - once it's merged into the kernel, we can't choose to not
> >>>> maintain/support it in the future
> >>>
> >>> Correct.
> >>>
> >>>> Am I understanding this correctly?
> >>>>
> >>>> In my opinion, if near-native performance is not a hard requirement,
> >>>> it seems like less pain overall to go with lklfuse. lklfuse seems a
> >>>> lot easier to maintain and I'm not sure if some complexities like
> >>>> btrfs's copy-on-write could be handled properly with fuse-iomap.
> >>>
> >>> btrfs cow can be done with iomap, at least on the directio end. It's
> >>> the other features like fsverity/fscrypt/data checksumming that aren't
> >>> currently supported by iomap.
> >>
> >> Pretty much everyone on btrfs uses data checksumming.
> >>
> >>>> What are your thoughts on this?
> >>>
> >>> "Gee, what if I could simplify most of my own work out of existence?"
> >>
> >> What is that work?
> >
> > Everything I've put out since the end of online fsck for xfs.
>
> Is pretty much all of that work either on better FUSE performance or
> fixes for problems found by fuzzers?
Mostly the iomap parts of fuse-iomap. It's a huge complication to add
to the already confusing fuse codebase.
--D
^ permalink raw reply
* Re: [PATCH v4 3/8] ext4: Add extent status cache support to kunit tests
From: Mark Brown @ 2026-03-19 15:14 UTC (permalink / raw)
To: Ojaswin Mujoo
Cc: linux-ext4, Theodore Ts'o, Ritesh Harjani, Zhang Yi, Jan Kara,
libaokun1, linux-kernel
In-Reply-To: <5f9d2668feeb89a3f3e9d03dadab8c10cbea3741.1769149131.git.ojaswin@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 466 bytes --]
On Fri, Jan 23, 2026 at 11:55:34AM +0530, Ojaswin Mujoo wrote:
> Add support in Kunit tests to ensure that the extent status cache is
> also in sync after the extent split and conversion operations.
I'm carrying a patch in -next that fixes regressions that were tracked
down to this patch:
https://lore.kernel.org/linux-ext4/5bb9041471dab8ce870c191c19cbe4df57473be8.1772381213.git.ritesh.list@gmail.com/
Any news on getting a fix integrated into the ext4 tree?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [GIT PULL 2/9] fuse2fs: add some easy new features
From: Theodore Tso @ 2026-03-19 14:59 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: linux-ext4
In-Reply-To: <177334916488.3254574.394222234133985617.stg-ugh@frogsfrogsfrogs>
On Thu, Mar 12, 2026 at 01:59:55PM -0700, Darrick J. Wong wrote:
> Please pull this branch with changes for ext4.
When reviewing this patch series, I noticed that the
debian/libext2fs2t64.symbols file used the version number of 1.47.4
for the new symbols. I'll fix it up after doing the pull, but in the
future, it's probably simpler if you don't try to adjust the debian
symbol files. I generally will take care of that before I do a Debian
release.
Thanks,
- Ted
^ permalink raw reply
* Re: [GIT PULL 1/9] fuse2fs: fix locking problems
From: Theodore Tso @ 2026-03-19 14:44 UTC (permalink / raw)
To: Darrick J. Wong; +Cc: linux-ext4
In-Reply-To: <177334916459.3254574.17133177610807268883.stg-ugh@frogsfrogsfrogs>
On Thu, Mar 12, 2026 at 01:59:39PM -0700, Darrick J. Wong wrote:
>
> Please pull this branch with changes for ext4.
Thanks, pulled into my next branch.
- Ted
^ permalink raw reply
* Re: [PATCH 12/61] quota: Prefer IS_ERR_OR_NULL over manual NULL check
From: Jan Kara @ 2026-03-19 14:13 UTC (permalink / raw)
To: Philipp Hahn
Cc: 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, Jan Kara
In-Reply-To: <20260310-b4-is_err_or_null-v1-12-bd63b656022d@avm.de>
On Tue 10-03-26 12:48:38, Philipp Hahn wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
>
> To: Jan Kara <jack@suse.com>
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
Thanks for the patch but frankly I find the original variant clearer wrt
what is going on. So I prefer to keep the code as is.
Honza
> ---
> fs/quota/quota.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/quota/quota.c b/fs/quota/quota.c
> index 33bacd70758007129e0375bab44d7431195ec441..2e09fc247d0cf45b9e83a4f8a0be7ea694c8c2a1 100644
> --- a/fs/quota/quota.c
> +++ b/fs/quota/quota.c
> @@ -965,7 +965,7 @@ SYSCALL_DEFINE4(quotactl, unsigned int, cmd, const char __user *, special,
> else
> drop_super_exclusive(sb);
> out:
> - if (pathp && !IS_ERR(pathp))
> + if (!IS_ERR_OR_NULL(pathp))
> path_put(pathp);
> return ret;
> }
>
> --
> 2.43.0
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH] ext4: xattr: fix out-of-bounds access in ext4_xattr_set_entry
From: Theodore Tso @ 2026-03-19 13:58 UTC (permalink / raw)
To: ZhengYuan Huang
Cc: adilger.kernel, tahsin, linux-ext4, linux-kernel, baijiaju1990,
r33s3n6, zzzccc427, stable
In-Reply-To: <CAOmEq9Uq5xMvhT7cyoY2uhSBhwSEEJ1vYRY36N4sxZSPCO1S8w@mail.gmail.com>
On Thu, Mar 19, 2026 at 07:13:45PM +0800, ZhengYuan Huang wrote:
>
> And yes, the reproducer does involve actively modifying the mounted
> filesystem image. We use ublk to enable this behavior.
We don't consider bugs which involve modfying the mounted filesystem
as valid from a security perspective. In particular, I don't want to
add checks to hotpaths to try to protect against these sorts of
failures, because they simply shouldn't be allowed --- and/or if the
attacker has write access to the block device while the file system is
mounted, you've basically lost already.
We have added the ioctl EXT4_IOC_SET_TUNE_SB_PARAM to more recent
kernels, and will be teaching tune2fs to use that instead of modifying
the mounted file system directly. Once that happens, we will add a
kernel configuration option which works like
CONFIG_BLK_DEV_WRITE_MOUNTED, but which is ext4 specific; so that for
distributions that are shipping a sufficiently new version of
e2fsprogs, they can block write access to mounted ext4 file systems.
Quoting from Kconfig documentation for CONFIG_BLK_DEV_WRITE_MOUNTED:
When a block device is mounted, writing to its buffer cache is very
likely going to cause filesystem corruption. It is also rather easy to
crash the kernel in this way since the filesystem has no practical way
of detecting these writes to buffer cache and verifying its metadata
integrity. However there are some setups that need this capability
like running fsck on read-only mounted root device, modifying some
features on mounted ext4 filesystem, and similar. If you say N, the
kernel will prevent processes from writing to block devices that are
mounted by filesystems which provides some more protection from runaway
privileged processes and generally makes it much harder to crash
filesystem drivers.
The official syzkaller instance sets CONFIG_BLK_DEV_WRITE_MOUNTED to
"no" and we've asked them to block fuzzers which try to modify the
file used by loopback mounts, because these sorts of syzkaller reports
are pure noise as far as we are concerned.
If system administrators are stupid enough to make the block device
world writeable, they deserve everything they get. Similarly, if
system administrators don't run fsck on random USB thumb drive dropped
in the parking lot by the MSS or the KGB before mounting it, again,
the bug is between the chair and keyboard. (For that matter,
inserting a random USB device for which you aren't sure whether it
came from a trusted source can make you vulnerable to hardware-level
attacks. Just don't do it.)
That being said, we are more likely to accept patches to address
static file system corruption, but the checks need to be done when the
metadata in question is first loaded, and outside of a hot path. But
trying to defend against dynamic modifications of the block device is
really a fools errand, without completely trashing the performance of
the file system.
Cheers,
- Ted
^ permalink raw reply
* [PATCH v4 1/5] ext4: fix miss unlock 'sb->s_umount' in extents_kunit_init()
From: Ye Bin @ 2026-03-19 12:54 UTC (permalink / raw)
To: tytso, adilger.kernel, linux-ext4; +Cc: jack
In-Reply-To: <20260319125434.333117-1-yebin@huaweicloud.com>
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>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.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 5496b2c8e2cd..82c59291e045 100644
--- a/fs/ext4/extents-test.c
+++ b/fs/ext4/extents-test.c
@@ -309,6 +309,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);
+
return 0;
}
--
2.34.1
^ permalink raw reply related
* [PATCH v4 5/5] ext4: fix possible null-ptr-deref in mbt_kunit_exit()
From: Ye Bin @ 2026-03-19 12:54 UTC (permalink / raw)
To: tytso, adilger.kernel, linux-ext4; +Cc: jack
In-Reply-To: <20260319125434.333117-1-yebin@huaweicloud.com>
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>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.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 related
* [PATCH v4 2/5] ext4: call deactivate_super() in extents_kunit_exit()
From: Ye Bin @ 2026-03-19 12:54 UTC (permalink / raw)
To: tytso, adilger.kernel, linux-ext4; +Cc: jack
In-Reply-To: <20260319125434.333117-1-yebin@huaweicloud.com>
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>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.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 82c59291e045..3d4663d99eb1 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
^ permalink raw reply related
* [PATCH v4 0/5] Fix some issues about ext4-test
From: Ye Bin @ 2026-03-19 12:54 UTC (permalink / raw)
To: tytso, adilger.kernel, linux-ext4; +Cc: jack
From: Ye Bin <yebin10@huawei.com>
This patch series is based on:
[1]: https://lore.kernel.org/linux-ext4/5bb9041471dab8ce870c191c19cbe4df57473be8.1772381213.git.ritesh.list@gmail.com/
Diff v4 vs v3:
1. Re-order PATCH[1] and PATCH[2].
2. Remove unnecessary check when call ext4_es_unregister_shrinker().
Diff v3 vs v2:
1. Remove three patches from this patchset:
ext4: fix mballoc-test.c is not compiled when EXT4_KUNIT_TESTS=M
ext4: introduce EXPORT_SYMBOL_FOR_EXT4_TEST() helper
ext4: fix extents-test.c is not compiled when EXT4_KUNIT_TESTS=M
2. Fix 'sbi' leak as no "sbi->s_sb->s_op->put_super()" registered.
Diff v2 vs v1:
1. Fix compile warning when disable EXT4_KUNIT_TESTS for patch[1][3];
2. Remove reviewed-by tag for patch[1];
Patch [1]-[2]:
Decoupled mballoc-test and extents-test from ext4. Patch [1] does not
have any changes compared to the previously released version, so the
reviewed-by is added.
Patch [3-7]:
Bugfix for extents-test.c.
Patch [8]:
Bugfix for mballoc-test.c.
Ye Bin (5):
ext4: fix miss unlock 'sb->s_umount' in extents_kunit_init()
ext4: call deactivate_super() in extents_kunit_exit()
ext4: fix the error handling process in extents_kunit_init).
ext4: fix possible null-ptr-deref in extents_kunit_exit()
ext4: fix possible null-ptr-deref in mbt_kunit_exit()
fs/ext4/extents-test.c | 53 +++++++++++++++++++++++++++++++-----------
fs/ext4/mballoc-test.c | 6 ++++-
2 files changed, 44 insertions(+), 15 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v4 4/5] ext4: fix possible null-ptr-deref in extents_kunit_exit()
From: Ye Bin @ 2026-03-19 12:54 UTC (permalink / raw)
To: tytso, adilger.kernel, linux-ext4; +Cc: jack
In-Reply-To: <20260319125434.333117-1-yebin@huaweicloud.com>
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>
Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.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 4ce3f81f6409..91aa2136703f 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);
--
2.34.1
^ permalink raw reply related
* [PATCH v4 3/5] ext4: fix the error handling process in extents_kunit_init).
From: Ye Bin @ 2026-03-19 12:54 UTC (permalink / raw)
To: tytso, adilger.kernel, linux-ext4; +Cc: jack
In-Reply-To: <20260319125434.333117-1-yebin@huaweicloud.com>
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;
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);
+ deactivate_locked_super(sb);
+ kfree(sbi);
+
+ return err;
}
/*
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3] ext4: fix use-after-free in update_super_work when racing with umount
From: Jan Kara @ 2026-03-19 12:48 UTC (permalink / raw)
To: Jiayuan Chen
Cc: linux-ext4, jack, Jiayuan Chen, Theodore Ts'o, Andreas Dilger,
Ritesh Harjani, Ye Bin, linux-kernel
In-Reply-To: <20260319120336.157873-1-jiayuan.chen@linux.dev>
On Thu 19-03-26 20:03:35, Jiayuan Chen wrote:
> From: Jiayuan Chen <jiayuan.chen@shopee.com>
>
> Commit b98535d09179 ("ext4: fix bug_on in start_this_handle during umount
> filesystem") moved ext4_unregister_sysfs() before flushing s_sb_upd_work
> to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups
> reads during unmount. However, this introduced a use-after-free because
> update_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which
> accesses the kobject's kernfs_node after it has been freed by kobject_del()
> in ext4_unregister_sysfs():
>
> update_super_work ext4_put_super
> ----------------- --------------
> ext4_unregister_sysfs(sb)
> kobject_del(&sbi->s_kobj)
> __kobject_del()
> sysfs_remove_dir()
> kobj->sd = NULL
> sysfs_put(sd)
> kernfs_put() // RCU free
> ext4_notify_error_sysfs(sbi)
> sysfs_notify(&sbi->s_kobj)
> kn = kobj->sd // stale pointer
> kernfs_get(kn) // UAF on freed kernfs_node
> ext4_journal_destroy()
> flush_work(&sbi->s_sb_upd_work)
>
> Instead of reordering the teardown sequence, fix this by making
> ext4_notify_error_sysfs() detect that sysfs has already been torn down
> by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call
> in that case. A dedicated mutex (s_error_notify_mutex) serializes
> ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs()
> to prevent TOCTOU races where the kobject could be deleted between the
> state_in_sysfs check and the sysfs_notify() call.
>
> Fixes: b98535d09179 ("ext4: fix bug_on in start_this_handle during umount filesystem")
> Cc: Jiayuan Chen <jiayuan.chen@linux.dev>
> Suggested-by: Jan Kara <jack@suse.cz>
> Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
Looks good to me! Feel free to add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> v2 -> v3: Fix issues reported by AI.
> https://sashiko.dev/#/patchset/20260319073651.79209-1-jiayuan.chen%40linux.dev
>
> v1 -> v2: Use state_in_sysfs instead of reordering the teardown
> sequence.
> https://lore.kernel.org/linux-ext4/20260313065206.152645-1-jiayuan.chen@linux.dev/
> ---
> fs/ext4/ext4.h | 1 +
> fs/ext4/super.c | 1 +
> fs/ext4/sysfs.c | 10 +++++++++-
> 3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index b76966dc06c0..c012e85d2515 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -1574,6 +1574,7 @@ struct ext4_sb_info {
> struct proc_dir_entry *s_proc;
> struct kobject s_kobj;
> struct completion s_kobj_unregister;
> + struct mutex s_error_notify_mutex; /* protects sysfs_notify vs kobject_del */
> struct super_block *s_sb;
> struct buffer_head *s_mmp_bh;
>
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 752f414aa06b..b2d58a9b0413 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -5397,6 +5397,7 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb)
>
> timer_setup(&sbi->s_err_report, print_daily_error_info, 0);
> spin_lock_init(&sbi->s_error_lock);
> + mutex_init(&sbi->s_error_notify_mutex);
> INIT_WORK(&sbi->s_sb_upd_work, update_super_work);
>
> err = ext4_group_desc_init(sb, es, logical_sb_block, &first_not_zeroed);
> diff --git a/fs/ext4/sysfs.c b/fs/ext4/sysfs.c
> index d2ecc1026c0c..0503bf02aea1 100644
> --- a/fs/ext4/sysfs.c
> +++ b/fs/ext4/sysfs.c
> @@ -597,7 +597,10 @@ static const struct kobj_type ext4_feat_ktype = {
>
> void ext4_notify_error_sysfs(struct ext4_sb_info *sbi)
> {
> - sysfs_notify(&sbi->s_kobj, NULL, "errors_count");
> + mutex_lock(&sbi->s_error_notify_mutex);
> + if (sbi->s_kobj.state_in_sysfs)
> + sysfs_notify(&sbi->s_kobj, NULL, "errors_count");
> + mutex_unlock(&sbi->s_error_notify_mutex);
> }
>
> static struct kobject *ext4_root;
> @@ -610,8 +613,10 @@ int ext4_register_sysfs(struct super_block *sb)
> int err;
>
> init_completion(&sbi->s_kobj_unregister);
> + mutex_lock(&sbi->s_error_notify_mutex);
> err = kobject_init_and_add(&sbi->s_kobj, &ext4_sb_ktype, ext4_root,
> "%s", sb->s_id);
> + mutex_unlock(&sbi->s_error_notify_mutex);
> if (err) {
> kobject_put(&sbi->s_kobj);
> wait_for_completion(&sbi->s_kobj_unregister);
> @@ -644,7 +649,10 @@ void ext4_unregister_sysfs(struct super_block *sb)
>
> if (sbi->s_proc)
> remove_proc_subtree(sb->s_id, ext4_proc_root);
> +
> + mutex_lock(&sbi->s_error_notify_mutex);
> kobject_del(&sbi->s_kobj);
> + mutex_unlock(&sbi->s_error_notify_mutex);
> }
>
> int __init ext4_init_sysfs(void)
> --
> 2.43.0
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [PATCH v3] ext4: fix use-after-free in update_super_work when racing with umount
From: Jiayuan Chen @ 2026-03-19 12:03 UTC (permalink / raw)
To: linux-ext4, jack
Cc: Jiayuan Chen, Jiayuan Chen, Theodore Ts'o, Andreas Dilger,
Ritesh Harjani, Ye Bin, linux-kernel
From: Jiayuan Chen <jiayuan.chen@shopee.com>
Commit b98535d09179 ("ext4: fix bug_on in start_this_handle during umount
filesystem") moved ext4_unregister_sysfs() before flushing s_sb_upd_work
to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups
reads during unmount. However, this introduced a use-after-free because
update_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which
accesses the kobject's kernfs_node after it has been freed by kobject_del()
in ext4_unregister_sysfs():
update_super_work ext4_put_super
----------------- --------------
ext4_unregister_sysfs(sb)
kobject_del(&sbi->s_kobj)
__kobject_del()
sysfs_remove_dir()
kobj->sd = NULL
sysfs_put(sd)
kernfs_put() // RCU free
ext4_notify_error_sysfs(sbi)
sysfs_notify(&sbi->s_kobj)
kn = kobj->sd // stale pointer
kernfs_get(kn) // UAF on freed kernfs_node
ext4_journal_destroy()
flush_work(&sbi->s_sb_upd_work)
Instead of reordering the teardown sequence, fix this by making
ext4_notify_error_sysfs() detect that sysfs has already been torn down
by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call
in that case. A dedicated mutex (s_error_notify_mutex) serializes
ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs()
to prevent TOCTOU races where the kobject could be deleted between the
state_in_sysfs check and the sysfs_notify() call.
Fixes: b98535d09179 ("ext4: fix bug_on in start_this_handle during umount filesystem")
Cc: Jiayuan Chen <jiayuan.chen@linux.dev>
Suggested-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
---
v2 -> v3: Fix issues reported by AI.
https://sashiko.dev/#/patchset/20260319073651.79209-1-jiayuan.chen%40linux.dev
v1 -> v2: Use state_in_sysfs instead of reordering the teardown
sequence.
https://lore.kernel.org/linux-ext4/20260313065206.152645-1-jiayuan.chen@linux.dev/
---
fs/ext4/ext4.h | 1 +
fs/ext4/super.c | 1 +
fs/ext4/sysfs.c | 10 +++++++++-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index b76966dc06c0..c012e85d2515 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -1574,6 +1574,7 @@ struct ext4_sb_info {
struct proc_dir_entry *s_proc;
struct kobject s_kobj;
struct completion s_kobj_unregister;
+ struct mutex s_error_notify_mutex; /* protects sysfs_notify vs kobject_del */
struct super_block *s_sb;
struct buffer_head *s_mmp_bh;
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 752f414aa06b..b2d58a9b0413 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -5397,6 +5397,7 @@ static int __ext4_fill_super(struct fs_context *fc, struct super_block *sb)
timer_setup(&sbi->s_err_report, print_daily_error_info, 0);
spin_lock_init(&sbi->s_error_lock);
+ mutex_init(&sbi->s_error_notify_mutex);
INIT_WORK(&sbi->s_sb_upd_work, update_super_work);
err = ext4_group_desc_init(sb, es, logical_sb_block, &first_not_zeroed);
diff --git a/fs/ext4/sysfs.c b/fs/ext4/sysfs.c
index d2ecc1026c0c..0503bf02aea1 100644
--- a/fs/ext4/sysfs.c
+++ b/fs/ext4/sysfs.c
@@ -597,7 +597,10 @@ static const struct kobj_type ext4_feat_ktype = {
void ext4_notify_error_sysfs(struct ext4_sb_info *sbi)
{
- sysfs_notify(&sbi->s_kobj, NULL, "errors_count");
+ mutex_lock(&sbi->s_error_notify_mutex);
+ if (sbi->s_kobj.state_in_sysfs)
+ sysfs_notify(&sbi->s_kobj, NULL, "errors_count");
+ mutex_unlock(&sbi->s_error_notify_mutex);
}
static struct kobject *ext4_root;
@@ -610,8 +613,10 @@ int ext4_register_sysfs(struct super_block *sb)
int err;
init_completion(&sbi->s_kobj_unregister);
+ mutex_lock(&sbi->s_error_notify_mutex);
err = kobject_init_and_add(&sbi->s_kobj, &ext4_sb_ktype, ext4_root,
"%s", sb->s_id);
+ mutex_unlock(&sbi->s_error_notify_mutex);
if (err) {
kobject_put(&sbi->s_kobj);
wait_for_completion(&sbi->s_kobj_unregister);
@@ -644,7 +649,10 @@ void ext4_unregister_sysfs(struct super_block *sb)
if (sbi->s_proc)
remove_proc_subtree(sb->s_id, ext4_proc_root);
+
+ mutex_lock(&sbi->s_error_notify_mutex);
kobject_del(&sbi->s_kobj);
+ mutex_unlock(&sbi->s_error_notify_mutex);
}
int __init ext4_init_sysfs(void)
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2] ext4: fix use-after-free in update_super_work when racing with umount
From: Jiayuan Chen @ 2026-03-19 11:17 UTC (permalink / raw)
To: Jan Kara
Cc: linux-ext4, Jiayuan Chen, Theodore Ts'o, Andreas Dilger,
Ye Bin, Ritesh Harjani, linux-kernel
In-Reply-To: <h4afxbv3sivvopwqfnccd235wywla6bvwk6a5qp5yuwg5pnr2e@s7jlvfxjgxgq>
On 3/19/26 6:50 PM, Jan Kara wrote:
> The initialization of s_error_notify_mutex should happen early in
> ext4_fill_super() as ext4_notify_error_sysfs() can be called rather early
> before ext4_register_sysfs() is called.
>
> Also we should protect kobject_init_and_add() with s_error_notify_mutex to
> handle the case where ext4_notify_error_sysfs() is racing with
> ext4_register_sysfs().
>
> Honza
> -- Jan Kara <jack@suse.com> SUSE Labs, CR
Hi Honza,
Thanks for the review! The AI catches are reasonable — I'll move
mutex_init() earlier in ext4_fill_super() and protect kobject_init_and_add()
with the mutex.
Thanks,
Jiayuan
^ permalink raw reply
* Re: [PATCH] ext4: xattr: fix out-of-bounds access in ext4_xattr_set_entry
From: ZhengYuan Huang @ 2026-03-19 11:13 UTC (permalink / raw)
To: Theodore Tso
Cc: adilger.kernel, tahsin, linux-ext4, linux-kernel, baijiaju1990,
r33s3n6, zzzccc427, stable
In-Reply-To: <20260318144509.GA82331@macsyma-wired.lan>
On Wed, Mar 18, 2026 at 10:46 PM Theodore Tso <tytso@mit.edu> wrote:
> Can you send us a pointer to the reproducer? And does the reproducer
> involve actively modifying the mounted file system image, either via
> the block device or the underlying file (if a loop device is being used)?
Thanks for your reply. I'm happy to provide a reproducer. The
following PoC reproduces the bug deterministically.
The PoC is too large to inline in email, so I uploaded it here:
https://drive.google.com/drive/folders/1OzH1XvAOAb9ulpOKfL70U1LvXhhlHAyz
Steps to reproduce:
1. Download the PoC from the provided link and extract it.
2. Build the ublk helper program from the ublk codebase, which is
used to provide the runtime corruption capability:
g++ -std=c++20 -fcoroutines -O2 -o standalone_replay \
standalone_replay_ext4.cpp targets/ublksrv_tgt.cpp \
-I. -Iinclude -Itargets/include \
-L./lib/.libs -lublksrv -luring -lpthread
3. Attach the image through ublk:
./standalone_replay add -t loop -f /path/to/image
4. Run the reproducer:
./syz-execprog -executor=./syz-executor -repeat=0 -procs=1 -threaded=0
-sandbox=none -method=dynamic -fstype=ext4 ./corpus0
I can reproduce the issue reliably on Ubuntu 24.04.
For completeness: the syz-execprog and syz-executor binaries here are
based on syzkaller, with only small local changes to add the
environment setup required by this reproducer. I can also provide the
modified sources if that would be helpful.
Apologies for the complexity of the reproducer. This issue was found
by our fuzzing tool, and I am still working on minimizing it,
which might take some time. I will send an updated, minimized version
as soon as possible.
And yes, the reproducer does involve actively modifying the mounted
filesystem image. We use ublk to enable this behavior.
thanks,
ZhengYuan Huang
^ permalink raw reply
* Re: [PATCH v2] ext4: fix use-after-free in update_super_work when racing with umount
From: Jan Kara @ 2026-03-19 10:50 UTC (permalink / raw)
To: Jiayuan Chen
Cc: linux-ext4, jack, Jiayuan Chen, Theodore Ts'o, Andreas Dilger,
Ye Bin, Ritesh Harjani, linux-kernel
In-Reply-To: <20260319073651.79209-1-jiayuan.chen@linux.dev>
On Thu 19-03-26 15:36:50, Jiayuan Chen wrote:
> From: Jiayuan Chen <jiayuan.chen@shopee.com>
>
> Commit b98535d09179 ("ext4: fix bug_on in start_this_handle during umount
> filesystem") moved ext4_unregister_sysfs() before flushing s_sb_upd_work
> to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups
> reads during unmount. However, this introduced a use-after-free because
> update_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which
> accesses the kobject's kernfs_node after it has been freed by kobject_del()
> in ext4_unregister_sysfs():
>
> update_super_work ext4_put_super
> ----------------- --------------
> ext4_unregister_sysfs(sb)
> kobject_del(&sbi->s_kobj)
> __kobject_del()
> sysfs_remove_dir()
> kobj->sd = NULL
> sysfs_put(sd)
> kernfs_put() // RCU free
> ext4_notify_error_sysfs(sbi)
> sysfs_notify(&sbi->s_kobj)
> kn = kobj->sd // stale pointer
> kernfs_get(kn) // UAF on freed kernfs_node
> ext4_journal_destroy()
> flush_work(&sbi->s_sb_upd_work)
>
> Instead of reordering the teardown sequence, fix this by making
> ext4_notify_error_sysfs() detect that sysfs has already been torn down
> by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call
> in that case. A dedicated mutex (s_error_notify_mutex) serializes
> ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs()
> to prevent TOCTOU races where the kobject could be deleted between the
> state_in_sysfs check and the sysfs_notify() call.
>
> Fixes: b98535d09179 ("ext4: fix bug_on in start_this_handle during umount filesystem")
> Cc: Jiayuan Chen <jiayuan.chen@linux.dev>
> Suggested-by: Jan Kara <jack@suse.cz>
> Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
Thanks for the patch! Automated AI review
(https://sashiko.dev/#/patchset/20260319073651.79209-1-jiayuan.chen%40linux.dev)
has noticed two small issues with this:
> diff --git a/fs/ext4/sysfs.c b/fs/ext4/sysfs.c
> index d2ecc1026c0c..f2505988e010 100644
> --- a/fs/ext4/sysfs.c
> +++ b/fs/ext4/sysfs.c
> @@ -597,7 +597,10 @@ static const struct kobj_type ext4_feat_ktype = {
>
> void ext4_notify_error_sysfs(struct ext4_sb_info *sbi)
> {
> - sysfs_notify(&sbi->s_kobj, NULL, "errors_count");
> + mutex_lock(&sbi->s_error_notify_mutex);
> + if (sbi->s_kobj.state_in_sysfs)
> + sysfs_notify(&sbi->s_kobj, NULL, "errors_count");
> + mutex_unlock(&sbi->s_error_notify_mutex);
> }
>
> static struct kobject *ext4_root;
> @@ -610,6 +613,7 @@ int ext4_register_sysfs(struct super_block *sb)
> int err;
>
> init_completion(&sbi->s_kobj_unregister);
> + mutex_init(&sbi->s_error_notify_mutex);
> err = kobject_init_and_add(&sbi->s_kobj, &ext4_sb_ktype, ext4_root,
> "%s", sb->s_id);
> if (err) {
The initialization of s_error_notify_mutex should happen early in
ext4_fill_super() as ext4_notify_error_sysfs() can be called rather early
before ext4_register_sysfs() is called.
Also we should protect kobject_init_and_add() with s_error_notify_mutex to
handle the case where ext4_notify_error_sysfs() is racing with
ext4_register_sysfs().
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [syzbot] [ext4?] general protection fault in ext4_split_extent_at
From: syzbot @ 2026-03-19 10:24 UTC (permalink / raw)
To: adilger.kernel, linux-ext4, linux-kernel, syzkaller-bugs, tytso
Hello,
syzbot found the following issue on:
HEAD commit: 1c9982b49613 Merge tag 'drm-fixes-2026-03-14' of https://g..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15e35d52580000
kernel config: https://syzkaller.appspot.com/x/.config?x=ccef46afa67b2b19
dashboard link: https://syzkaller.appspot.com/bug?extid=1ffa5d865557e51cb604
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-1c9982b4.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/0ac9f4872167/vmlinux-1c9982b4.xz
kernel image: https://storage.googleapis.com/syzbot-assets/bdee9f3a13ab/bzImage-1c9982b4.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+1ffa5d865557e51cb604@syzkaller.appspotmail.com
EXT4-fs (loop0): pa ffff88804798e658: logic 0, phys. 209, len 19
EXT4-fs error (device loop0): ext4_mb_release_inode_pa:5465: group 0, free 0, pa_free 8
EXT4-fs error (device loop0): ext4_ext_split:1151: inode #18: comm kworker/u4:8: eh_entries 0 != eh_max 84!
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 UID: 0 PID: 1060 Comm: kworker/u4:8 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: ext4-rsv-conversion ext4_end_io_rsv_work
RIP: 0010:ext4_split_extent_at+0x486/0xa40 fs/ext4/extents.c:3266
Code: 02 00 00 e8 0c 90 42 ff 49 bf 00 00 00 00 00 fc ff df 4c 8b 6c 24 38 0f b7 9c 24 e4 00 00 00 49 83 c4 04 4c 89 e0 48 c1 e8 03 <42> 0f b6 04 38 84 c0 0f 85 23 05 00 00 66 41 89 1c 24 4c 8b 74 24
RSP: 0018:ffffc90001567180 EFLAGS: 00010247
RAX: 0000000000000000 RBX: 0000000000008004 RCX: ffff8880331d4980
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc900015672c8 R08: ffff888047a501d7 R09: 1ffff11008f4a03a
R10: dffffc0000000000 R11: ffffed1008f4a03b R12: 0000000000000004
R13: 1ffff920002ace44 R14: ffff8880368d5500 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff88808ca55000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007feb2c215ff8 CR3: 00000000123cf000 CR4: 0000000000352ef0
Call Trace:
<TASK>
ext4_split_extent fs/ext4/extents.c:3440 [inline]
ext4_split_convert_extents+0x36d/0x1a00 fs/ext4/extents.c:3830
ext4_convert_unwritten_extents_endio fs/ext4/extents.c:3906 [inline]
ext4_ext_handle_unwritten_extents fs/ext4/extents.c:3990 [inline]
ext4_ext_map_blocks+0xe70/0x58b0 fs/ext4/extents.c:4327
ext4_map_create_blocks+0x11d/0x540 fs/ext4/inode.c:616
ext4_map_blocks+0x7cd/0x11d0 fs/ext4/inode.c:809
ext4_convert_unwritten_extents+0x2be/0x5f0 fs/ext4/extents.c:5029
ext4_convert_unwritten_io_end_vec+0xff/0x170 fs/ext4/extents.c:5069
ext4_end_io_end+0xc7/0x410 fs/ext4/page-io.c:200
ext4_do_flush_completed_IO fs/ext4/page-io.c:291 [inline]
ext4_end_io_rsv_work+0x26a/0x340 fs/ext4/page-io.c:306
process_one_work kernel/workqueue.c:3276 [inline]
process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:ext4_split_extent_at+0x486/0xa40 fs/ext4/extents.c:3266
Code: 02 00 00 e8 0c 90 42 ff 49 bf 00 00 00 00 00 fc ff df 4c 8b 6c 24 38 0f b7 9c 24 e4 00 00 00 49 83 c4 04 4c 89 e0 48 c1 e8 03 <42> 0f b6 04 38 84 c0 0f 85 23 05 00 00 66 41 89 1c 24 4c 8b 74 24
RSP: 0018:ffffc90001567180 EFLAGS: 00010247
RAX: 0000000000000000 RBX: 0000000000008004 RCX: ffff8880331d4980
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: ffffc900015672c8 R08: ffff888047a501d7 R09: 1ffff11008f4a03a
R10: dffffc0000000000 R11: ffffed1008f4a03b R12: 0000000000000004
R13: 1ffff920002ace44 R14: ffff8880368d5500 R15: dffffc0000000000
FS: 0000000000000000(0000) GS:ffff88808ca55000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007feb2c215ff8 CR3: 00000000123cf000 CR4: 0000000000352ef0
----------------
Code disassembly (best guess):
0: 02 00 add (%rax),%al
2: 00 e8 add %ch,%al
4: 0c 90 or $0x90,%al
6: 42 ff 49 bf rex.X decl -0x41(%rcx)
a: 00 00 add %al,(%rax)
c: 00 00 add %al,(%rax)
e: 00 fc add %bh,%ah
10: ff lcall (bad)
11: df 4c 8b 6c fisttps 0x6c(%rbx,%rcx,4)
15: 24 38 and $0x38,%al
17: 0f b7 9c 24 e4 00 00 movzwl 0xe4(%rsp),%ebx
1e: 00
1f: 49 83 c4 04 add $0x4,%r12
23: 4c 89 e0 mov %r12,%rax
26: 48 c1 e8 03 shr $0x3,%rax
* 2a: 42 0f b6 04 38 movzbl (%rax,%r15,1),%eax <-- trapping instruction
2f: 84 c0 test %al,%al
31: 0f 85 23 05 00 00 jne 0x55a
37: 66 41 89 1c 24 mov %bx,(%r12)
3c: 4c rex.WR
3d: 8b .byte 0x8b
3e: 74 24 je 0x64
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply
* [PATCH] ext4: Fix the might_sleep() warnings in kvfree()
From: Zqiang @ 2026-03-19 9:45 UTC (permalink / raw)
To: tytso, adilger.kernel, libaokun; +Cc: linux-ext4, linux-kernel, qiang.zhang
Use the kvfree() in the RCU read critical section can trigger
the following warnings:
EXT4-fs (vdb): unmounting filesystem cd983e5b-3c83-4f5a-a136-17b00eb9d018.
WARNING: suspicious RCU usage
./include/linux/rcupdate.h:409 Illegal context switch in RCU read-side critical section!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
Call Trace:
<TASK>
dump_stack_lvl+0xbb/0xd0
dump_stack+0x14/0x20
lockdep_rcu_suspicious+0x15a/0x1b0
__might_resched+0x375/0x4d0
? put_object.part.0+0x2c/0x50
__might_sleep+0x108/0x160
vfree+0x58/0x910
? ext4_group_desc_free+0x27/0x270
kvfree+0x23/0x40
ext4_group_desc_free+0x111/0x270
ext4_put_super+0x3c8/0xd40
generic_shutdown_super+0x14c/0x4a0
? __pfx_shrinker_free+0x10/0x10
kill_block_super+0x40/0x90
ext4_kill_sb+0x6d/0xb0
deactivate_locked_super+0xb4/0x180
deactivate_super+0x7e/0xa0
cleanup_mnt+0x296/0x3e0
__cleanup_mnt+0x16/0x20
task_work_run+0x157/0x250
? __pfx_task_work_run+0x10/0x10
? exit_to_user_mode_loop+0x6a/0x550
exit_to_user_mode_loop+0x102/0x550
do_syscall_64+0x44a/0x500
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
BUG: sleeping function called from invalid context at mm/vmalloc.c:3441
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556, name: umount
preempt_count: 1, expected: 0
CPU: 3 UID: 0 PID: 556 Comm: umount
Call Trace:
<TASK>
dump_stack_lvl+0xbb/0xd0
dump_stack+0x14/0x20
__might_resched+0x275/0x4d0
? put_object.part.0+0x2c/0x50
__might_sleep+0x108/0x160
vfree+0x58/0x910
? ext4_group_desc_free+0x27/0x270
kvfree+0x23/0x40
ext4_group_desc_free+0x111/0x270
ext4_put_super+0x3c8/0xd40
generic_shutdown_super+0x14c/0x4a0
? __pfx_shrinker_free+0x10/0x10
kill_block_super+0x40/0x90
ext4_kill_sb+0x6d/0xb0
deactivate_locked_super+0xb4/0x180
deactivate_super+0x7e/0xa0
cleanup_mnt+0x296/0x3e0
__cleanup_mnt+0x16/0x20
task_work_run+0x157/0x250
? __pfx_task_work_run+0x10/0x10
? exit_to_user_mode_loop+0x6a/0x550
exit_to_user_mode_loop+0x102/0x550
do_syscall_64+0x44a/0x500
entry_SYSCALL_64_after_hwframe+0x77/0x7f
The above scenarios occur in initialization failures and teardown
paths, there are no parallel operations on the resources released
by kvfree(), this commit therefore remove rcu_read_lock/unlock() and
use rcu_access_pointer() instead of rcu_dereference() operations.
Fixes: 7c990728b99e ("ext4: fix potential race between s_flex_groups online resizing and access")
Fixes: df3da4ea5a0f ("ext4: fix potential race between s_group_info online resizing and access")
Signed-off-by: Zqiang <qiang.zhang@linux.dev>
---
fs/ext4/mballoc.c | 10 +++-------
fs/ext4/super.c | 8 ++------
2 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/fs/ext4/mballoc.c b/fs/ext4/mballoc.c
index 20e9fdaf4301..e96513cc6151 100644
--- a/fs/ext4/mballoc.c
+++ b/fs/ext4/mballoc.c
@@ -3580,9 +3580,7 @@ static int ext4_mb_init_backend(struct super_block *sb)
rcu_read_unlock();
iput(sbi->s_buddy_cache);
err_freesgi:
- rcu_read_lock();
- kvfree(rcu_dereference(sbi->s_group_info));
- rcu_read_unlock();
+ kvfree(rcu_access_pointer(sbi->s_group_info));
return -ENOMEM;
}
@@ -3897,7 +3895,8 @@ void ext4_mb_release(struct super_block *sb)
WARN_ON_ONCE(!list_empty(&sbi->s_discard_list));
}
- if (sbi->s_group_info) {
+ group_info = rcu_access_pointer(sbi->s_group_info);
+ if (group_info) {
for (i = 0; i < ngroups; i++) {
cond_resched();
grinfo = ext4_get_group_info(sb, i);
@@ -3915,12 +3914,9 @@ void ext4_mb_release(struct super_block *sb)
num_meta_group_infos = (ngroups +
EXT4_DESC_PER_BLOCK(sb) - 1) >>
EXT4_DESC_PER_BLOCK_BITS(sb);
- rcu_read_lock();
- group_info = rcu_dereference(sbi->s_group_info);
for (i = 0; i < num_meta_group_infos; i++)
kfree(group_info[i]);
kvfree(group_info);
- rcu_read_unlock();
}
ext4_mb_avg_fragment_size_destroy(sbi);
ext4_mb_largest_free_orders_destroy(sbi);
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 43f680c750ae..0b2fa7bd787f 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -1254,12 +1254,10 @@ static void ext4_group_desc_free(struct ext4_sb_info *sbi)
struct buffer_head **group_desc;
int i;
- rcu_read_lock();
- group_desc = rcu_dereference(sbi->s_group_desc);
+ group_desc = rcu_access_pointer(sbi->s_group_desc);
for (i = 0; i < sbi->s_gdb_count; i++)
brelse(group_desc[i]);
kvfree(group_desc);
- rcu_read_unlock();
}
static void ext4_flex_groups_free(struct ext4_sb_info *sbi)
@@ -1267,14 +1265,12 @@ static void ext4_flex_groups_free(struct ext4_sb_info *sbi)
struct flex_groups **flex_groups;
int i;
- rcu_read_lock();
- flex_groups = rcu_dereference(sbi->s_flex_groups);
+ flex_groups = rcu_access_pointer(sbi->s_flex_groups);
if (flex_groups) {
for (i = 0; i < sbi->s_flex_groups_allocated; i++)
kvfree(flex_groups[i]);
kvfree(flex_groups);
}
- rcu_read_unlock();
}
static void ext4_put_super(struct super_block *sb)
--
2.17.1
^ permalink raw reply related
* [PATCH v2] ext4: fix use-after-free in update_super_work when racing with umount
From: Jiayuan Chen @ 2026-03-19 7:36 UTC (permalink / raw)
To: linux-ext4, jack
Cc: Jiayuan Chen, Jiayuan Chen, Theodore Ts'o, Andreas Dilger,
Ye Bin, Ritesh Harjani, linux-kernel
From: Jiayuan Chen <jiayuan.chen@shopee.com>
Commit b98535d09179 ("ext4: fix bug_on in start_this_handle during umount
filesystem") moved ext4_unregister_sysfs() before flushing s_sb_upd_work
to prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups
reads during unmount. However, this introduced a use-after-free because
update_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which
accesses the kobject's kernfs_node after it has been freed by kobject_del()
in ext4_unregister_sysfs():
update_super_work ext4_put_super
----------------- --------------
ext4_unregister_sysfs(sb)
kobject_del(&sbi->s_kobj)
__kobject_del()
sysfs_remove_dir()
kobj->sd = NULL
sysfs_put(sd)
kernfs_put() // RCU free
ext4_notify_error_sysfs(sbi)
sysfs_notify(&sbi->s_kobj)
kn = kobj->sd // stale pointer
kernfs_get(kn) // UAF on freed kernfs_node
ext4_journal_destroy()
flush_work(&sbi->s_sb_upd_work)
Instead of reordering the teardown sequence, fix this by making
ext4_notify_error_sysfs() detect that sysfs has already been torn down
by checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call
in that case. A dedicated mutex (s_error_notify_mutex) serializes
ext4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs()
to prevent TOCTOU races where the kobject could be deleted between the
state_in_sysfs check and the sysfs_notify() call.
Fixes: b98535d09179 ("ext4: fix bug_on in start_this_handle during umount filesystem")
Cc: Jiayuan Chen <jiayuan.chen@linux.dev>
Suggested-by: Jan Kara <jack@suse.cz>
Signed-off-by: Jiayuan Chen <jiayuan.chen@shopee.com>
---
v1 -> v2: Use state_in_sysfs instead of reordering the teardown
sequence.
https://lore.kernel.org/linux-ext4/20260313065206.152645-1-jiayuan.chen@linux.dev/
---
fs/ext4/ext4.h | 1 +
fs/ext4/sysfs.c | 9 ++++++++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index b76966dc06c0..c012e85d2515 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -1574,6 +1574,7 @@ struct ext4_sb_info {
struct proc_dir_entry *s_proc;
struct kobject s_kobj;
struct completion s_kobj_unregister;
+ struct mutex s_error_notify_mutex; /* protects sysfs_notify vs kobject_del */
struct super_block *s_sb;
struct buffer_head *s_mmp_bh;
diff --git a/fs/ext4/sysfs.c b/fs/ext4/sysfs.c
index d2ecc1026c0c..f2505988e010 100644
--- a/fs/ext4/sysfs.c
+++ b/fs/ext4/sysfs.c
@@ -597,7 +597,10 @@ static const struct kobj_type ext4_feat_ktype = {
void ext4_notify_error_sysfs(struct ext4_sb_info *sbi)
{
- sysfs_notify(&sbi->s_kobj, NULL, "errors_count");
+ mutex_lock(&sbi->s_error_notify_mutex);
+ if (sbi->s_kobj.state_in_sysfs)
+ sysfs_notify(&sbi->s_kobj, NULL, "errors_count");
+ mutex_unlock(&sbi->s_error_notify_mutex);
}
static struct kobject *ext4_root;
@@ -610,6 +613,7 @@ int ext4_register_sysfs(struct super_block *sb)
int err;
init_completion(&sbi->s_kobj_unregister);
+ mutex_init(&sbi->s_error_notify_mutex);
err = kobject_init_and_add(&sbi->s_kobj, &ext4_sb_ktype, ext4_root,
"%s", sb->s_id);
if (err) {
@@ -644,7 +648,10 @@ void ext4_unregister_sysfs(struct super_block *sb)
if (sbi->s_proc)
remove_proc_subtree(sb->s_id, ext4_proc_root);
+
+ mutex_lock(&sbi->s_error_notify_mutex);
kobject_del(&sbi->s_kobj);
+ mutex_unlock(&sbi->s_error_notify_mutex);
}
int __init ext4_init_sysfs(void)
--
2.43.0
^ permalink raw reply related
* Re: [PATCHBLIZZARD v7] fuse/libfuse/e2fsprogs: containerize ext4 for safer operation
From: Demi Marie Obenour @ 2026-03-19 7:28 UTC (permalink / raw)
To: Darrick J. Wong
Cc: Joanne Koong, linux-fsdevel, bpf, linux-ext4, Miklos Szeredi,
Bernd Schubert, Theodore Ts'o, Neal Gompa, Amir Goldstein,
Christian Brauner, Jeff Layton, John
In-Reply-To: <20260318213129.GB6004@frogsfrogsfrogs>
[-- Attachment #1.1.1: Type: text/plain, Size: 7118 bytes --]
On 3/18/26 17:31, Darrick J. Wong wrote:
> On Mon, Mar 16, 2026 at 08:20:29PM -0400, Demi Marie Obenour wrote:
>> On 3/16/26 19:41, Darrick J. Wong wrote:
>>> On Mon, Mar 16, 2026 at 04:08:55PM -0700, Joanne Koong wrote:
>>>> On Mon, Mar 16, 2026 at 11:04 AM Darrick J. Wong <djwong@kernel.org> wrote:
>>>>>
>>>>> 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
>>>>
>>>> Gotcha, so it would basically be having to port this arch/lkl
>>>> directory [1] into the linux tree
>>>
>>> Right.
>>>
>>>>> user-mode-linux to work anywhere other than x86.
>>>>
>>>> Are lklfuse and user-mode-linux (UML) two separate things or is
>>>> lklfuse dependent on user-mode-linux?
>>>
>>> I was under the impression that lklfuse uses UML. Given the weird
>>> things in arch/lkl/Kconfig:
>>>
>>> config 64BIT
>>> bool "64bit kernel"
>>> default y if OUTPUT_FORMAT = "pe-x86-64"
>>> default $(success,$(srctree)/arch/lkl/scripts/cc-objdump-file-format.sh|grep -q '^elf64-') if OUTPUT_FORMAT != "pe-x86-64"
>>>
>>> I was kinda guessing x86_64 was the primary target of the developers?
>>>
>>> /me notes that he's now looked into libguestfs per Demi Marie's comments
>>> and some curiosity on the part of ngompa and i>
>>>
>>> Whatever it is that libguestfs does to stand up unprivileged fs mounts
>>> also could fit this bill. It's *really* slow to start because it takes
>>> the booted kernel, creates a largeish initramfs, boots that combo via
>>> libvirt, and then fires up a fuse server to talk to the vm kernel.
>>>
>>> I think all you'd have to do is change libguestfs to start the VM and
>>> run the fuse server inside a systemd container instead of directly from
>>> the CLI.
>>
>> The feedback I have gotten from ngompa is that libguestfs is just
>> too slow for distros to use it to mount stuff.
>
> Yes, libguestfs is /verrrry/ slow to start up.
>
>>>>>> 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.
>>>>
>>>> For the security / isolation use cases you've described, is
>>>> near-native performance a hard requirement?
>>>
>>> Not a hard requirement, just a means to convince people that they can
>>> choose containment without completely collapsing performance.
>>>
>>>> As I understand it, the main use cases of this will be for mounting
>>>> untrusted disk images and CI/filesystem testing, or are there broader
>>>> use cases beyond this?
>>>
>>> That covers nearly all of it.
>>
>> It's worth noting that on ChromeOS and Android, the only trusted
>> disk images are those that are read-only and protected by dm-verity.
>> *Every* writable image is considered untrusted.
>>
>> I don't know if doing a full fsck at each boot is considered
>> acceptable, but I suspect it would slow boot far too much.
>
> Not to mention that an attacker who gained control of the boot process
> could inject malicious filesystem metadata after fsck completes
> successfully but before the kernel mount occurs.
>
>> Yes, Google ought to be paying for the kernel changes to fix this mess.
>>
>>>>> 3> lklfuse hasn't been updated since 6.6.
>>>>
>>>> Gotcha. So if I'm understanding it correctly, the pros/cons come down to:
>>>> lklfuse pros:
>>>> - (arguably) easier setup cost. once it's setup (assuming it's
>>>> possible to add support for the vmapped kernel memory thing you
>>>> mentioned above), it'll automatically work for every filesystem vs.
>>>> having to implement a fuse-iomap server for every filesystem
>>>
>>> Or even a good non-iomap fuse server for every filesystem. Admittedly
>>> the weak part of fuse4fs is that libext2fs is not as robust as the
>>> kernel is.
>>>
>>>> - easier to maintain vs. having to maintain each filesystem's
>>>> userspace server implementation
>>>
>>> Yeah.
>>>
>>>> lklfuse cons:
>>>> - worse (not sure by how much) performance
>>>
>>> Probably a lot, because now you have to run a full IO stack all the way
>>> through lklfuse.
>>
>> How much is "a lot"? Is it "this is only useful for non-interactive
>> overnight backups", "you will notice this in benchmarks but it's okay
>> for normal use", or somewhere in between?
>
> Startup is painfully slow. Normal operation isn't noticeably bad, but I
> didn't bother doing any performance comparisons.
>
>> Could lklfuse and iomap be combined?
>
> Probably, though you'd have to find a way to route the FUSE_IOMAP_*
> requests to a filesystem driver. That's upside-down of the current
> iomap model where filesystems have to opt into using iomap on a
> per-IO-path basis, and then iomap calls the filesystem to find mappings.
If it does get done it would be awesome. I don't think I'll be able to
contribute, though.
>>>> - once it's merged into the kernel, we can't choose to not
>>>> maintain/support it in the future
>>>
>>> Correct.
>>>
>>>> Am I understanding this correctly?
>>>>
>>>> In my opinion, if near-native performance is not a hard requirement,
>>>> it seems like less pain overall to go with lklfuse. lklfuse seems a
>>>> lot easier to maintain and I'm not sure if some complexities like
>>>> btrfs's copy-on-write could be handled properly with fuse-iomap.
>>>
>>> btrfs cow can be done with iomap, at least on the directio end. It's
>>> the other features like fsverity/fscrypt/data checksumming that aren't
>>> currently supported by iomap.
>>
>> Pretty much everyone on btrfs uses data checksumming.
>>
>>>> What are your thoughts on this?
>>>
>>> "Gee, what if I could simplify most of my own work out of existence?"
>>
>> What is that work?
>
> Everything I've put out since the end of online fsck for xfs.
Is pretty much all of that work either on better FUSE performance or
fixes for problems found by fuzzers?
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCHBLIZZARD v7] fuse/libfuse/e2fsprogs: containerize ext4 for safer operation
From: Darrick J. Wong @ 2026-03-18 21:31 UTC (permalink / raw)
To: Demi Marie Obenour
Cc: Joanne Koong, linux-fsdevel, bpf, linux-ext4, Miklos Szeredi,
Bernd Schubert, Theodore Ts'o, Neal Gompa, Amir Goldstein,
Christian Brauner, Jeff Layton, John
In-Reply-To: <208bfbd2-d671-462c-925f-4d51b7df1f18@gmail.com>
On Mon, Mar 16, 2026 at 08:20:29PM -0400, Demi Marie Obenour wrote:
> On 3/16/26 19:41, Darrick J. Wong wrote:
> > On Mon, Mar 16, 2026 at 04:08:55PM -0700, Joanne Koong wrote:
> >> On Mon, Mar 16, 2026 at 11:04 AM Darrick J. Wong <djwong@kernel.org> wrote:
> >>>
> >>> 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
> >>
> >> Gotcha, so it would basically be having to port this arch/lkl
> >> directory [1] into the linux tree
> >
> > Right.
> >
> >>> user-mode-linux to work anywhere other than x86.
> >>
> >> Are lklfuse and user-mode-linux (UML) two separate things or is
> >> lklfuse dependent on user-mode-linux?
> >
> > I was under the impression that lklfuse uses UML. Given the weird
> > things in arch/lkl/Kconfig:
> >
> > config 64BIT
> > bool "64bit kernel"
> > default y if OUTPUT_FORMAT = "pe-x86-64"
> > default $(success,$(srctree)/arch/lkl/scripts/cc-objdump-file-format.sh|grep -q '^elf64-') if OUTPUT_FORMAT != "pe-x86-64"
> >
> > I was kinda guessing x86_64 was the primary target of the developers?
> >
> > /me notes that he's now looked into libguestfs per Demi Marie's comments
> > and some curiosity on the part of ngompa and i>
> >
> > Whatever it is that libguestfs does to stand up unprivileged fs mounts
> > also could fit this bill. It's *really* slow to start because it takes
> > the booted kernel, creates a largeish initramfs, boots that combo via
> > libvirt, and then fires up a fuse server to talk to the vm kernel.
> >
> > I think all you'd have to do is change libguestfs to start the VM and
> > run the fuse server inside a systemd container instead of directly from
> > the CLI.
>
> The feedback I have gotten from ngompa is that libguestfs is just
> too slow for distros to use it to mount stuff.
Yes, libguestfs is /verrrry/ slow to start up.
> >>>> 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.
> >>
> >> For the security / isolation use cases you've described, is
> >> near-native performance a hard requirement?
> >
> > Not a hard requirement, just a means to convince people that they can
> > choose containment without completely collapsing performance.
> >
> >> As I understand it, the main use cases of this will be for mounting
> >> untrusted disk images and CI/filesystem testing, or are there broader
> >> use cases beyond this?
> >
> > That covers nearly all of it.
>
> It's worth noting that on ChromeOS and Android, the only trusted
> disk images are those that are read-only and protected by dm-verity.
> *Every* writable image is considered untrusted.
>
> I don't know if doing a full fsck at each boot is considered
> acceptable, but I suspect it would slow boot far too much.
Not to mention that an attacker who gained control of the boot process
could inject malicious filesystem metadata after fsck completes
successfully but before the kernel mount occurs.
> Yes, Google ought to be paying for the kernel changes to fix this mess.
>
> >>> 3> lklfuse hasn't been updated since 6.6.
> >>
> >> Gotcha. So if I'm understanding it correctly, the pros/cons come down to:
> >> lklfuse pros:
> >> - (arguably) easier setup cost. once it's setup (assuming it's
> >> possible to add support for the vmapped kernel memory thing you
> >> mentioned above), it'll automatically work for every filesystem vs.
> >> having to implement a fuse-iomap server for every filesystem
> >
> > Or even a good non-iomap fuse server for every filesystem. Admittedly
> > the weak part of fuse4fs is that libext2fs is not as robust as the
> > kernel is.
> >
> >> - easier to maintain vs. having to maintain each filesystem's
> >> userspace server implementation
> >
> > Yeah.
> >
> >> lklfuse cons:
> >> - worse (not sure by how much) performance
> >
> > Probably a lot, because now you have to run a full IO stack all the way
> > through lklfuse.
>
> How much is "a lot"? Is it "this is only useful for non-interactive
> overnight backups", "you will notice this in benchmarks but it's okay
> for normal use", or somewhere in between?
Startup is painfully slow. Normal operation isn't noticeably bad, but I
didn't bother doing any performance comparisons.
> Could lklfuse and iomap be combined?
Probably, though you'd have to find a way to route the FUSE_IOMAP_*
requests to a filesystem driver. That's upside-down of the current
iomap model where filesystems have to opt into using iomap on a
per-IO-path basis, and then iomap calls the filesystem to find mappings.
> >> - once it's merged into the kernel, we can't choose to not
> >> maintain/support it in the future
> >
> > Correct.
> >
> >> Am I understanding this correctly?
> >>
> >> In my opinion, if near-native performance is not a hard requirement,
> >> it seems like less pain overall to go with lklfuse. lklfuse seems a
> >> lot easier to maintain and I'm not sure if some complexities like
> >> btrfs's copy-on-write could be handled properly with fuse-iomap.
> >
> > btrfs cow can be done with iomap, at least on the directio end. It's
> > the other features like fsverity/fscrypt/data checksumming that aren't
> > currently supported by iomap.
>
> Pretty much everyone on btrfs uses data checksumming.
>
> >> What are your thoughts on this?
> >
> > "Gee, what if I could simplify most of my own work out of existence?"
>
> What is that work?
Everything I've put out since the end of online fsck for xfs.
--D
>
> > --D
> >
> >> Thanks,
> >> Joanne
> >>
> >> [1] https://github.com/lkl/linux/tree/master/arch/lkl
> >>
> >>>
> >>> --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
> >>
>
>
> --
> Sincerely,
> Demi Marie Obenour (she/her/hers)
^ permalink raw reply
* Re: [PATCH 3/3] ext4: move dcache manipulation out of __ext4_link()
From: Jan Kara @ 2026-03-18 18:03 UTC (permalink / raw)
To: NeilBrown
Cc: Theodore Ts'o, Andreas Dilger, Jan Kara, linux-ext4,
linux-fsdevel
In-Reply-To: <20260317224638.3809014-4-neilb@ownmail.net>
On Wed 18-03-26 09:39:51, NeilBrown wrote:
> From: NeilBrown <neil@brown.name>
>
> __ext4_link() has two callers.
>
> - ext4_link() calls it during normal handling of the link() system
> call or similar
> - ext4_fc_replay_link_internal() calls it when replaying the journal
> at mount time.
>
> The former needs changes to dcache - instaniating the dentry to the
^^ instantiating
> inode on success. The latter doesn't need or want any dcache
> manipluation.
^^ manipulation
> So move the manipulation out of __ext4_link() and do it in ext4_link()
> only.
>
> This requires:
> - passing the qname from the dentry explicitly to __ext4_link.
> The parent dir is already passed. The dentry is still passed
> in the ext4_link() case purely for use by ext4_fc_track_link().
> - passing the inode separately to ext4_fc_track_link() as the
> dentry will not be instantiated yet.
> - using __ext4_add_entry() in ext4_link, which doesn't need a dentry.
> - moving ext4_inc_count(), ihold)(, d_instantiate(), drop_nlink() and
> iput() calls out of __ext4_link() into ext4_link().
>
> This substantially simplifies ext4_fc_replay_link_internal(), and
> removes a use of d_alloc() which, it is planned, will be removed.
>
> Signed-off-by: NeilBrown <neil@brown.name>
Looks good to me! Feel free to add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> fs/ext4/ext4.h | 5 +++--
> fs/ext4/fast_commit.c | 32 ++++----------------------------
> fs/ext4/namei.c | 25 ++++++++++++++-----------
> 3 files changed, 21 insertions(+), 41 deletions(-)
>
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index 293f698b7042..e757e9cf9728 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -2974,7 +2974,8 @@ void __ext4_fc_track_unlink(handle_t *handle, struct inode *inode,
> void __ext4_fc_track_link(handle_t *handle, struct inode *inode,
> struct dentry *dentry);
> void ext4_fc_track_unlink(handle_t *handle, struct dentry *dentry);
> -void ext4_fc_track_link(handle_t *handle, struct dentry *dentry);
> +void ext4_fc_track_link(handle_t *handle, struct inode *inode,
> + struct dentry *dentry);
> void __ext4_fc_track_create(handle_t *handle, struct inode *inode,
> struct dentry *dentry);
> void ext4_fc_track_create(handle_t *handle, struct dentry *dentry);
> @@ -3719,7 +3720,7 @@ extern int ext4_handle_dirty_dirblock(handle_t *handle, struct inode *inode,
> extern int __ext4_unlink(struct inode *dir, const struct qstr *d_name,
> struct inode *inode, struct dentry *dentry);
> extern int __ext4_link(struct inode *dir, struct inode *inode,
> - struct dentry *dentry);
> + const struct qstr *d_name, struct dentry *dentry);
>
> #define S_SHIFT 12
> static const unsigned char ext4_type_by_mode[(S_IFMT >> S_SHIFT) + 1] = {
> diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c
> index 3ee302b73f45..175dda11f377 100644
> --- a/fs/ext4/fast_commit.c
> +++ b/fs/ext4/fast_commit.c
> @@ -497,10 +497,9 @@ void __ext4_fc_track_link(handle_t *handle,
> trace_ext4_fc_track_link(handle, inode, dentry, ret);
> }
>
> -void ext4_fc_track_link(handle_t *handle, struct dentry *dentry)
> +void ext4_fc_track_link(handle_t *handle, struct inode *inode,
> + struct dentry *dentry)
> {
> - struct inode *inode = d_inode(dentry);
> -
> if (ext4_fc_eligible(inode->i_sb))
> __ext4_fc_track_link(handle, inode, dentry);
> }
> @@ -1431,7 +1430,6 @@ static int ext4_fc_replay_link_internal(struct super_block *sb,
> struct inode *inode)
> {
> struct inode *dir = NULL;
> - struct dentry *dentry_dir = NULL, *dentry_inode = NULL;
> struct qstr qstr_dname = QSTR_INIT(darg->dname, darg->dname_len);
> int ret = 0;
>
> @@ -1442,21 +1440,7 @@ static int ext4_fc_replay_link_internal(struct super_block *sb,
> goto out;
> }
>
> - dentry_dir = d_obtain_alias(dir);
> - if (IS_ERR(dentry_dir)) {
> - ext4_debug("Failed to obtain dentry");
> - dentry_dir = NULL;
> - goto out;
> - }
> -
> - dentry_inode = d_alloc(dentry_dir, &qstr_dname);
> - if (!dentry_inode) {
> - ext4_debug("Inode dentry not created.");
> - ret = -ENOMEM;
> - goto out;
> - }
> -
> - ret = __ext4_link(dir, inode, dentry_inode);
> + ret = __ext4_link(dir, inode, &qstr_dname, NULL);
> /*
> * It's possible that link already existed since data blocks
> * for the dir in question got persisted before we crashed OR
> @@ -1470,16 +1454,8 @@ static int ext4_fc_replay_link_internal(struct super_block *sb,
>
> ret = 0;
> out:
> - if (dentry_dir) {
> - d_drop(dentry_dir);
> - dput(dentry_dir);
> - } else if (dir) {
> + if (dir)
> iput(dir);
> - }
> - if (dentry_inode) {
> - d_drop(dentry_inode);
> - dput(dentry_inode);
> - }
>
> return ret;
> }
> diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
> index 768036a109d7..23942320c515 100644
> --- a/fs/ext4/namei.c
> +++ b/fs/ext4/namei.c
> @@ -3452,7 +3452,8 @@ static int ext4_symlink(struct mnt_idmap *idmap, struct inode *dir,
> return err;
> }
>
> -int __ext4_link(struct inode *dir, struct inode *inode, struct dentry *dentry)
> +int __ext4_link(struct inode *dir, struct inode *inode,
> + const struct qstr *d_name, struct dentry *dentry)
> {
> handle_t *handle;
> int err, retries = 0;
> @@ -3467,10 +3468,8 @@ int __ext4_link(struct inode *dir, struct inode *inode, struct dentry *dentry)
> ext4_handle_sync(handle);
>
> inode_set_ctime_current(inode);
> - ext4_inc_count(inode);
> - ihold(inode);
>
> - err = ext4_add_entry(handle, dentry, inode);
> + err = __ext4_add_entry(handle, dir, d_name, inode);
> if (!err) {
> err = ext4_mark_inode_dirty(handle, inode);
> /* this can happen only for tmpfile being
> @@ -3478,11 +3477,8 @@ int __ext4_link(struct inode *dir, struct inode *inode, struct dentry *dentry)
> */
> if (inode->i_nlink == 1)
> ext4_orphan_del(handle, inode);
> - d_instantiate(dentry, inode);
> - ext4_fc_track_link(handle, dentry);
> - } else {
> - drop_nlink(inode);
> - iput(inode);
> + if (dentry)
> + ext4_fc_track_link(handle, inode, dentry);
> }
> ext4_journal_stop(handle);
> if (err == -ENOSPC && ext4_should_retry_alloc(dir->i_sb, &retries))
> @@ -3511,9 +3507,16 @@ static int ext4_link(struct dentry *old_dentry,
> err = dquot_initialize(dir);
> if (err)
> return err;
> - return __ext4_link(dir, inode, dentry);
> + ext4_inc_count(inode);
> + err = __ext4_link(dir, inode, &dentry->d_name, dentry);
> + if (!err) {
> + ihold(inode);
> + d_instantiate(dentry, inode);
> + } else {
> + drop_nlink(inode);
> + }
> + return err;
> }
> -
> /*
> * Try to find buffer head where contains the parent block.
> * It should be the inode block if it is inlined or the 1st block
> --
> 2.50.0.107.gf914562f5916.dirty
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH 2/3] ext4: add ext4_fc_eligible()
From: Jan Kara @ 2026-03-18 17:57 UTC (permalink / raw)
To: NeilBrown
Cc: Theodore Ts'o, Andreas Dilger, Jan Kara, linux-ext4,
linux-fsdevel
In-Reply-To: <20260317224638.3809014-3-neilb@ownmail.net>
On Wed 18-03-26 09:39:50, NeilBrown wrote:
> From: NeilBrown <neil@brown.name>
>
> Testing EXT4_MF_FC_INELIGIBLE is almost always combined with testing
> ext4_fc_disabled(). The code can be simplified by combining these two
> in a new ext4_fc_eligible().
>
> In ext4_fc_track_inode() this moves the ext4_fc_disabled() test after
> ext4_fc_mark_ineligible(), but as that is a non-op when
> ext4_fc_disabled() is true, this is no no consequence.
>
> Signed-off-by: NeilBrown <neil@brown.name>
One nit below, otherwise feel free to add:
Reviewed-by: Jan Kara <jack@suse.cz>
> @@ -557,16 +548,13 @@ void ext4_fc_track_inode(handle_t *handle, struct inode *inode)
> if (S_ISDIR(inode->i_mode))
> return;
>
> - if (ext4_fc_disabled(inode->i_sb))
> - return;
> -
> if (ext4_should_journal_data(inode)) {
> ext4_fc_mark_ineligible(inode->i_sb,
> EXT4_FC_REASON_INODE_JOURNAL_DATA, handle);
> return;
> }
>
> - if (ext4_test_mount_flag(inode->i_sb, EXT4_MF_FC_INELIGIBLE))
> + if (!ext4_fc_eligible(inode->i_sb))
> return;
Here I think the !ext4_fc_eligible() check could be actually above the
ext4_should_journal_data() check - if the fs is not eligible for
fastcommit, there's no point in marking it ineligible again...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH 1/3] ext4: split __ext4_add_entry() out of ext4_add_entry()
From: Jan Kara @ 2026-03-18 17:56 UTC (permalink / raw)
To: NeilBrown
Cc: Theodore Ts'o, Andreas Dilger, Jan Kara, linux-ext4,
linux-fsdevel
In-Reply-To: <20260317224638.3809014-2-neilb@ownmail.net>
On Wed 18-03-26 09:39:49, NeilBrown wrote:
> From: NeilBrown <neil@brown.name>
>
> __ext4_add_entry() is not given a dentry - just inodes and name.
> This will help the next patch which simplifies __ex4_link().
>
> Signed-off-by: NeilBrown <neil@brown.name>
Looks good. Feel free to add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> fs/ext4/namei.c | 21 ++++++++++++++-------
> 1 file changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
> index c4b5e252af0e..768036a109d7 100644
> --- a/fs/ext4/namei.c
> +++ b/fs/ext4/namei.c
> @@ -2353,10 +2353,10 @@ static int make_indexed_dir(handle_t *handle, struct ext4_filename *fname,
> * may not sleep between calling this and putting something into
> * the entry, as someone else might have used it while you slept.
> */
> -static int ext4_add_entry(handle_t *handle, struct dentry *dentry,
> +static int __ext4_add_entry(handle_t *handle, struct inode *dir,
> + const struct qstr *d_name,
> struct inode *inode)
> {
> - struct inode *dir = d_inode(dentry->d_parent);
> struct buffer_head *bh = NULL;
> struct ext4_dir_entry_2 *de;
> struct super_block *sb;
> @@ -2373,13 +2373,10 @@ static int ext4_add_entry(handle_t *handle, struct dentry *dentry,
> sb = dir->i_sb;
> blocksize = sb->s_blocksize;
>
> - if (fscrypt_is_nokey_name(dentry))
> - return -ENOKEY;
> -
> - if (!generic_ci_validate_strict_name(dir, &dentry->d_name))
> + if (!generic_ci_validate_strict_name(dir, d_name))
> return -EINVAL;
>
> - retval = ext4_fname_setup_filename(dir, &dentry->d_name, 0, &fname);
> + retval = ext4_fname_setup_filename(dir, d_name, 0, &fname);
> if (retval)
> return retval;
>
> @@ -2460,6 +2457,16 @@ static int ext4_add_entry(handle_t *handle, struct dentry *dentry,
> return retval;
> }
>
> +static int ext4_add_entry(handle_t *handle, struct dentry *dentry,
> + struct inode *inode)
> +{
> + struct inode *dir = d_inode(dentry->d_parent);
> +
> + if (fscrypt_is_nokey_name(dentry))
> + return -ENOKEY;
> + return __ext4_add_entry(handle, dir, &dentry->d_name, inode);
> +}
> +
> /*
> * Returns 0 for success, or a negative error value
> */
> --
> 2.50.0.107.gf914562f5916.dirty
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ 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