ACK: [SRU][N/Q][PATCH 0/1] Remount ext4 to readonly with data=journal mode may dump call trace

[Masahiro Yamada]

On 4/7/26 18:26, Gerald Yang wrote:
> BugLink: https://bugs.launchpad.net/bugs/2147400
>
> [Impact]
>
> When journal is filled with some data and remount the filesystem to read-only in data=journal mode
> it may dump the following call trace:
> [   71.629350] CPU: 0 UID: 0 PID: 177 Comm: kworker/u96:5 Tainted: G            E       6.19.0-rc7 #1 PREEMPT(voluntary)
> [   71.629352] Tainted: [E]=UNSIGNED_MODULE
> [   71.629353] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)/LXD, BIOS unknown 2/2/2022
> [   71.629354] Workqueue: writeback wb_workfn (flush-7:4)
> [   71.629359] RIP: 0010:ext4_journal_check_start+0x8b/0xd0
> [   71.629360] Code: 31 ff 45 31 c0 45 31 c9 e9 42 ad c4 00 48 8b 5d f8 b8 fb ff ff ff c9 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc <0f> 0b b8 e2 ff ff ff eb c2 0f 0b eb
>   a9 44 8b 42 08 68 c7 53 ce b8
> [   71.629361] RSP: 0018:ffffcf32c0fdf6a8 EFLAGS: 00010202
> [   71.629364] RAX: ffff8f08c8505000 RBX: ffff8f08c67ee800 RCX: 0000000000000000
> [   71.629366] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> [   71.629367] RBP: ffffcf32c0fdf6b0 R08: 0000000000000001 R09: 0000000000000000
> [   71.629368] R10: ffff8f08db18b3a8 R11: 0000000000000000 R12: 0000000000000000
> [   71.629368] R13: 0000000000000002 R14: 0000000000000a48 R15: ffff8f08c67ee800
> [   71.629369] FS:  0000000000000000(0000) GS:ffff8f0a7d273000(0000) knlGS:0000000000000000
> [   71.629370] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   71.629371] CR2: 00007b66825905cc CR3: 000000011053d004 CR4: 0000000000772ef0
> [   71.629374] PKRU: 55555554
> [   71.629374] Call Trace:
> [   71.629378]  <TASK>
> [   71.629382]  __ext4_journal_start_sb+0x38/0x1c0
> [   71.629383]  mpage_prepare_extent_to_map+0x4af/0x580
> [   71.629389]  ? sbitmap_get+0x73/0x180
> [   71.629399]  ext4_do_writepages+0x3cc/0x10a0
> [   71.629400]  ? kvm_sched_clock_read+0x11/0x20
> [   71.629409]  ext4_writepages+0xc8/0x1b0
> [   71.629410]  ? ext4_writepages+0xc8/0x1b0
> [   71.629411]  do_writepages+0xc4/0x180
> [   71.629416]  __writeback_single_inode+0x45/0x350
> [   71.629419]  ? _raw_spin_unlock+0xe/0x40
> [   71.629423]  writeback_sb_inodes+0x260/0x5c0
> [   71.629425]  ? __schedule+0x4d1/0x1870
> [   71.629429]  __writeback_inodes_wb+0x54/0x100
> [   71.629431]  ? queue_io+0x82/0x140
> [   71.629433]  wb_writeback+0x1ab/0x330
> [   71.629448]  wb_workfn+0x31d/0x410
> [   71.629450]  process_one_work+0x191/0x3e0
> [   71.629455]  worker_thread+0x2e3/0x420
>
> [Fix]
>
> This upstream commit fixes the issue:
> https://github.com/torvalds/linux/commit/f4a2b42e78914ff15630e71289adc589c3a8eb45
>
> All the discussions are in this thread:
> https://lore.kernel.org/all/20260128074515.2028982-1-gerald.yang@canonical.com/
>
> [Test Plan]
>
> This can be easily reproduced by the following script:
> mkdir -p mnt
> dd if=/dev/zero of=ext4disk bs=1G count=2 oflag=direct
> mkfs.ext4 ext4disk
> tune2fs -o journal_data ext4disk
> mount ext4disk mnt
> fio --name=fiotest --rw=randwrite --bs=4k --runtime=3 --ioengine=libaio --iodepth=128 --numjobs=4 --filename=mnt/fiotest --filesize=1G --group_reporting
> mount -o remount,ro ext4disk mnt
> sync
>
> [Where problems could occur]
>
> When the call trace happens, there is no data lost, all the dirty data has been flushed to file system before remounting.
> The fix is to make sure folio state is correct and update the xarray, so the writeback thread won't be trigger if there is no dirty data.
> So if there is something really goes wrong, there still won't be data lost, even remount it to read-write mode again.
>
> Jan Kara (1):
>    ext4: fix stale xarray tags after writeback
>
>   fs/ext4/page-io.c | 10 ++++++++--
>   1 file changed, 8 insertions(+), 2 deletions(-)
>
Acked-by: Masahiro Yamada <masahiro.yamada at canonical.com>