* Re: [PATCH] loop: block loop reconfiguration of offset/sizelimit on mounted device
From: Theodore Tso @ 2026-03-30 19:00 UTC (permalink / raw)
To: Deepanshu Kartikey
Cc: Christoph Hellwig, axboe, dvyukov, adilger.kernel, linux-block,
linux-kernel, linux-ext4, syzbot+fb32afec111a7d61b939
In-Reply-To: <CADhLXY6Cu+O_jeL9xxORtLg-LU6pdBxFb29yhS=d2rTtgbA2tw@mail.gmail.com>
On Mon, Mar 30, 2026 at 08:03:55PM +0530, Deepanshu Kartikey wrote:
>
> The check would be:
>
> #ifndef CONFIG_BLK_DEV_WRITE_MOUNTED
> if ((lo->lo_offset != info->lo_offset ||
> lo->lo_sizelimit != info->lo_sizelimit) &&
> lo->lo_device->bd_writers < 0) {
> err = -EBUSY;
> goto out_unlock;
> }
> #endif
Can you please move bdev_writes_blocked() into
include/linux/blk_types.h as an inline function as Christoph
suggested?
The reason for that is that "bdev_writers < 0" is an implementation
detail and it might change in the future, and then loop driver might
break unexpectedly. Using bdev_writes_blocked() is also much clearer
from a code readability perspective.
> Regarding Christoph's point about increasing lo_sizelimit being
> safe - should I narrow the check to only block shrinking and
> offset changes?
Yes, I think we should allow the loop device to grow, since that's
harmless and there are some legitimate use cases when people might
want to do this and then trigger an online resize so the file system
grows to use the added space.
- Ted
^ permalink raw reply
* [PATCH] ext4: fix missing brelse() in ext4_xattr_inode_dec_ref_all()
From: skoyama.kernel @ 2026-03-30 17:42 UTC (permalink / raw)
To: linux-ext4; +Cc: Sohei Koyama
From: Sohei Koyama <skoyama@ddn.com>
The commit c8e008b60492 ("ext4: ignore xattrs past end")
introduced a refcount leak in when block_csum is false.
ext4_xattr_inode_dec_ref_all() calls ext4_get_inode_loc() to
get iloc.bh, but never releases it with brelse().
Fixes: c8e008b60492 ("ext4: ignore xattrs past end")
Signed-off-by: Sohei Koyama <skoyama@ddn.com>
---
fs/ext4/xattr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 7bf9ba19a89d..19c72e38fb82 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -1165,7 +1165,7 @@ ext4_xattr_inode_dec_ref_all(handle_t *handle, struct inode *parent,
{
struct inode *ea_inode;
struct ext4_xattr_entry *entry;
- struct ext4_iloc iloc;
+ struct ext4_iloc iloc = { .bh = NULL };
bool dirty = false;
unsigned int ea_ino;
int err;
@@ -1260,6 +1260,8 @@ ext4_xattr_inode_dec_ref_all(handle_t *handle, struct inode *parent,
ext4_warning_inode(parent,
"handle dirty metadata err=%d", err);
}
+
+ brelse(iloc.bh);
}
/*
--
2.39.3 (Apple Git-146)
^ permalink raw reply related
* Re: [PATCH] loop: block loop reconfiguration of offset/sizelimit on mounted device
From: Deepanshu Kartikey @ 2026-03-30 14:33 UTC (permalink / raw)
To: Theodore Tso
Cc: Christoph Hellwig, axboe, dvyukov, adilger.kernel, linux-block,
linux-kernel, linux-ext4, syzbot+fb32afec111a7d61b939
In-Reply-To: <20260330133800.GC22278@macsyma.local>
On Mon, Mar 30, 2026 at 7:08 PM Theodore Tso <tytso@mit.edu> wrote:
>
> The patch was missing the...
>
> #ifndef CONFIG_BLK_DEV_WRITE_MOUNTED)
>
> ... in loop.c which was in my original sketch of a patch which I sent
> to Deepanshu.
>
> The intent was to suppress Syzkaller noise. Inherent in my assumption
> was that changing either lo_offset or lo_sizelimit parameter was going
> to mutate the loop device when it was mounted, which was the intent of
> !CONFIG_BLK_DEV_WRITE_MOUNTED. I also assumed that at least for now,
> the only user of !CONFIG_BLK_DEV_WRITE_MOUNTED was syzkaller, since
> there are file systems (in particular ext4) that are commonly in use
> whose userspace utilities fundamentally assume that you can write to
> the block device. Even after we promulgate the tune2fs changes to use
> the new EXT4_IOC_SET_TUNE_SB_PARAM ioctl and we can assume that it is
> common use in deployed kernels, some grub operations still assume they
> can modify the block device where the second-stage grub bootloader is
> located.
>
> In the long term, when ext4 can start assuming that we can suppress
> writes to the block device (and we find a solution to the grub issue),
> we'll probably want to have a way to suppress write access to block
> devices on a per-super basis, without clearing the Kconfig
> CONFIG_BLK_DEV_WRITE_MOUNTED. But that's a problem for another day...
>
> Cheers,
>
> - Ted
Hi Ted, Christoph,
Thank you both for the feedback. Based on your suggestions, I'll
submit a v2 with the following approach:
- Use #ifndef CONFIG_BLK_DEV_WRITE_MOUNTED as Ted originally
intended, since this is meant to suppress syzkaller noise
- Check bd_writers directly instead of exporting
bdev_writes_blocked(), addressing Christoph's concern
- No changes to block/bdev.c or include/linux/blkdev.h, keeping
the patch minimal and limited to drivers/block/loop.c
The check would be:
#ifndef CONFIG_BLK_DEV_WRITE_MOUNTED
if ((lo->lo_offset != info->lo_offset ||
lo->lo_sizelimit != info->lo_sizelimit) &&
lo->lo_device->bd_writers < 0) {
err = -EBUSY;
goto out_unlock;
}
#endif
Regarding Christoph's point about increasing lo_sizelimit being
safe - should I narrow the check to only block shrinking and
offset changes?
Thanks,
Deepanshu
^ permalink raw reply
* Re: [PATCH] loop: block loop reconfiguration of offset/sizelimit on mounted device
From: Theodore Tso @ 2026-03-30 13:38 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Deepanshu Kartikey, axboe, dvyukov, adilger.kernel, linux-block,
linux-kernel, linux-ext4, syzbot+fb32afec111a7d61b939
In-Reply-To: <acoQBLwdc1PqIb0m@infradead.org>
On Sun, Mar 29, 2026 at 10:54:12PM -0700, Christoph Hellwig wrote:
> On Mon, Mar 30, 2026 at 10:13:34AM +0530, Deepanshu Kartikey wrote:
> > LOOP_SET_STATUS{64} allows changing lo_offset and lo_sizelimit while
> > a filesystem is mounted on the loop device. This effectively mutates
> > the data visible to the mounted filesystem, which is equivalent to
> > writing directly to the block device.
>
> Increasing the size certainly does not do that.
>
> > Export bdev_writes_blocked() so it can be used from the loop driver.
>
> I'm not sure exporting this is a good idea. Besides the growing the
> device part above, if someone insist on changing the size, they could
> do this just fine with a remove block device, so prohibiting it locally
> just because we can seems odd. And exporting a helper with obscure
> usage for a strange use case without documenting that is rarely a
> good idea.
The patch was missing the...
#ifndef CONFIG_BLK_DEV_WRITE_MOUNTED)
... in loop.c which was in my original sketch of a patch which I sent
to Deepanshu.
The intent was to suppress Syzkaller noise. Inherent in my assumption
was that changing either lo_offset or lo_sizelimit parameter was going
to mutate the loop device when it was mounted, which was the intent of
!CONFIG_BLK_DEV_WRITE_MOUNTED. I also assumed that at least for now,
the only user of !CONFIG_BLK_DEV_WRITE_MOUNTED was syzkaller, since
there are file systems (in particular ext4) that are commonly in use
whose userspace utilities fundamentally assume that you can write to
the block device. Even after we promulgate the tune2fs changes to use
the new EXT4_IOC_SET_TUNE_SB_PARAM ioctl and we can assume that it is
common use in deployed kernels, some grub operations still assume they
can modify the block device where the second-stage grub bootloader is
located.
In the long term, when ext4 can start assuming that we can suppress
writes to the block device (and we find a solution to the grub issue),
we'll probably want to have a way to suppress write access to block
devices on a per-super basis, without clearing the Kconfig
CONFIG_BLK_DEV_WRITE_MOUNTED. But that's a problem for another day...
Cheers,
- Ted
^ permalink raw reply
* [PATCH v5 4/5] ext4: fix possible null-ptr-deref in extents_kunit_exit()
From: Ye Bin @ 2026-03-30 13:30 UTC (permalink / raw)
To: tytso, adilger.kernel, linux-ext4; +Cc: jack
In-Reply-To: <20260330133035.287842-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 4042bc8a95e2..6b53a3f39fcd 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 v5 1/5] ext4: fix miss unlock 'sb->s_umount' in extents_kunit_init()
From: Ye Bin @ 2026-03-30 13:30 UTC (permalink / raw)
To: tytso, adilger.kernel, linux-ext4; +Cc: jack
In-Reply-To: <20260330133035.287842-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 v5 3/5] ext4: fix the error handling process in extents_kunit_init).
From: Ye Bin @ 2026-03-30 13:30 UTC (permalink / raw)
To: tytso, adilger.kernel, linux-ext4; +Cc: jack
In-Reply-To: <20260330133035.287842-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>
---
fs/ext4/extents-test.c | 50 +++++++++++++++++++++++++++++-------------
1 file changed, 35 insertions(+), 15 deletions(-)
diff --git a/fs/ext4/extents-test.c b/fs/ext4/extents-test.c
index 3d4663d99eb1..4042bc8a95e2 100644
--- a/fs/ext4/extents-test.c
+++ b/fs/ext4/extents-test.c
@@ -225,34 +225,38 @@ 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;
+ err = ext4_es_register_shrinker(sbi);
+ if (err)
+ goto out_deactivate;
+
/* 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;
+ }
ei = k_ctx.k_ei;
inode = &ei->vfs_inode;
- err = ext4_es_register_shrinker(sbi);
- if (err)
- return err;
-
ext4_es_init_tree(&ei->i_es_tree);
rwlock_init(&ei->i_es_lock);
INIT_LIST_HEAD(&ei->i_es_list);
@@ -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;
+ }
/*
* 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:
+ 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);
+out_deactivate:
+ deactivate_locked_super(sb);
+ kfree(sbi);
+
+ return err;
}
/*
--
2.34.1
^ permalink raw reply related
* [PATCH v5 2/5] ext4: call deactivate_super() in extents_kunit_exit()
From: Ye Bin @ 2026-03-30 13:30 UTC (permalink / raw)
To: tytso, adilger.kernel, linux-ext4; +Cc: jack
In-Reply-To: <20260330133035.287842-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>
Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.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 v5 0/5] Fix some issues about ext4-test
From: Ye Bin @ 2026-03-30 13:30 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 v5 vs v4:
1. Patch[3]
Move ext4_es_register_shrinker() before setting up the mock inode.
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 | 60 ++++++++++++++++++++++++++++++------------
fs/ext4/mballoc-test.c | 6 ++++-
2 files changed, 48 insertions(+), 18 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH v5 5/5] ext4: fix possible null-ptr-deref in mbt_kunit_exit()
From: Ye Bin @ 2026-03-30 13:30 UTC (permalink / raw)
To: tytso, adilger.kernel, linux-ext4; +Cc: jack
In-Reply-To: <20260330133035.287842-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
* Re: [PATCH 15/42] fat: Sync and invalidate metadata buffers from fat_evict_inode()
From: OGAWA Hirofumi @ 2026-03-30 11:29 UTC (permalink / raw)
To: Jan Kara
Cc: linux-fsdevel, linux-block, Christian Brauner, Al Viro,
linux-ext4, Ted Tso, Tigran A. Aivazian, David Sterba,
Muchun Song, Oscar Salvador, David Hildenbrand, linux-mm,
linux-aio, Benjamin LaHaise
In-Reply-To: <3oh5cbnm6dwz6rikc6laably5nvu4c4wtxjqzuu3wymzhpqrtw@skopu327hd7a>
Jan Kara <jack@suse.cz> writes:
> On Sun 29-03-26 22:55:09, OGAWA Hirofumi wrote:
>> Jan Kara <jack@suse.cz> writes:
>> > There are only very few filesystems using generic metadata buffer head
>> > tracking and everybody is paying the overhead. When we remove this
>> > tracking for inode reclaim code .evict will start to see inodes with
>> > metadata buffers attached so write them out and prune them.
>> >
>> > Signed-off-by: Jan Kara <jack@suse.cz>
>> > ---
>> > fs/fat/inode.c | 4 +++-
>> > 1 file changed, 3 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/fs/fat/inode.c b/fs/fat/inode.c
>> > index 3cc5fb01afa1..ce88602b0d57 100644
>> > --- a/fs/fat/inode.c
>> > +++ b/fs/fat/inode.c
>> > @@ -657,8 +657,10 @@ static void fat_evict_inode(struct inode *inode)
>> > if (!inode->i_nlink) {
>> > inode->i_size = 0;
>> > fat_truncate_blocks(inode, 0);
>> > - } else
>> > + } else {
>> > + sync_mapping_buffers(inode->i_mapping);
>>
>> Hm, why do we have to add this here? For FAT, if buffers are still
>> dirty, buffers will be flushed via bdev flush?
>
> The reason why I've put sync_mapping_buffers() here is the following
> sequence:
> fd = open("file")
> write(fd)
> close(fd)
> - now data gets written out, dentry & inode can get evicted from memory
> fd = open("file")
> fsync(fd)
> - this should flush all dirty metadata associated with "file" but if we
> didn't call sync_mapping_buffers() during inode eviction we wouldn't
> have a way to do that.
>
> So in general I think sync_mapping_buffers() call is indeed needed.
Hm, it looks like not new issue, isn't it? Why we have changed now in
this series?
It is including trade off write amplification vs reliability (i.e. may
not call fsync()), for example. So I think we should not add it easily.
Thanks.
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
^ permalink raw reply
* Re: [PATCH 15/42] fat: Sync and invalidate metadata buffers from fat_evict_inode()
From: Jan Kara @ 2026-03-30 9:08 UTC (permalink / raw)
To: OGAWA Hirofumi
Cc: Jan Kara, linux-fsdevel, linux-block, Christian Brauner, Al Viro,
linux-ext4, Ted Tso, Tigran A. Aivazian, David Sterba,
Muchun Song, Oscar Salvador, David Hildenbrand, linux-mm,
linux-aio, Benjamin LaHaise
In-Reply-To: <87ldfazqo2.fsf@mail.parknet.co.jp>
On Sun 29-03-26 22:55:09, OGAWA Hirofumi wrote:
> Jan Kara <jack@suse.cz> writes:
> > There are only very few filesystems using generic metadata buffer head
> > tracking and everybody is paying the overhead. When we remove this
> > tracking for inode reclaim code .evict will start to see inodes with
> > metadata buffers attached so write them out and prune them.
> >
> > Signed-off-by: Jan Kara <jack@suse.cz>
> > ---
> > fs/fat/inode.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/fs/fat/inode.c b/fs/fat/inode.c
> > index 3cc5fb01afa1..ce88602b0d57 100644
> > --- a/fs/fat/inode.c
> > +++ b/fs/fat/inode.c
> > @@ -657,8 +657,10 @@ static void fat_evict_inode(struct inode *inode)
> > if (!inode->i_nlink) {
> > inode->i_size = 0;
> > fat_truncate_blocks(inode, 0);
> > - } else
> > + } else {
> > + sync_mapping_buffers(inode->i_mapping);
>
> Hm, why do we have to add this here? For FAT, if buffers are still
> dirty, buffers will be flushed via bdev flush?
The reason why I've put sync_mapping_buffers() here is the following
sequence:
fd = open("file")
write(fd)
close(fd)
- now data gets written out, dentry & inode can get evicted from memory
fd = open("file")
fsync(fd)
- this should flush all dirty metadata associated with "file" but if we
didn't call sync_mapping_buffers() during inode eviction we wouldn't
have a way to do that.
So in general I think sync_mapping_buffers() call is indeed needed.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* Re: [PATCH v4 3/5] ext4: fix the error handling process in extents_kunit_init).
From: yebin (H) @ 2026-03-30 7:02 UTC (permalink / raw)
To: Ritesh Harjani, Ye Bin, tytso, adilger.kernel, linux-ext4
Cc: jack, Ojaswin Mujoo
In-Reply-To: <ldfnxo07.ritesh.list@gmail.com>
On 2026/3/20 9:56, Ritesh Harjani 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
>>
>> Fixes: cb1e0c1d1fad ("ext4: kunit tests for extent splitting and conversion")
>> Signed-off-by: Ye Bin <yebin10@huawei.com>
>> Reviewed-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
>> Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
>> ---
>> fs/ext4/extents-test.c | 43 ++++++++++++++++++++++++++++++------------
>> 1 file changed, 31 insertions(+), 12 deletions(-)
>>
>> diff --git a/fs/ext4/extents-test.c b/fs/ext4/extents-test.c
>> index 3d4663d99eb1..4ce3f81f6409 100644
>> --- a/fs/ext4/extents-test.c
>> +++ b/fs/ext4/extents-test.c
>> @@ -225,33 +225,37 @@ static int extents_kunit_init(struct kunit *test)
>> (struct kunit_ext_test_param *)(test->param_value);
>> int err;
>>
>> - sb = sget(&ext_fs_type, NULL, ext_set, 0, NULL);
>> - if (IS_ERR(sb))
>> - return PTR_ERR(sb);
>> -
>> - sb->s_blocksize = 4096;
>> - sb->s_blocksize_bits = 12;
>> -
>> sbi = kzalloc_obj(struct ext4_sb_info);
>> if (sbi == NULL)
>> return -ENOMEM;
>>
>> + sb = sget(&ext_fs_type, NULL, ext_set, 0, NULL);
>> + if (IS_ERR(sb)) {
>> + kfree(sbi);
>> + return PTR_ERR(sb);
>> + }
>> +
>> sbi->s_sb = sb;
>> sb->s_fs_info = sbi;
>>
>> + sb->s_blocksize = 4096;
>> + sb->s_blocksize_bits = 12;
>> +
>> if (!param || !param->disable_zeroout)
>> sbi->s_extent_max_zeroout_kb = 32;
>>
>> /* setup the mock inode */
>> k_ctx.k_ei = kzalloc_obj(struct ext4_inode_info);
>> - if (k_ctx.k_ei == NULL)
>> - return -ENOMEM;
>> + if (k_ctx.k_ei == NULL) {
>> + err = -ENOMEM;
>> + goto out_deactivate;
>> + }
>> ei = k_ctx.k_ei;
>> inode = &ei->vfs_inode;
>>
>> err = ext4_es_register_shrinker(sbi);
>> if (err)
>> - return err;
>> + goto out_deactivate;
>
> Even though the patch looks ok, but still wanted to check if ...
>
> Do you think we can move ext4_es_register_shrinker() before setting up
> the mock inode and on error we simply return err?
> That way, there won't be any ambiguity in the error handling for calling
> ext4_es_unregister_shrinker()?
Sorry, I've been a bit busy lately. The idea is good, and I will send a
new version of the patch.
>
>>
>> ext4_es_init_tree(&ei->i_es_tree);
>> rwlock_init(&ei->i_es_lock);
>> @@ -267,8 +271,10 @@ static int extents_kunit_init(struct kunit *test)
>> inode->i_sb = sb;
>>
>> k_ctx.k_data = kzalloc(EXT_DATA_LEN * 4096, GFP_KERNEL);
>> - if (k_ctx.k_data == NULL)
>> - return -ENOMEM;
>> + if (k_ctx.k_data == NULL) {
>> + err = -ENOMEM;
>> + goto out_deactivate;
>> + }
>>
>> /*
>> * set the data area to a junk value
>> @@ -313,6 +319,19 @@ static int extents_kunit_init(struct kunit *test)
>> up_write(&sb->s_umount);
>>
>> return 0;
>> +
>> +out_deactivate:
>> + kfree(k_ctx.k_ei);
>> + k_ctx.k_ei = NULL;
>> +
>> + kfree(k_ctx.k_data);
>> + k_ctx.k_data = NULL;
>> +
>> + ext4_es_unregister_shrinker(sbi);
>
> -ritesh
>
>
> .
>
^ permalink raw reply
* Re: [PATCH] loop: block loop reconfiguration of offset/sizelimit on mounted device
From: Christoph Hellwig @ 2026-03-30 5:54 UTC (permalink / raw)
To: Deepanshu Kartikey
Cc: axboe, tytso, dvyukov, adilger.kernel, linux-block, linux-kernel,
linux-ext4, syzbot+fb32afec111a7d61b939
In-Reply-To: <20260330044334.373480-1-kartikey406@gmail.com>
On Mon, Mar 30, 2026 at 10:13:34AM +0530, Deepanshu Kartikey wrote:
> LOOP_SET_STATUS{64} allows changing lo_offset and lo_sizelimit while
> a filesystem is mounted on the loop device. This effectively mutates
> the data visible to the mounted filesystem, which is equivalent to
> writing directly to the block device.
Increasing the size certainly does not do that.
> Export bdev_writes_blocked() so it can be used from the loop driver.
I'm not sure exporting this is a good idea. Besides the growing the
device part above, if someone insist on changing the size, they could
do this just fine with a remove block device, so prohibiting it locally
just because we can seems odd. And exporting a helper with obscure
usage for a strange use case without documenting that is rarely a
good idea.
> -static bool bdev_writes_blocked(struct block_device *bdev)
> +bool bdev_writes_blocked(struct block_device *bdev)
> {
> return bdev->bd_writers < 0;
> }
> +EXPORT_SYMBOL_GPL(bdev_writes_blocked);
> +
>
> static void bdev_block_writes(struct block_device *bdev)
... and if we were to make it public it should be inline, and in a
separate patch.
And if not this would still add a spurious empty line.
^ permalink raw reply
* Re: SYZKALLER BUG: messing with a mounted file system via loop ioctls (was: Re: [PATCH] ext4: add bounds check in ext4_xattr_ibody_get() to) prevent out-of-bounds access
From: Deepanshu Kartikey @ 2026-03-30 4:44 UTC (permalink / raw)
To: Theodore Tso
Cc: Dmitry Vyukov, syzkaller, adilger.kernel, linux-ext4,
linux-kernel, syzbot+fb32afec111a7d61b939
In-Reply-To: <20260329134832.GA8782@Mac>
On Sun, Mar 29, 2026 at 7:18 PM Theodore Tso <tytso@mit.edu> wrote:
>
> The fix is something like:
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index 0000913f7efc..c1d17e2bbd0c 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -1238,6 +1238,16 @@ loop_set_status(struct loop_device *lo, const struct loop_info64 *info)
> err = -ENXIO;
> goto out_unlock;
> }
> +#ifndef CONFIG_BLK_DEV_WRITE_MOUNTED)
> + /*
> + * bdev_writes_blocked is a static function defiend in
> + * block/bdev.c, so this won't work as-is.
> + */
> + if (bdev_writes_blocked(lo->lo_device)) {
> + err = -EBUSY;
> + goto out_unlock;
> + }
> +#endif
>
> if (lo->lo_offset != info->lo_offset ||
> lo->lo_sizelimit != info->lo_sizelimit) {
>
> Turning this into a real patch that exports bdev_writes_blocked() is
> left as an exercise to the reader.
>
> - Ted
I have sent the patch
Thanks
Deepanshu
^ permalink raw reply
* [PATCH] loop: block loop reconfiguration of offset/sizelimit on mounted device
From: Deepanshu Kartikey @ 2026-03-30 4:43 UTC (permalink / raw)
To: axboe, tytso, dvyukov
Cc: adilger.kernel, linux-block, linux-kernel, linux-ext4,
Deepanshu Kartikey, syzbot+fb32afec111a7d61b939
LOOP_SET_STATUS{64} allows changing lo_offset and lo_sizelimit while
a filesystem is mounted on the loop device. This effectively mutates
the data visible to the mounted filesystem, which is equivalent to
writing directly to the block device.
When bdev_allow_write_mounted is false, direct writes to a mounted
block device are blocked via bdev_writes_blocked(). However,
LOOP_SET_STATUS{64} bypasses this protection because it modifies
the loop configuration through an ioctl rather than opening the
block device for writing.
Fix this by checking bdev_writes_blocked() before allowing changes
to lo_offset or lo_sizelimit. If the loop device has writes blocked
(indicating a filesystem is mounted with write protection), return
-EBUSY. Other loop status fields that do not affect the visible
data can still be changed while mounted.
Export bdev_writes_blocked() so it can be used from the loop driver.
Suggested-by: Theodore Ts'o <tytso@mit.edu>
Reported-by: syzbot+fb32afec111a7d61b939@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=fb32afec111a7d61b939
Tested-by: syzbot+fb32afec111a7d61b939@syzkaller.appspotmail.com
Signed-off-by: Deepanshu Kartikey <kartikey406@gmail.com>
---
block/bdev.c | 4 +++-
drivers/block/loop.c | 12 ++++++++++++
include/linux/blkdev.h | 1 +
3 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/block/bdev.c b/block/bdev.c
index ed022f8c48c7..96520fac7b2f 100644
--- a/block/bdev.c
+++ b/block/bdev.c
@@ -860,10 +860,12 @@ void blkdev_put_no_open(struct block_device *bdev)
put_device(&bdev->bd_device);
}
-static bool bdev_writes_blocked(struct block_device *bdev)
+bool bdev_writes_blocked(struct block_device *bdev)
{
return bdev->bd_writers < 0;
}
+EXPORT_SYMBOL_GPL(bdev_writes_blocked);
+
static void bdev_block_writes(struct block_device *bdev)
{
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 0000913f7efc..3f3a29abad1f 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1239,6 +1239,18 @@ loop_set_status(struct loop_device *lo, const struct loop_info64 *info)
goto out_unlock;
}
+ /*
+ * Changing lo_offset or lo_sizelimit on a mounted device is
+ * equivalent to modifying the block device contents, block
+ * this if writes are blocked on the device.
+ */
+ if ((lo->lo_offset != info->lo_offset ||
+ lo->lo_sizelimit != info->lo_sizelimit) &&
+ bdev_writes_blocked(lo->lo_device)) {
+ err = -EBUSY;
+ goto out_unlock;
+ }
+
if (lo->lo_offset != info->lo_offset ||
lo->lo_sizelimit != info->lo_sizelimit) {
size_changed = true;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index d463b9b5a0a5..6b908e9dd035 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -820,6 +820,7 @@ static inline bool bdev_read_only(struct block_device *bdev)
return bdev_test_flag(bdev, BD_READ_ONLY) || get_disk_ro(bdev->bd_disk);
}
+bool bdev_writes_blocked(struct block_device *bdev);
bool set_capacity_and_notify(struct gendisk *disk, sector_t size);
void disk_force_media_change(struct gendisk *disk);
void bdev_mark_dead(struct block_device *bdev, bool surprise);
--
2.43.0
^ permalink raw reply related
* Re: SYZKALLER BUG: messing with a mounted file system via loop ioctls (was: Re: [PATCH] ext4: add bounds check in ext4_xattr_ibody_get() to) prevent out-of-bounds access
From: Theodore Tso @ 2026-03-29 17:06 UTC (permalink / raw)
To: Deepanshu Kartikey
Cc: Dmitry Vyukov, syzkaller, adilger.kernel, linux-ext4,
linux-kernel, syzbot+fb32afec111a7d61b939
In-Reply-To: <CADhLXY6uiBk1KTBH7M5Zjfy5RU3nPqaYaOD7FsQWGTwgfdi4Gg@mail.gmail.com>
On Sun, Mar 29, 2026 at 08:09:00PM +0530, Deepanshu Kartikey wrote:
>
> Thanks for the sketch. I'll look into turning this into a proper
> patch, exporting bdev_writes_blocked() and fixing up the
> LOOP_SET_STATUS path.
Thank you! Much appreciated!!
- Ted
^ permalink raw reply
* Re: [GIT PULL] ext4 fixes for 7.0-rc6
From: pr-tracker-bot @ 2026-03-29 16:42 UTC (permalink / raw)
To: Theodore Tso
Cc: Linus Torvalds, Ext4 Developers List,
Linux Kernel Developers List
In-Reply-To: <20260329045741.GA9694@Mac>
The pull request you sent on Sat, 28 Mar 2026 23:57:41 -0500:
> https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus-7.0-rc6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/241d4ca15de9bf2cc04bdec466a6a2b0bd5dbc19
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: SYZKALLER BUG: messing with a mounted file system via loop ioctls (was: Re: [PATCH] ext4: add bounds check in ext4_xattr_ibody_get() to) prevent out-of-bounds access
From: Deepanshu Kartikey @ 2026-03-29 14:39 UTC (permalink / raw)
To: Theodore Tso, Dmitry Vyukov
Cc: syzkaller, adilger.kernel, linux-ext4, linux-kernel,
syzbot+fb32afec111a7d61b939
In-Reply-To: <20260329134832.GA8782@Mac>
On Sun, Mar 29, 2026 at 7:18 PM Theodore Tso <tytso@mit.edu> wrote:
>
> On Sun, Mar 29, 2026 at 11:47:44AM +0200, Dmitry Vyukov wrote:
> > Thanks for the report.
> >
> > https://syzkaller.appspot.com/text?tag=ReproSyz&x=17a43b3a580000
> >
> > Do you mean LOOP_SET_STATUS64 ioctl? It's the only ioctl in the repro:
> >
> > ioctl$LOOP_SET_STATUS64(r0, 0x4c04, ...)
>
> The loop LOOP_SET_STATUS ioctl is also problematic.
>
> > Does it mean it should also be prohibited under
> > CONFIG_BLK_DEV_WRITE_MOUNTED to avoid kernel memory corruption?
> > Or at least some changes should be prohibited? E.g. I guess changing
> > lo_offset is equivalent to writing to the mounted device.
>
> Yes, that's correct. LOOP_SET_STATUS[64] can set lo_offset and
> lo_sizelimit which effectively mutates the loop device while it is
> mounted.
>
> The fix is something like:
>
> diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> index 0000913f7efc..c1d17e2bbd0c 100644
> --- a/drivers/block/loop.c
> +++ b/drivers/block/loop.c
> @@ -1238,6 +1238,16 @@ loop_set_status(struct loop_device *lo, const struct loop_info64 *info)
> err = -ENXIO;
> goto out_unlock;
> }
> +#ifndef CONFIG_BLK_DEV_WRITE_MOUNTED)
> + /*
> + * bdev_writes_blocked is a static function defiend in
> + * block/bdev.c, so this won't work as-is.
> + */
> + if (bdev_writes_blocked(lo->lo_device)) {
> + err = -EBUSY;
> + goto out_unlock;
> + }
> +#endif
>
> if (lo->lo_offset != info->lo_offset ||
> lo->lo_sizelimit != info->lo_sizelimit) {
>
> Turning this into a real patch that exports bdev_writes_blocked() is
> left as an exercise to the reader.
>
> - Ted
Hi Ted and Dmitry
Thanks for the sketch. I'll look into turning this into a proper
patch, exporting bdev_writes_blocked() and fixing up the
LOOP_SET_STATUS path.
Deepanshu
^ permalink raw reply
* Re: [PATCH 15/42] fat: Sync and invalidate metadata buffers from fat_evict_inode()
From: OGAWA Hirofumi @ 2026-03-29 13:55 UTC (permalink / raw)
To: Jan Kara
Cc: linux-fsdevel, linux-block, Christian Brauner, Al Viro,
linux-ext4, Ted Tso, Tigran A. Aivazian, David Sterba,
Muchun Song, Oscar Salvador, David Hildenbrand, linux-mm,
linux-aio, Benjamin LaHaise
In-Reply-To: <20260326095354.16340-57-jack@suse.cz>
Jan Kara <jack@suse.cz> writes:
> There are only very few filesystems using generic metadata buffer head
> tracking and everybody is paying the overhead. When we remove this
> tracking for inode reclaim code .evict will start to see inodes with
> metadata buffers attached so write them out and prune them.
>
> Signed-off-by: Jan Kara <jack@suse.cz>
> ---
> fs/fat/inode.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/fs/fat/inode.c b/fs/fat/inode.c
> index 3cc5fb01afa1..ce88602b0d57 100644
> --- a/fs/fat/inode.c
> +++ b/fs/fat/inode.c
> @@ -657,8 +657,10 @@ static void fat_evict_inode(struct inode *inode)
> if (!inode->i_nlink) {
> inode->i_size = 0;
> fat_truncate_blocks(inode, 0);
> - } else
> + } else {
> + sync_mapping_buffers(inode->i_mapping);
Hm, why do we have to add this here? For FAT, if buffers are still
dirty, buffers will be flushed via bdev flush?
Thanks.
> fat_free_eofblocks(inode);
> + }
>
> invalidate_inode_buffers(inode);
> clear_inode(inode);
--
OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
^ permalink raw reply
* Re: SYZKALLER BUG: messing with a mounted file system via loop ioctls (was: Re: [PATCH] ext4: add bounds check in ext4_xattr_ibody_get() to) prevent out-of-bounds access
From: Theodore Tso @ 2026-03-29 13:48 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Deepanshu Kartikey, syzkaller, adilger.kernel, linux-ext4,
linux-kernel, syzbot+fb32afec111a7d61b939
In-Reply-To: <CACT4Y+ZzbnD_puTRMx4MpcACpp5m3aMhQYvH+1LAyTKOz6otEw@mail.gmail.com>
On Sun, Mar 29, 2026 at 11:47:44AM +0200, Dmitry Vyukov wrote:
> Thanks for the report.
>
> https://syzkaller.appspot.com/text?tag=ReproSyz&x=17a43b3a580000
>
> Do you mean LOOP_SET_STATUS64 ioctl? It's the only ioctl in the repro:
>
> ioctl$LOOP_SET_STATUS64(r0, 0x4c04, ...)
The loop LOOP_SET_STATUS ioctl is also problematic.
> Does it mean it should also be prohibited under
> CONFIG_BLK_DEV_WRITE_MOUNTED to avoid kernel memory corruption?
> Or at least some changes should be prohibited? E.g. I guess changing
> lo_offset is equivalent to writing to the mounted device.
Yes, that's correct. LOOP_SET_STATUS[64] can set lo_offset and
lo_sizelimit which effectively mutates the loop device while it is
mounted.
The fix is something like:
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 0000913f7efc..c1d17e2bbd0c 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -1238,6 +1238,16 @@ loop_set_status(struct loop_device *lo, const struct loop_info64 *info)
err = -ENXIO;
goto out_unlock;
}
+#ifndef CONFIG_BLK_DEV_WRITE_MOUNTED)
+ /*
+ * bdev_writes_blocked is a static function defiend in
+ * block/bdev.c, so this won't work as-is.
+ */
+ if (bdev_writes_blocked(lo->lo_device)) {
+ err = -EBUSY;
+ goto out_unlock;
+ }
+#endif
if (lo->lo_offset != info->lo_offset ||
lo->lo_sizelimit != info->lo_sizelimit) {
Turning this into a real patch that exports bdev_writes_blocked() is
left as an exercise to the reader.
- Ted
^ permalink raw reply related
* Re: [PATCH next] ext4: Fix diagnostic printf formats
From: Andy Shevchenko @ 2026-03-29 11:37 UTC (permalink / raw)
To: Theodore Tso
Cc: David Laight, Andreas Dilger, linux-ext4, linux-kernel,
Masami Hiramatsu, Petr Mladek, Rasmus Villemoes, Steven Rostedt,
Sergey Senozhatsky, Andrew Morton
In-Reply-To: <20260327171414.GF4383@macsyma.local>
On Fri, Mar 27, 2026 at 12:14:14PM -0500, Theodore Tso wrote:
> On Fri, Mar 27, 2026 at 04:12:38PM +0200, Andy Shevchenko wrote:
> > > > I'm not sure how your patch helps with all that, but apparently the
> > > > printed data has to be NUL-terminated, otherwise I have no idea how
> > > > it was ever working without crashes.
> > >
> > > I noticed that as well.
> > > I suspect it way have worked for the person that wrote it because the
> > > name strings all happened to be NUL terminated.
> > > There is certainly likely to be a '\0' before you 'fall off' mapped
> > > memory and crash - so maybe they just ignored the extra characters.
> > >
> > > Clearly the other option is to delete it all.
> >
> > I would go for the history of the change and if it's old enough and not
> > mentioned in any Documentation or not-so-old email thread, kill all that
> > for good. But better to hear the ext4 maintainers first.
>
> This is code that can only be manually enabled by adding a
>
> #define DX_DEBUG
>
> to the sources; it's not anything that users can configure using
> Kconfig. It *has* been used relatively recently, when developers
> added support for three level htree directories. I'm not sure why
> they didn't run into the NULL termination issue, but since it is handy
> to have the debugging code for developers' use, my preference would be
> to keep the code and fix it up the problems.
Good to know!
But what is expected input here, i.o.w. should we assume it's always
NUL-terminated, or use fixed-length strings? If the latter one is correct
the current patch may be applied as is then.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: SYZKALLER BUG: messing with a mounted file system via loop ioctls (was: Re: [PATCH] ext4: add bounds check in ext4_xattr_ibody_get() to) prevent out-of-bounds access
From: Dmitry Vyukov @ 2026-03-29 9:47 UTC (permalink / raw)
To: Deepanshu Kartikey, Theodore Tso, syzkaller
Cc: adilger.kernel, linux-ext4, linux-kernel,
syzbot+fb32afec111a7d61b939
In-Reply-To: <CADhLXY6QjWHiyY2MkUutzJK8utKghMTxjG9C8X7e=WDL5xKvYQ@mail.gmail.com>
On Sat, 28 Mar 2026 at 16:02, Deepanshu Kartikey <kartikey406@gmail.com> wrote:
>
> On Fri, Mar 27, 2026 at 10:01 PM Theodore Tso <tytso@mit.edu> wrote:
> >
> > On Fri, Mar 27, 2026 at 08:02:30PM +0530, Deepanshu Kartikey wrote:
> > >
> > > Thank you for the review. I tried moving the fix to check_xattrs()
> > > as you suggested, but the syzbot reproducer still crashes. I added
> > > printk statements to trace the code path and found the root cause.
> > >
> > > The issue is that __xattr_check_inode() runs once during ext4_iget(),
> > > but ext4_xattr_ibody_get() re-reads the inode from disk via
> > > ext4_get_inode_loc() on every call. The reproducer exploits this by
> > > shrinking the loop device after mount, causing the re-read to return
> > > corrupted data.
> >
> > I consider this more a defect in Syzkaller than in ext4. Syzkaller
> > already unsets CONFIG_BLK_DEV_WRITE_MOUNTED because modifying a
> > mounted file system is not considered a valid security concern.
> > Unfortunately, the syzkaller fuzzer which corrupts a mounted file
> > system by messing with a loop device using a privileged ioctl bypasses
> > !CONFIG_DEV_BLK_WRITE_MOUNTED.
> >
> > I'll accept a change to add a to check_xattrs(), which will protect
> > against static corruptions, but adding an extra check to a hotpath
> > (this would slow down SELinux, which aggressively needs to read the
> > file's sid) to protect against a corruption issue which requires root
> > privs is not something I'm interested in.
> >
> > My priority is improving ext4 --- not reducing the syzkaller reports
> > against ext4 to zero, since there are false positives like this. For
> > people who care about reducing the syzkaller report gamification, my
> > suggestion is to either extend CONFIG_BLK_DEV_WRITE_MOUNTED to prevent
> > these loop device reconfiguration while a file system is mounted on
> > that loop device, or to fix syzkaller to not create fuzzers like this.
Hi Ted,
Thanks for the report.
https://syzkaller.appspot.com/text?tag=ReproSyz&x=17a43b3a580000
Do you mean LOOP_SET_STATUS64 ioctl? It's the only ioctl in the repro:
ioctl$LOOP_SET_STATUS64(r0, 0x4c04, ...)
Does it mean it should also be prohibited under
CONFIG_BLK_DEV_WRITE_MOUNTED to avoid kernel memory corruption?
Or at least some changes should be prohibited? E.g. I guess changing
lo_offset is equivalent to writing to the mounted device.
^ permalink raw reply
* [GIT PULL] ext4 fixes for 7.0-rc6
From: Theodore Tso @ 2026-03-29 4:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Ext4 Developers List, Linux Kernel Developers List
The following changes since commit f338e77383789c0cae23ca3d48adcc5e9e137e3c:
Linux 7.0-rc4 (2026-03-15 13:52:05 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git tags/ext4_for_linus-7.0-rc6
for you to fetch changes up to 9ee29d20aab228adfb02ca93f87fb53c56c2f3af:
ext4: always drain queued discard work in ext4_mb_release() (2026-03-27 23:39:10 -0400)
----------------------------------------------------------------
Update the MAINTAINERS file to add reviewers for the ext4 file system
Add a test issue an ext4 warning (not a WARN_ON) if there are still
dirty pages attached to an evicted inode.
A lot of ext4 bug fixes including:
* Fix a number of Syzkaller issues.
* Fix memory leaks on error paths.
* Replace some BUG and WARN with EFSCORRUPTED reporting.
* Fix a potential crash when disabling discard via remount followed
by an immediate unmount. (Found by Sashiko)
* Fix a corner case which could lead to allocating blocks for an
indirect-mapped inode block numbers > 2**32.
* Fix a race when reallocating a freed inode that could result in
a deadlock.
* Fix a user-after-free in update_super_work when racing with umount.
* Fix build issues when trying to build ext4's kunit tests as a module
* Fix a bug where ext4_split_extent_zeroout() could fail to pass
back an error from ext4_ext_dirty().
* Avoid allocating blocks from a corrupted block group in
ext4_mb_find_by_goal().
* Fix a percpu_counters list corruption BUG triggered by an
ext4 extents kunit.
* Fix a potetial crash caused by the fast commit flush path potentially
accessing the jinode structure before it is fully initialized.
* Fix fsync(2) in no-journal mode to make sure the dirtied inode is
write to storage.
* Fix a bug when in no-journal mode, when ext4 tries to avoid using
recently deleted inodes, if lazy itable initialization is enabled,
can lead to an unitialized inode getting skipped and triggering
an e2fsck complaint.
* Fix journal credit calculation when setting an xattr when both
the encryption and ea_inode feeatures are enabled.
* Fix corner cases which could result in stale xarray tags after
writeback.
* Fix generic/475 failures caused by ENOSPC errors while creating
a symlink when the system crashes resulting to a file system
inconsistency when replaying the fast commit journal.
----------------------------------------------------------------
Baokun Li (1):
ext4: fix iloc.bh leak in ext4_fc_replay_inode() error paths
Deepanshu Kartikey (1):
ext4: convert inline data to extents when truncate exceeds inline size
Edward Adam Davis (1):
ext4: avoid infinite loops caused by residual data
Helen Koike (1):
ext4: reject mount if bigalloc with s_first_data_block != 0
Jan Kara (4):
ext4: fix stale xarray tags after writeback
ext4: make recently_deleted() properly work with lazy itable initialization
ext4: fix fsync(2) for nojournal mode
ext4: fix deadlock on inode reallocation
Jiayuan Chen (1):
ext4: fix use-after-free in update_super_work when racing with umount
Li Chen (1):
ext4: publish jinode after initialization
Milos Nikic (1):
jbd2: gracefully abort on checkpointing state corruptions
Ojaswin Mujoo (1):
ext4: minor fix for ext4_split_extent_zeroout()
Ritesh Harjani (IBM) (1):
ext4: kunit: extents-test: lix percpu_counters list corruption
Simon Weber (1):
ext4: fix journal credit check when setting fscrypt context
Tejas Bharambe (1):
ext4: validate p_idx bounds in ext4_ext_correct_indexes
Theodore Ts'o (3):
Update MAINTAINERS file to add reviewers for ext4
ext4: handle wraparound when searching for blocks for indirect mapped blocks
ext4: always drain queued discard work in ext4_mb_release()
Ye Bin (5):
ext4: avoid allocate block from corrupted group in ext4_mb_find_by_goal()
ext4: test if inode's all dirty pages are submitted to disk
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
Yuto Ohnuki (1):
ext4: replace BUG_ON with proper error handling in ext4_read_inline_folio
Zhang Yi (1):
ext4: do not check fast symlink during orphan recovery
Zqiang (1):
ext4: fix the might_sleep() warnings in kvfree()
hongao (1):
ext4: skip split extent recovery on corruption
MAINTAINERS | 7 ++-
fs/ext4/Makefile | 5 +-
fs/ext4/crypto.c | 9 +++-
fs/ext4/ext4.h | 6 +++
fs/ext4/ext4_extents.h | 12 +++++
fs/ext4/extents-test.c | 12 +++--
fs/ext4/extents.c | 80 +++++++++++++++++++++++++-----
fs/ext4/fast_commit.c | 17 ++++---
fs/ext4/fsync.c | 16 +++++-
fs/ext4/ialloc.c | 6 +++
fs/ext4/inline.c | 10 +++-
fs/ext4/inode.c | 75 ++++++++++++++++++++++------
fs/ext4/mballoc-test.c | 81 +++++++++++++++---------------
fs/ext4/mballoc.c | 132 ++++++++++++++++++++++++++++++++++++++++++-------
fs/ext4/mballoc.h | 30 +++++++++++
fs/ext4/page-io.c | 10 +++-
fs/ext4/super.c | 37 +++++++++++---
fs/ext4/sysfs.c | 10 +++-
fs/jbd2/checkpoint.c | 15 +++++-
19 files changed, 455 insertions(+), 115 deletions(-)
^ permalink raw reply
* [tytso-ext4:dev] BUILD SUCCESS 9ee29d20aab228adfb02ca93f87fb53c56c2f3af
From: kernel test robot @ 2026-03-28 16:43 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: linux-ext4
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev
branch HEAD: 9ee29d20aab228adfb02ca93f87fb53c56c2f3af ext4: always drain queued discard work in ext4_mb_release()
elapsed time: 752m
configs tested: 187
configs skipped: 2
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260328 gcc-15.2.0
arc randconfig-002-20260328 gcc-15.2.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm aspeed_g4_defconfig clang-23
arm collie_defconfig gcc-15.2.0
arm defconfig gcc-15.2.0
arm randconfig-001-20260328 gcc-15.2.0
arm randconfig-002-20260328 gcc-15.2.0
arm randconfig-003-20260328 gcc-15.2.0
arm randconfig-004-20260328 gcc-15.2.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260328 gcc-14.3.0
arm64 randconfig-002-20260328 gcc-14.3.0
arm64 randconfig-003-20260328 gcc-14.3.0
arm64 randconfig-004-20260328 gcc-14.3.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260328 gcc-14.3.0
csky randconfig-002-20260328 gcc-14.3.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260328 gcc-11.5.0
hexagon randconfig-002-20260328 gcc-11.5.0
i386 allmodconfig clang-20
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260328 clang-20
i386 buildonly-randconfig-002-20260328 clang-20
i386 buildonly-randconfig-003-20260328 clang-20
i386 buildonly-randconfig-004-20260328 clang-20
i386 buildonly-randconfig-005-20260328 clang-20
i386 buildonly-randconfig-006-20260328 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260328 clang-20
i386 randconfig-002-20260328 clang-20
i386 randconfig-003-20260328 clang-20
i386 randconfig-004-20260328 clang-20
i386 randconfig-005-20260328 clang-20
i386 randconfig-006-20260328 clang-20
i386 randconfig-007-20260328 clang-20
i386 randconfig-011-20260328 gcc-13
i386 randconfig-012-20260328 gcc-13
i386 randconfig-013-20260328 gcc-13
i386 randconfig-014-20260328 gcc-13
i386 randconfig-015-20260328 gcc-13
i386 randconfig-016-20260328 gcc-13
i386 randconfig-017-20260328 gcc-13
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260328 gcc-11.5.0
loongarch randconfig-002-20260328 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
nios2 allmodconfig clang-23
nios2 allmodconfig gcc-11.5.0
nios2 allnoconfig clang-23
nios2 allnoconfig gcc-11.5.0
nios2 defconfig clang-19
nios2 randconfig-001-20260328 gcc-11.5.0
nios2 randconfig-002-20260328 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allmodconfig gcc-15.2.0
openrisc allnoconfig clang-23
openrisc allnoconfig gcc-15.2.0
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allnoconfig gcc-15.2.0
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260328 gcc-10.5.0
parisc randconfig-002-20260328 gcc-10.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc allnoconfig gcc-15.2.0
powerpc cell_defconfig gcc-15.2.0
powerpc randconfig-001-20260328 gcc-10.5.0
powerpc randconfig-002-20260328 gcc-10.5.0
powerpc64 randconfig-001-20260328 gcc-10.5.0
powerpc64 randconfig-002-20260328 gcc-10.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allnoconfig gcc-15.2.0
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001-20260328 clang-23
riscv randconfig-002-20260328 clang-23
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001-20260328 clang-23
s390 randconfig-002-20260328 clang-23
sh alldefconfig gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allnoconfig gcc-15.2.0
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001-20260328 clang-23
sh randconfig-002-20260328 clang-23
sh se7705_defconfig gcc-15.2.0
sparc allnoconfig clang-23
sparc allnoconfig gcc-15.2.0
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260328 gcc-14
sparc randconfig-002-20260328 gcc-14
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260328 gcc-14
sparc64 randconfig-002-20260328 gcc-14
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260328 gcc-14
um randconfig-002-20260328 gcc-14
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260328 clang-20
x86_64 buildonly-randconfig-002-20260328 clang-20
x86_64 buildonly-randconfig-003-20260328 clang-20
x86_64 buildonly-randconfig-004-20260328 clang-20
x86_64 buildonly-randconfig-005-20260328 clang-20
x86_64 buildonly-randconfig-006-20260328 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260328 gcc-14
x86_64 randconfig-002-20260328 gcc-14
x86_64 randconfig-003-20260328 gcc-14
x86_64 randconfig-004-20260328 gcc-14
x86_64 randconfig-005-20260328 gcc-14
x86_64 randconfig-006-20260328 gcc-14
x86_64 randconfig-011-20260328 clang-20
x86_64 randconfig-012-20260328 clang-20
x86_64 randconfig-013-20260328 clang-20
x86_64 randconfig-014-20260328 clang-20
x86_64 randconfig-015-20260328 clang-20
x86_64 randconfig-016-20260328 clang-20
x86_64 randconfig-071-20260328 gcc-12
x86_64 randconfig-072-20260328 gcc-12
x86_64 randconfig-073-20260328 gcc-12
x86_64 randconfig-074-20260328 gcc-12
x86_64 randconfig-075-20260328 gcc-12
x86_64 randconfig-076-20260328 gcc-12
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allnoconfig gcc-15.2.0
xtensa allyesconfig clang-23
xtensa randconfig-001-20260328 gcc-14
xtensa randconfig-002-20260328 gcc-14
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ 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