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

[Gerald Yang]

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(-)

-- 
2.43.0