Regressions noticed on arm64 devices while running LTP syscalls mmap16 test case on the Linux next-20250616..next-20250626 with the extra build config fragment CONFIG_ARM64_64K_PAGES=y the kernel warning noticed.
Not reproducible with 4K page size.
Test environments: - Dragonboard-410c - Juno-r2 - rk3399-rock-pi-4b - qemu-arm64
Regression Analysis: - New regression? Yes - Reproducibility? Yes
Test regression: next-20250626 LTP mmap16 WARNING fs jbd2 transaction.c start_this_handle
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
## Test log <6>[ 89.498969] loop0: detected capacity change from 0 to 614400 <3>[ 89.609561] operation not supported error, dev loop0, sector 20352 op 0x9:(WRITE_ZEROES) flags 0x20000800 phys_seg 0 prio class 0 <6>[ 89.707795] EXT4-fs (loop0): mounted filesystem 6786a191-5e0d-472b-8bce-4714e1a4fb44 r/w with ordered data mode. Quota mode: none. <3>[ 90.023985] JBD2: kworker/u8:2 wants too many credits credits:416 rsv_credits:21 max:334 <4>[ 90.024973] ------------[ cut here ]------------ <4>[ 90.025062] WARNING: fs/jbd2/transaction.c:334 at start_this_handle+0x4c0/0x4e0, CPU#0: 2/42 <4>[ 90.026661] Modules linked in: btrfs blake2b_generic xor xor_neon raid6_pq zstd_compress sm3_ce sha3_ce fuse drm backlight ip_tables x_tables <4>[ 90.027952] CPU: 0 UID: 0 PID: 42 Comm: kworker/u8:2 Not tainted 6.16.0-rc3-next-20250626 #1 PREEMPT <4>[ 90.029043] Hardware name: linux,dummy-virt (DT) <4>[ 90.029524] Workqueue: writeback wb_workfn (flush-7:0) <4>[ 90.030050] pstate: 63402009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) <4>[ 90.030311] pc : start_this_handle (fs/jbd2/transaction.c:334 (discriminator 1)) <4>[ 90.030481] lr : start_this_handle (fs/jbd2/transaction.c:334 (discriminator 1)) <4>[ 90.030656] sp : ffffc000805cb650 <4>[ 90.030785] x29: ffffc000805cb690 x28: fff00000dd1f5000 x27: ffffde2ec0272000 <4>[ 90.031097] x26: 00000000000001a0 x25: 0000000000000015 x24: 0000000000000002 <4>[ 90.031360] x23: 0000000000000015 x22: 0000000000000c40 x21: 0000000000000008 <4>[ 90.031618] x20: fff00000c231da78 x19: fff00000c231da78 x18: 0000000000000000 <4>[ 90.031875] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 <4>[ 90.032859] x14: 0000000000000000 x13: 00000000ffffffff x12: 0000000000000000 <4>[ 90.033225] x11: 0000000000000000 x10: ffffde2ebfba8bd0 x9 : ffffde2ebd34e944 <4>[ 90.033607] x8 : ffffc000805cb278 x7 : 0000000000000000 x6 : 0000000000000001 <4>[ 90.033971] x5 : ffffde2ebfb29000 x4 : ffffde2ebfb293d0 x3 : 0000000000000000 <4>[ 90.034294] x2 : 0000000000000000 x1 : fff00000c04dc080 x0 : 000000000000004c <4>[ 90.034772] Call trace: <4>[ 90.035068] start_this_handle (fs/jbd2/transaction.c:334 (discriminator 1)) (P) <4>[ 90.035366] jbd2__journal_start (fs/jbd2/transaction.c:501) <4>[ 90.035586] __ext4_journal_start_sb (fs/ext4/ext4_jbd2.c:117) <4>[ 90.035807] ext4_do_writepages (fs/ext4/ext4_jbd2.h:242 fs/ext4/inode.c:2846) <4>[ 90.036004] ext4_writepages (fs/ext4/inode.c:2953) <4>[ 90.036233] do_writepages (mm/page-writeback.c:2636) <4>[ 90.036406] __writeback_single_inode (fs/fs-writeback.c:1680) <4>[ 90.036616] writeback_sb_inodes (fs/fs-writeback.c:1978) <4>[ 90.036891] wb_writeback (fs/fs-writeback.c:2156) <4>[ 90.037122] wb_workfn (fs/fs-writeback.c:2303 (discriminator 1) fs/fs-writeback.c:2343 (discriminator 1)) <4>[ 90.037318] process_one_work (kernel/workqueue.c:3244) <4>[ 90.037517] worker_thread (kernel/workqueue.c:3316 (discriminator 2) kernel/workqueue.c:3403 (discriminator 2)) <4>[ 90.037752] kthread (kernel/kthread.c:463) <4>[ 90.037903] ret_from_fork (arch/arm64/kernel/entry.S:863) <4>[ 90.038217] ---[ end trace 0000000000000000 ]--- <2>[ 90.039950] EXT4-fs (loop0): ext4_do_writepages: jbd2_start: 9223372036854775807 pages, ino 14; err -28 <3>[ 90.040291] JBD2: kworker/u8:2 wants too many credits credits:416 rsv_credits:21 max:334 <4>[ 90.040374] ------------[ cut here ]------------ <4>[ 90.040386] WARNING: fs/jbd2/transaction.c:334 at start_this_handle+0x4c0/0x4e0, CPU#1: 2/42
## Source * Kernel version: 6.16.0-rc3-next-20250626 * Git tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git * Git sha: ecb259c4f70dd5c83907809f45bf4dc6869961d7 * Git describe: 6.16.0-rc3-next-20250626 * Project details: https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20250626/ * Architectures: arm64 * Toolchains: gcc-13 * Kconfigs: gcc-13-lkftconfig-64k_page_size
## Build arm64 * Test log: https://qa-reports.linaro.org/api/testruns/28894530/log_file/ * Test LAVA log 1: https://lkft.validation.linaro.org/scheduler/job/8331353#L6841 * Test LAVA log 2: https://lkft.validation.linaro.org/scheduler/job/8331352#L8854 * Test details: https://regressions.linaro.org/lkft/linux-next-master/next-20250626/log-pars... * Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObV... * Kernel config: https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObV...
-- Linaro LKFT https://lkft.linaro.org
Hi, Naresh!
On 2025/6/26 20:31, Naresh Kamboju wrote:
Regressions noticed on arm64 devices while running LTP syscalls mmap16 test case on the Linux next-20250616..next-20250626 with the extra build config fragment CONFIG_ARM64_64K_PAGES=y the kernel warning noticed.
Not reproducible with 4K page size.
Test environments:
- Dragonboard-410c
- Juno-r2
- rk3399-rock-pi-4b
- qemu-arm64
Regression Analysis:
- New regression? Yes
- Reproducibility? Yes
Test regression: next-20250626 LTP mmap16 WARNING fs jbd2 transaction.c start_this_handle
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Thank you for the report. The block size for this test is 1 KB, so I suspect this is the issue with insufficient journal credits that we are going to resolve.
https://lore.kernel.org/linux-ext4/20250611111625.1668035-1-yi.zhang@huaweic...
Thanks, Yi.
## Test log <6>[ 89.498969] loop0: detected capacity change from 0 to 614400 <3>[ 89.609561] operation not supported error, dev loop0, sector 20352 op 0x9:(WRITE_ZEROES) flags 0x20000800 phys_seg 0 prio class 0 <6>[ 89.707795] EXT4-fs (loop0): mounted filesystem 6786a191-5e0d-472b-8bce-4714e1a4fb44 r/w with ordered data mode. Quota mode: none. <3>[ 90.023985] JBD2: kworker/u8:2 wants too many credits credits:416 rsv_credits:21 max:334 <4>[ 90.024973] ------------[ cut here ]------------ <4>[ 90.025062] WARNING: fs/jbd2/transaction.c:334 at start_this_handle+0x4c0/0x4e0, CPU#0: 2/42 <4>[ 90.026661] Modules linked in: btrfs blake2b_generic xor xor_neon raid6_pq zstd_compress sm3_ce sha3_ce fuse drm backlight ip_tables x_tables <4>[ 90.027952] CPU: 0 UID: 0 PID: 42 Comm: kworker/u8:2 Not tainted 6.16.0-rc3-next-20250626 #1 PREEMPT <4>[ 90.029043] Hardware name: linux,dummy-virt (DT) <4>[ 90.029524] Workqueue: writeback wb_workfn (flush-7:0) <4>[ 90.030050] pstate: 63402009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) <4>[ 90.030311] pc : start_this_handle (fs/jbd2/transaction.c:334 (discriminator 1)) <4>[ 90.030481] lr : start_this_handle (fs/jbd2/transaction.c:334 (discriminator 1)) <4>[ 90.030656] sp : ffffc000805cb650 <4>[ 90.030785] x29: ffffc000805cb690 x28: fff00000dd1f5000 x27: ffffde2ec0272000 <4>[ 90.031097] x26: 00000000000001a0 x25: 0000000000000015 x24: 0000000000000002 <4>[ 90.031360] x23: 0000000000000015 x22: 0000000000000c40 x21: 0000000000000008 <4>[ 90.031618] x20: fff00000c231da78 x19: fff00000c231da78 x18: 0000000000000000 <4>[ 90.031875] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 <4>[ 90.032859] x14: 0000000000000000 x13: 00000000ffffffff x12: 0000000000000000 <4>[ 90.033225] x11: 0000000000000000 x10: ffffde2ebfba8bd0 x9 : ffffde2ebd34e944 <4>[ 90.033607] x8 : ffffc000805cb278 x7 : 0000000000000000 x6 : 0000000000000001 <4>[ 90.033971] x5 : ffffde2ebfb29000 x4 : ffffde2ebfb293d0 x3 : 0000000000000000 <4>[ 90.034294] x2 : 0000000000000000 x1 : fff00000c04dc080 x0 : 000000000000004c <4>[ 90.034772] Call trace: <4>[ 90.035068] start_this_handle (fs/jbd2/transaction.c:334 (discriminator 1)) (P) <4>[ 90.035366] jbd2__journal_start (fs/jbd2/transaction.c:501) <4>[ 90.035586] __ext4_journal_start_sb (fs/ext4/ext4_jbd2.c:117) <4>[ 90.035807] ext4_do_writepages (fs/ext4/ext4_jbd2.h:242 fs/ext4/inode.c:2846) <4>[ 90.036004] ext4_writepages (fs/ext4/inode.c:2953) <4>[ 90.036233] do_writepages (mm/page-writeback.c:2636) <4>[ 90.036406] __writeback_single_inode (fs/fs-writeback.c:1680) <4>[ 90.036616] writeback_sb_inodes (fs/fs-writeback.c:1978) <4>[ 90.036891] wb_writeback (fs/fs-writeback.c:2156) <4>[ 90.037122] wb_workfn (fs/fs-writeback.c:2303 (discriminator 1) fs/fs-writeback.c:2343 (discriminator 1)) <4>[ 90.037318] process_one_work (kernel/workqueue.c:3244) <4>[ 90.037517] worker_thread (kernel/workqueue.c:3316 (discriminator 2) kernel/workqueue.c:3403 (discriminator 2)) <4>[ 90.037752] kthread (kernel/kthread.c:463) <4>[ 90.037903] ret_from_fork (arch/arm64/kernel/entry.S:863) <4>[ 90.038217] ---[ end trace 0000000000000000 ]--- <2>[ 90.039950] EXT4-fs (loop0): ext4_do_writepages: jbd2_start: 9223372036854775807 pages, ino 14; err -28 <3>[ 90.040291] JBD2: kworker/u8:2 wants too many credits credits:416 rsv_credits:21 max:334 <4>[ 90.040374] ------------[ cut here ]------------ <4>[ 90.040386] WARNING: fs/jbd2/transaction.c:334 at start_this_handle+0x4c0/0x4e0, CPU#1: 2/42
## Source
- Kernel version: 6.16.0-rc3-next-20250626
- Git tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git
- Git sha: ecb259c4f70dd5c83907809f45bf4dc6869961d7
- Git describe: 6.16.0-rc3-next-20250626
- Project details:
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20250626/
- Architectures: arm64
- Toolchains: gcc-13
- Kconfigs: gcc-13-lkftconfig-64k_page_size
## Build arm64
- Test log: https://qa-reports.linaro.org/api/testruns/28894530/log_file/
- Test LAVA log 1:
https://lkft.validation.linaro.org/scheduler/job/8331353#L6841
- Test LAVA log 2:
https://lkft.validation.linaro.org/scheduler/job/8331352#L8854
- Test details:
https://regressions.linaro.org/lkft/linux-next-master/next-20250626/log-pars...
- Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObV...
- Kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObV...
-- Linaro LKFT https://lkft.linaro.org
On Thu, 26 Jun 2025 at 19:23, Zhang Yi yi.zhang@huaweicloud.com wrote:
Hi, Naresh!
On 2025/6/26 20:31, Naresh Kamboju wrote:
Regressions noticed on arm64 devices while running LTP syscalls mmap16 test case on the Linux next-20250616..next-20250626 with the extra build config fragment CONFIG_ARM64_64K_PAGES=y the kernel warning noticed.
Not reproducible with 4K page size.
Test environments:
- Dragonboard-410c
- Juno-r2
- rk3399-rock-pi-4b
- qemu-arm64
Regression Analysis:
- New regression? Yes
- Reproducibility? Yes
Test regression: next-20250626 LTP mmap16 WARNING fs jbd2 transaction.c start_this_handle
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Thank you for the report. The block size for this test is 1 KB, so I suspect this is the issue with insufficient journal credits that we are going to resolve.
I have applied your patch set [1] and tested and the reported regressions did not fix. Am I missing anything ?
[1] https://lore.kernel.org/linux-ext4/20250611111625.1668035-1-yi.zhang@huaweic...
Thanks, Yi.
- Naresh
## Test log <6>[ 89.498969] loop0: detected capacity change from 0 to 614400 <3>[ 89.609561] operation not supported error, dev loop0, sector 20352 op 0x9:(WRITE_ZEROES) flags 0x20000800 phys_seg 0 prio class 0 <6>[ 89.707795] EXT4-fs (loop0): mounted filesystem 6786a191-5e0d-472b-8bce-4714e1a4fb44 r/w with ordered data mode. Quota mode: none. <3>[ 90.023985] JBD2: kworker/u8:2 wants too many credits credits:416 rsv_credits:21 max:334 <4>[ 90.024973] ------------[ cut here ]------------ <4>[ 90.025062] WARNING: fs/jbd2/transaction.c:334 at start_this_handle+0x4c0/0x4e0, CPU#0: 2/42 <4>[ 90.026661] Modules linked in: btrfs blake2b_generic xor xor_neon raid6_pq zstd_compress sm3_ce sha3_ce fuse drm backlight ip_tables x_tables <4>[ 90.027952] CPU: 0 UID: 0 PID: 42 Comm: kworker/u8:2 Not tainted 6.16.0-rc3-next-20250626 #1 PREEMPT <4>[ 90.029043] Hardware name: linux,dummy-virt (DT) <4>[ 90.029524] Workqueue: writeback wb_workfn (flush-7:0) <4>[ 90.030050] pstate: 63402009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) <4>[ 90.030311] pc : start_this_handle (fs/jbd2/transaction.c:334 (discriminator 1)) <4>[ 90.030481] lr : start_this_handle (fs/jbd2/transaction.c:334 (discriminator 1)) <4>[ 90.030656] sp : ffffc000805cb650 <4>[ 90.030785] x29: ffffc000805cb690 x28: fff00000dd1f5000 x27: ffffde2ec0272000 <4>[ 90.031097] x26: 00000000000001a0 x25: 0000000000000015 x24: 0000000000000002 <4>[ 90.031360] x23: 0000000000000015 x22: 0000000000000c40 x21: 0000000000000008 <4>[ 90.031618] x20: fff00000c231da78 x19: fff00000c231da78 x18: 0000000000000000 <4>[ 90.031875] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 <4>[ 90.032859] x14: 0000000000000000 x13: 00000000ffffffff x12: 0000000000000000 <4>[ 90.033225] x11: 0000000000000000 x10: ffffde2ebfba8bd0 x9 : ffffde2ebd34e944 <4>[ 90.033607] x8 : ffffc000805cb278 x7 : 0000000000000000 x6 : 0000000000000001 <4>[ 90.033971] x5 : ffffde2ebfb29000 x4 : ffffde2ebfb293d0 x3 : 0000000000000000 <4>[ 90.034294] x2 : 0000000000000000 x1 : fff00000c04dc080 x0 : 000000000000004c <4>[ 90.034772] Call trace: <4>[ 90.035068] start_this_handle (fs/jbd2/transaction.c:334 (discriminator 1)) (P) <4>[ 90.035366] jbd2__journal_start (fs/jbd2/transaction.c:501) <4>[ 90.035586] __ext4_journal_start_sb (fs/ext4/ext4_jbd2.c:117) <4>[ 90.035807] ext4_do_writepages (fs/ext4/ext4_jbd2.h:242 fs/ext4/inode.c:2846) <4>[ 90.036004] ext4_writepages (fs/ext4/inode.c:2953) <4>[ 90.036233] do_writepages (mm/page-writeback.c:2636) <4>[ 90.036406] __writeback_single_inode (fs/fs-writeback.c:1680) <4>[ 90.036616] writeback_sb_inodes (fs/fs-writeback.c:1978) <4>[ 90.036891] wb_writeback (fs/fs-writeback.c:2156) <4>[ 90.037122] wb_workfn (fs/fs-writeback.c:2303 (discriminator 1) fs/fs-writeback.c:2343 (discriminator 1)) <4>[ 90.037318] process_one_work (kernel/workqueue.c:3244) <4>[ 90.037517] worker_thread (kernel/workqueue.c:3316 (discriminator 2) kernel/workqueue.c:3403 (discriminator 2)) <4>[ 90.037752] kthread (kernel/kthread.c:463) <4>[ 90.037903] ret_from_fork (arch/arm64/kernel/entry.S:863) <4>[ 90.038217] ---[ end trace 0000000000000000 ]--- <2>[ 90.039950] EXT4-fs (loop0): ext4_do_writepages: jbd2_start: 9223372036854775807 pages, ino 14; err -28 <3>[ 90.040291] JBD2: kworker/u8:2 wants too many credits credits:416 rsv_credits:21 max:334 <4>[ 90.040374] ------------[ cut here ]------------ <4>[ 90.040386] WARNING: fs/jbd2/transaction.c:334 at start_this_handle+0x4c0/0x4e0, CPU#1: 2/42
## Source
- Kernel version: 6.16.0-rc3-next-20250626
- Git tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git
- Git sha: ecb259c4f70dd5c83907809f45bf4dc6869961d7
- Git describe: 6.16.0-rc3-next-20250626
- Project details:
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20250626/
- Architectures: arm64
- Toolchains: gcc-13
- Kconfigs: gcc-13-lkftconfig-64k_page_size
## Build arm64
- Test log: https://qa-reports.linaro.org/api/testruns/28894530/log_file/
- Test LAVA log 1:
https://lkft.validation.linaro.org/scheduler/job/8331353#L6841
- Test LAVA log 2:
https://lkft.validation.linaro.org/scheduler/job/8331352#L8854
- Test details:
https://regressions.linaro.org/lkft/linux-next-master/next-20250626/log-pars...
- Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObV...
- Kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObV...
-- Linaro LKFT https://lkft.linaro.org
On 2025/7/3 15:26, Naresh Kamboju wrote:
On Thu, 26 Jun 2025 at 19:23, Zhang Yi yi.zhang@huaweicloud.com wrote:
Hi, Naresh!
On 2025/6/26 20:31, Naresh Kamboju wrote:
Regressions noticed on arm64 devices while running LTP syscalls mmap16 test case on the Linux next-20250616..next-20250626 with the extra build config fragment CONFIG_ARM64_64K_PAGES=y the kernel warning noticed.
Not reproducible with 4K page size.
Test environments:
- Dragonboard-410c
- Juno-r2
- rk3399-rock-pi-4b
- qemu-arm64
Regression Analysis:
- New regression? Yes
- Reproducibility? Yes
Test regression: next-20250626 LTP mmap16 WARNING fs jbd2 transaction.c start_this_handle
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Thank you for the report. The block size for this test is 1 KB, so I suspect this is the issue with insufficient journal credits that we are going to resolve.
I have applied your patch set [1] and tested and the reported regressions did not fix. Am I missing anything ?
[1] https://lore.kernel.org/linux-ext4/20250611111625.1668035-1-yi.zhang@huaweic...
I can also reproduce the similar warning with xfstests generic/730 under 64k page size + 4k block size.
Thanks, Joseph
On 2025/7/3 18:47, Joseph Qi wrote:
On 2025/7/3 15:26, Naresh Kamboju wrote:
On Thu, 26 Jun 2025 at 19:23, Zhang Yi yi.zhang@huaweicloud.com wrote:
Hi, Naresh!
On 2025/6/26 20:31, Naresh Kamboju wrote:
Regressions noticed on arm64 devices while running LTP syscalls mmap16 test case on the Linux next-20250616..next-20250626 with the extra build config fragment CONFIG_ARM64_64K_PAGES=y the kernel warning noticed.
Not reproducible with 4K page size.
Test environments:
- Dragonboard-410c
- Juno-r2
- rk3399-rock-pi-4b
- qemu-arm64
Regression Analysis:
- New regression? Yes
- Reproducibility? Yes
Test regression: next-20250626 LTP mmap16 WARNING fs jbd2 transaction.c start_this_handle
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Thank you for the report. The block size for this test is 1 KB, so I suspect this is the issue with insufficient journal credits that we are going to resolve.
I have applied your patch set [1] and tested and the reported regressions did not fix. Am I missing anything ?
[1] https://lore.kernel.org/linux-ext4/20250611111625.1668035-1-yi.zhang@huaweic...
I can also reproduce the similar warning with xfstests generic/730 under 64k page size + 4k block size.
Hi, Joseph!
I cannot reproduce this issue on my machine. Theoretically, the 'rsv_credits' should be 113 under 64k page size + 4k block size, I don't think it would exceed the max user trans buffers. Could you please give more details? What is the configuration of your xfstests? and what does the specific error log look like?
Thanks, Yi.
On 2025/7/5 15:10, Zhang Yi wrote:
On 2025/7/3 18:47, Joseph Qi wrote:
On 2025/7/3 15:26, Naresh Kamboju wrote:
On Thu, 26 Jun 2025 at 19:23, Zhang Yi yi.zhang@huaweicloud.com wrote:
Hi, Naresh!
On 2025/6/26 20:31, Naresh Kamboju wrote:
Regressions noticed on arm64 devices while running LTP syscalls mmap16 test case on the Linux next-20250616..next-20250626 with the extra build config fragment CONFIG_ARM64_64K_PAGES=y the kernel warning noticed.
Not reproducible with 4K page size.
Test environments:
- Dragonboard-410c
- Juno-r2
- rk3399-rock-pi-4b
- qemu-arm64
Regression Analysis:
- New regression? Yes
- Reproducibility? Yes
Test regression: next-20250626 LTP mmap16 WARNING fs jbd2 transaction.c start_this_handle
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Thank you for the report. The block size for this test is 1 KB, so I suspect this is the issue with insufficient journal credits that we are going to resolve.
I have applied your patch set [1] and tested and the reported regressions did not fix. Am I missing anything ?
[1] https://lore.kernel.org/linux-ext4/20250611111625.1668035-1-yi.zhang@huaweic...
I can also reproduce the similar warning with xfstests generic/730 under 64k page size + 4k block size.
Hi, Joseph!
I cannot reproduce this issue on my machine. Theoretically, the 'rsv_credits' should be 113 under 64k page size + 4k block size, I don't think it would exceed the max user trans buffers. Could you please give more details? What is the configuration of your xfstests? and what does the specific error log look like?
I'm testing on arm 64K ECS with xfstests local.config as follows:
export TEST_DEV=/dev/nvme1n1p1 export TEST_DIR=/mnt/test export SCRATCH_DEV=/dev/nvme1n1p2 export SCRATCH_MNT=/mnt/scratch
Each disk part is 250G and formated with 4k block size.
The dmesg shows the following warning:
[ 137.174661] JBD2: kworker/u32:0 wants too many credits credits:32 rsv_credits:1577 max:2695 ... [ 137.175544] Call trace: [ 137.175545] start_this_handle+0x3bc/0x3d8 (P) [ 137.175548] jbd2__journal_start+0x10c/0x248 [ 137.175550] __ext4_journal_start_sb+0xe4/0x1b0 [ 137.175553] ext4_do_writepages+0x430/0x768 [ 137.175556] ext4_writepages+0x8c/0x118 [ 137.175558] do_writepages+0xac/0x180 [ 137.175561] __writeback_single_inode+0x48/0x328 [ 137.175563] writeback_sb_inodes+0x244/0x4a0 [ 137.175564] wb_writeback+0xec/0x3a0 [ 137.175566] wb_do_writeback+0xc0/0x250 [ 137.175568] wb_workfn+0x70/0x1b0 [ 137.175570] process_one_work+0x180/0x400 [ 137.175573] worker_thread+0x254/0x2c8 [ 137.175575] kthread+0x124/0x130 [ 137.175577] ret_from_fork+0x10/0x20 ...
On 2025/7/7 9:43, Joseph Qi wrote:
On 2025/7/5 15:10, Zhang Yi wrote:
On 2025/7/3 18:47, Joseph Qi wrote:
On 2025/7/3 15:26, Naresh Kamboju wrote:
On Thu, 26 Jun 2025 at 19:23, Zhang Yi yi.zhang@huaweicloud.com wrote:
Hi, Naresh!
On 2025/6/26 20:31, Naresh Kamboju wrote:
Regressions noticed on arm64 devices while running LTP syscalls mmap16 test case on the Linux next-20250616..next-20250626 with the extra build config fragment CONFIG_ARM64_64K_PAGES=y the kernel warning noticed.
Not reproducible with 4K page size.
Test environments:
- Dragonboard-410c
- Juno-r2
- rk3399-rock-pi-4b
- qemu-arm64
Regression Analysis:
- New regression? Yes
- Reproducibility? Yes
Test regression: next-20250626 LTP mmap16 WARNING fs jbd2 transaction.c start_this_handle
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Thank you for the report. The block size for this test is 1 KB, so I suspect this is the issue with insufficient journal credits that we are going to resolve.
I have applied your patch set [1] and tested and the reported regressions did not fix. Am I missing anything ?
[1] https://lore.kernel.org/linux-ext4/20250611111625.1668035-1-yi.zhang@huaweic...
I can also reproduce the similar warning with xfstests generic/730 under 64k page size + 4k block size.
Hi, Joseph!
I cannot reproduce this issue on my machine. Theoretically, the 'rsv_credits' should be 113 under 64k page size + 4k block size, I don't think it would exceed the max user trans buffers. Could you please give more details? What is the configuration of your xfstests? and what does the specific error log look like?
I'm testing on arm 64K ECS with xfstests local.config as follows:
export TEST_DEV=/dev/nvme1n1p1 export TEST_DIR=/mnt/test export SCRATCH_DEV=/dev/nvme1n1p2 export SCRATCH_MNT=/mnt/scratch
Each disk part is 250G and formated with 4k block size.
The dmesg shows the following warning:
[ 137.174661] JBD2: kworker/u32:0 wants too many credits credits:32 rsv_credits:1577 max:2695 ... [ 137.175544] Call trace: [ 137.175545] start_this_handle+0x3bc/0x3d8 (P) [ 137.175548] jbd2__journal_start+0x10c/0x248 [ 137.175550] __ext4_journal_start_sb+0xe4/0x1b0 [ 137.175553] ext4_do_writepages+0x430/0x768 [ 137.175556] ext4_writepages+0x8c/0x118 [ 137.175558] do_writepages+0xac/0x180 [ 137.175561] __writeback_single_inode+0x48/0x328 [ 137.175563] writeback_sb_inodes+0x244/0x4a0 [ 137.175564] wb_writeback+0xec/0x3a0 [ 137.175566] wb_do_writeback+0xc0/0x250 [ 137.175568] wb_workfn+0x70/0x1b0 [ 137.175570] process_one_work+0x180/0x400 [ 137.175573] worker_thread+0x254/0x2c8 [ 137.175575] kthread+0x124/0x130 [ 137.175577] ret_from_fork+0x10/0x20 ...
OK, well. Since you did not specifically set MKFS_OPTIONS="-b 4096, the generic/730 will use scsi_debug to create a file system image with a size of 256MB, a block size of 1KB, and a log size of 8MB. Consequently, the issue did not actually occur in a 4KB block size environment, so the root cause is the same as Naresh's report.
Thanks, Yi.
On 2025/7/3 15:26, Naresh Kamboju wrote:
On Thu, 26 Jun 2025 at 19:23, Zhang Yi yi.zhang@huaweicloud.com wrote:
Hi, Naresh!
On 2025/6/26 20:31, Naresh Kamboju wrote:
Regressions noticed on arm64 devices while running LTP syscalls mmap16 test case on the Linux next-20250616..next-20250626 with the extra build config fragment CONFIG_ARM64_64K_PAGES=y the kernel warning noticed.
Not reproducible with 4K page size.
Test environments:
- Dragonboard-410c
- Juno-r2
- rk3399-rock-pi-4b
- qemu-arm64
Regression Analysis:
- New regression? Yes
- Reproducibility? Yes
Test regression: next-20250626 LTP mmap16 WARNING fs jbd2 transaction.c start_this_handle
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Thank you for the report. The block size for this test is 1 KB, so I suspect this is the issue with insufficient journal credits that we are going to resolve.
I have applied your patch set [1] and tested and the reported regressions did not fix. Am I missing anything ?
[1] https://lore.kernel.org/linux-ext4/20250611111625.1668035-1-yi.zhang@huaweic...
Hmm. It seems that my fix for the insufficient journal credit series cannot handle cases with a page size of 64k. The problem is the folio size can up to 128M, and the 'rsv_blocks' in ext4_do_writepages() can up to 1577 on 1K block size filesystems, this is too large.
Therefore, at this time, I think we should disable the large folio support for 64K page size. Then, we may need to reserve rsv_blocks for one extent and implement the same journal extension logic for reserved credits.
Ted and Jan, what do you think?
Thanks, Yi.
## Test log <6>[ 89.498969] loop0: detected capacity change from 0 to 614400 <3>[ 89.609561] operation not supported error, dev loop0, sector 20352 op 0x9:(WRITE_ZEROES) flags 0x20000800 phys_seg 0 prio class 0 <6>[ 89.707795] EXT4-fs (loop0): mounted filesystem 6786a191-5e0d-472b-8bce-4714e1a4fb44 r/w with ordered data mode. Quota mode: none. <3>[ 90.023985] JBD2: kworker/u8:2 wants too many credits credits:416 rsv_credits:21 max:334 <4>[ 90.024973] ------------[ cut here ]------------ <4>[ 90.025062] WARNING: fs/jbd2/transaction.c:334 at start_this_handle+0x4c0/0x4e0, CPU#0: 2/42 <4>[ 90.026661] Modules linked in: btrfs blake2b_generic xor xor_neon raid6_pq zstd_compress sm3_ce sha3_ce fuse drm backlight ip_tables x_tables <4>[ 90.027952] CPU: 0 UID: 0 PID: 42 Comm: kworker/u8:2 Not tainted 6.16.0-rc3-next-20250626 #1 PREEMPT <4>[ 90.029043] Hardware name: linux,dummy-virt (DT) <4>[ 90.029524] Workqueue: writeback wb_workfn (flush-7:0) <4>[ 90.030050] pstate: 63402009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) <4>[ 90.030311] pc : start_this_handle (fs/jbd2/transaction.c:334 (discriminator 1)) <4>[ 90.030481] lr : start_this_handle (fs/jbd2/transaction.c:334 (discriminator 1)) <4>[ 90.030656] sp : ffffc000805cb650 <4>[ 90.030785] x29: ffffc000805cb690 x28: fff00000dd1f5000 x27: ffffde2ec0272000 <4>[ 90.031097] x26: 00000000000001a0 x25: 0000000000000015 x24: 0000000000000002 <4>[ 90.031360] x23: 0000000000000015 x22: 0000000000000c40 x21: 0000000000000008 <4>[ 90.031618] x20: fff00000c231da78 x19: fff00000c231da78 x18: 0000000000000000 <4>[ 90.031875] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 <4>[ 90.032859] x14: 0000000000000000 x13: 00000000ffffffff x12: 0000000000000000 <4>[ 90.033225] x11: 0000000000000000 x10: ffffde2ebfba8bd0 x9 : ffffde2ebd34e944 <4>[ 90.033607] x8 : ffffc000805cb278 x7 : 0000000000000000 x6 : 0000000000000001 <4>[ 90.033971] x5 : ffffde2ebfb29000 x4 : ffffde2ebfb293d0 x3 : 0000000000000000 <4>[ 90.034294] x2 : 0000000000000000 x1 : fff00000c04dc080 x0 : 000000000000004c <4>[ 90.034772] Call trace: <4>[ 90.035068] start_this_handle (fs/jbd2/transaction.c:334 (discriminator 1)) (P) <4>[ 90.035366] jbd2__journal_start (fs/jbd2/transaction.c:501) <4>[ 90.035586] __ext4_journal_start_sb (fs/ext4/ext4_jbd2.c:117) <4>[ 90.035807] ext4_do_writepages (fs/ext4/ext4_jbd2.h:242 fs/ext4/inode.c:2846) <4>[ 90.036004] ext4_writepages (fs/ext4/inode.c:2953) <4>[ 90.036233] do_writepages (mm/page-writeback.c:2636) <4>[ 90.036406] __writeback_single_inode (fs/fs-writeback.c:1680) <4>[ 90.036616] writeback_sb_inodes (fs/fs-writeback.c:1978) <4>[ 90.036891] wb_writeback (fs/fs-writeback.c:2156) <4>[ 90.037122] wb_workfn (fs/fs-writeback.c:2303 (discriminator 1) fs/fs-writeback.c:2343 (discriminator 1)) <4>[ 90.037318] process_one_work (kernel/workqueue.c:3244) <4>[ 90.037517] worker_thread (kernel/workqueue.c:3316 (discriminator 2) kernel/workqueue.c:3403 (discriminator 2)) <4>[ 90.037752] kthread (kernel/kthread.c:463) <4>[ 90.037903] ret_from_fork (arch/arm64/kernel/entry.S:863) <4>[ 90.038217] ---[ end trace 0000000000000000 ]--- <2>[ 90.039950] EXT4-fs (loop0): ext4_do_writepages: jbd2_start: 9223372036854775807 pages, ino 14; err -28 <3>[ 90.040291] JBD2: kworker/u8:2 wants too many credits credits:416 rsv_credits:21 max:334 <4>[ 90.040374] ------------[ cut here ]------------ <4>[ 90.040386] WARNING: fs/jbd2/transaction.c:334 at start_this_handle+0x4c0/0x4e0, CPU#1: 2/42
## Source
- Kernel version: 6.16.0-rc3-next-20250626
- Git tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git
- Git sha: ecb259c4f70dd5c83907809f45bf4dc6869961d7
- Git describe: 6.16.0-rc3-next-20250626
- Project details:
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20250626/
- Architectures: arm64
- Toolchains: gcc-13
- Kconfigs: gcc-13-lkftconfig-64k_page_size
## Build arm64
- Test log: https://qa-reports.linaro.org/api/testruns/28894530/log_file/
- Test LAVA log 1:
https://lkft.validation.linaro.org/scheduler/job/8331353#L6841
- Test LAVA log 2:
https://lkft.validation.linaro.org/scheduler/job/8331352#L8854
- Test details:
https://regressions.linaro.org/lkft/linux-next-master/next-20250626/log-pars...
- Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObV...
- Kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObV...
-- Linaro LKFT https://lkft.linaro.org
On Thu 03-07-25 19:33:32, Zhang Yi wrote:
On 2025/7/3 15:26, Naresh Kamboju wrote:
On Thu, 26 Jun 2025 at 19:23, Zhang Yi yi.zhang@huaweicloud.com wrote:
On 2025/6/26 20:31, Naresh Kamboju wrote:
Regressions noticed on arm64 devices while running LTP syscalls mmap16 test case on the Linux next-20250616..next-20250626 with the extra build config fragment CONFIG_ARM64_64K_PAGES=y the kernel warning noticed.
Not reproducible with 4K page size.
Test environments:
- Dragonboard-410c
- Juno-r2
- rk3399-rock-pi-4b
- qemu-arm64
Regression Analysis:
- New regression? Yes
- Reproducibility? Yes
Test regression: next-20250626 LTP mmap16 WARNING fs jbd2 transaction.c start_this_handle
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Thank you for the report. The block size for this test is 1 KB, so I suspect this is the issue with insufficient journal credits that we are going to resolve.
I have applied your patch set [1] and tested and the reported regressions did not fix. Am I missing anything ?
[1] https://lore.kernel.org/linux-ext4/20250611111625.1668035-1-yi.zhang@huaweic...
Hmm. It seems that my fix for the insufficient journal credit series cannot handle cases with a page size of 64k. The problem is the folio size can up to 128M, and the 'rsv_blocks' in ext4_do_writepages() can up to 1577 on 1K block size filesystems, this is too large.
Firstly, I think that 128M folios are too big for our current approaches (in ext4 at least) to sensibly work. Maybe we could limit max folio order in ext4 mappings to max 1024 blocks per folio or something like that? For realistic setups with 4k blocksize this means 4M folios which is not really limiting for x86. Arm64 or ppc64 could do bigger but the gain for even larger folios is diminishingly small anyway.
Secondly, I'm wondering that even with 1577 reserved blocks we shouldn't really overflow the journal unless you make it really small. But maybe that's what the test does...
Therefore, at this time, I think we should disable the large folio support for 64K page size. Then, we may need to reserve rsv_blocks for one extent and implement the same journal extension logic for reserved credits.
Ted and Jan, what do you think?
I wouldn't really disable it for 64K page size. I'd rather limit max folio order to 1024 blocks. That actually makes sense as a general limitation of our current implementation (linked lists of bhs in each folio don't really scale). We can use mapping_set_folio_order_range() for that instead of mapping_set_large_folios().
Honza
On 2025/7/4 19:17, Jan Kara wrote:
On Thu 03-07-25 19:33:32, Zhang Yi wrote:
On 2025/7/3 15:26, Naresh Kamboju wrote:
On Thu, 26 Jun 2025 at 19:23, Zhang Yi yi.zhang@huaweicloud.com wrote:
On 2025/6/26 20:31, Naresh Kamboju wrote:
Regressions noticed on arm64 devices while running LTP syscalls mmap16 test case on the Linux next-20250616..next-20250626 with the extra build config fragment CONFIG_ARM64_64K_PAGES=y the kernel warning noticed.
Not reproducible with 4K page size.
Test environments:
- Dragonboard-410c
- Juno-r2
- rk3399-rock-pi-4b
- qemu-arm64
Regression Analysis:
- New regression? Yes
- Reproducibility? Yes
Test regression: next-20250626 LTP mmap16 WARNING fs jbd2 transaction.c start_this_handle
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Thank you for the report. The block size for this test is 1 KB, so I suspect this is the issue with insufficient journal credits that we are going to resolve.
I have applied your patch set [1] and tested and the reported regressions did not fix. Am I missing anything ?
[1] https://lore.kernel.org/linux-ext4/20250611111625.1668035-1-yi.zhang@huaweic...
Hmm. It seems that my fix for the insufficient journal credit series cannot handle cases with a page size of 64k. The problem is the folio size can up to 128M, and the 'rsv_blocks' in ext4_do_writepages() can up to 1577 on 1K block size filesystems, this is too large.
Firstly, I think that 128M folios are too big for our current approaches (in ext4 at least) to sensibly work. Maybe we could limit max folio order in ext4 mappings to max 1024 blocks per folio or something like that? For realistic setups with 4k blocksize this means 4M folios which is not really limiting for x86. Arm64 or ppc64 could do bigger but the gain for even larger folios is diminishingly small anyway.
Yeah, I agree.
Secondly, I'm wondering that even with 1577 reserved blocks we shouldn't really overflow the journal unless you make it really small. But maybe that's what the test does...
Yes, the test creates a filesystem image with a block size of 1 KB and a journal consisting of 1024 blocks.
Therefore, at this time, I think we should disable the large folio support for 64K page size. Then, we may need to reserve rsv_blocks for one extent and implement the same journal extension logic for reserved credits.
Ted and Jan, what do you think?
I wouldn't really disable it for 64K page size. I'd rather limit max folio order to 1024 blocks. That actually makes sense as a general limitation of our current implementation (linked lists of bhs in each folio don't really scale). We can use mapping_set_folio_order_range() for that instead of mapping_set_large_folios().
Indeed, after noticing that Btrfs also calls mapping_set_folio_order_range() to set the maximum size of a folio, I thought this solution should work. So I changed my mind and was going to try this solution. However, I guess limit max folio order to 1024 blocks is somewhat too small. I'd like to limit the order to 2048 blocks, because this this allows a file system with a 1KB block size to achieve a maximum folio size to PMD size in x86 with a 4KB page size, this is useful for increase the TLB efficiency and reduce page fault handling overhead.
I defined a new macro, something like this:
/* * Limit the maximum folio order to 2048 blocks to prevent overestimation * of reserve handle credits during the folio writeback in environments * where the PAGE_SIZE exceeds 4KB. */ #define EXT4_MAX_PAGECACHE_ORDER(i) \ min(MAX_PAGECACHE_ORDER, (11 + (i)->i_blkbits - PAGE_SIZE))
What do you think?
Best regards, Yi.
On Mon 07-07-25 12:54:56, Zhang Yi wrote:
On 2025/7/4 19:17, Jan Kara wrote:
I wouldn't really disable it for 64K page size. I'd rather limit max folio order to 1024 blocks. That actually makes sense as a general limitation of our current implementation (linked lists of bhs in each folio don't really scale). We can use mapping_set_folio_order_range() for that instead of mapping_set_large_folios().
Indeed, after noticing that Btrfs also calls mapping_set_folio_order_range() to set the maximum size of a folio, I thought this solution should work. So I changed my mind and was going to try this solution. However, I guess limit max folio order to 1024 blocks is somewhat too small. I'd like to limit the order to 2048 blocks, because this this allows a file system with a 1KB block size to achieve a maximum folio size to PMD size in x86 with a 4KB page size, this is useful for increase the TLB efficiency and reduce page fault handling overhead.
OK. In my opinion whoever runs with 1k blocksize doesn't really care about performance too much and thus is unlikely to care about getting 2M pages :). But whatever, the limit of 2048 blocks is fine by me.
I defined a new macro, something like this:
/*
- Limit the maximum folio order to 2048 blocks to prevent overestimation
- of reserve handle credits during the folio writeback in environments
- where the PAGE_SIZE exceeds 4KB.
*/ #define EXT4_MAX_PAGECACHE_ORDER(i) \ min(MAX_PAGECACHE_ORDER, (11 + (i)->i_blkbits - PAGE_SIZE))
^^^ PAGE_SHIFT
Otherwise looks good to me.
Honza
On 2025/7/3 15:26, Naresh Kamboju wrote:
On Thu, 26 Jun 2025 at 19:23, Zhang Yi yi.zhang@huaweicloud.com wrote:
Hi, Naresh!
On 2025/6/26 20:31, Naresh Kamboju wrote:
Regressions noticed on arm64 devices while running LTP syscalls mmap16 test case on the Linux next-20250616..next-20250626 with the extra build config fragment CONFIG_ARM64_64K_PAGES=y the kernel warning noticed.
Not reproducible with 4K page size.
Test environments:
- Dragonboard-410c
- Juno-r2
- rk3399-rock-pi-4b
- qemu-arm64
Regression Analysis:
- New regression? Yes
- Reproducibility? Yes
Test regression: next-20250626 LTP mmap16 WARNING fs jbd2 transaction.c start_this_handle
Reported-by: Linux Kernel Functional Testing lkft@linaro.org
Thank you for the report. The block size for this test is 1 KB, so I suspect this is the issue with insufficient journal credits that we are going to resolve.
I have applied your patch set [1] and tested and the reported regressions did not fix. Am I missing anything ?
[1] https://lore.kernel.org/linux-ext4/20250611111625.1668035-1-yi.zhang@huaweic...
Hi, Naresh and Joseph!
Thanks to Jan's assistance, I've fixed this issue in my latest series and both tests passed on my machine. Could you please give it a try?
https://lore.kernel.org/linux-ext4/20250707140814.542883-1-yi.zhang@huaweicl...
Thanks, Yi.
## Test log <6>[ 89.498969] loop0: detected capacity change from 0 to 614400 <3>[ 89.609561] operation not supported error, dev loop0, sector 20352 op 0x9:(WRITE_ZEROES) flags 0x20000800 phys_seg 0 prio class 0 <6>[ 89.707795] EXT4-fs (loop0): mounted filesystem 6786a191-5e0d-472b-8bce-4714e1a4fb44 r/w with ordered data mode. Quota mode: none. <3>[ 90.023985] JBD2: kworker/u8:2 wants too many credits credits:416 rsv_credits:21 max:334 <4>[ 90.024973] ------------[ cut here ]------------ <4>[ 90.025062] WARNING: fs/jbd2/transaction.c:334 at start_this_handle+0x4c0/0x4e0, CPU#0: 2/42 <4>[ 90.026661] Modules linked in: btrfs blake2b_generic xor xor_neon raid6_pq zstd_compress sm3_ce sha3_ce fuse drm backlight ip_tables x_tables <4>[ 90.027952] CPU: 0 UID: 0 PID: 42 Comm: kworker/u8:2 Not tainted 6.16.0-rc3-next-20250626 #1 PREEMPT <4>[ 90.029043] Hardware name: linux,dummy-virt (DT) <4>[ 90.029524] Workqueue: writeback wb_workfn (flush-7:0) <4>[ 90.030050] pstate: 63402009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) <4>[ 90.030311] pc : start_this_handle (fs/jbd2/transaction.c:334 (discriminator 1)) <4>[ 90.030481] lr : start_this_handle (fs/jbd2/transaction.c:334 (discriminator 1)) <4>[ 90.030656] sp : ffffc000805cb650 <4>[ 90.030785] x29: ffffc000805cb690 x28: fff00000dd1f5000 x27: ffffde2ec0272000 <4>[ 90.031097] x26: 00000000000001a0 x25: 0000000000000015 x24: 0000000000000002 <4>[ 90.031360] x23: 0000000000000015 x22: 0000000000000c40 x21: 0000000000000008 <4>[ 90.031618] x20: fff00000c231da78 x19: fff00000c231da78 x18: 0000000000000000 <4>[ 90.031875] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 <4>[ 90.032859] x14: 0000000000000000 x13: 00000000ffffffff x12: 0000000000000000 <4>[ 90.033225] x11: 0000000000000000 x10: ffffde2ebfba8bd0 x9 : ffffde2ebd34e944 <4>[ 90.033607] x8 : ffffc000805cb278 x7 : 0000000000000000 x6 : 0000000000000001 <4>[ 90.033971] x5 : ffffde2ebfb29000 x4 : ffffde2ebfb293d0 x3 : 0000000000000000 <4>[ 90.034294] x2 : 0000000000000000 x1 : fff00000c04dc080 x0 : 000000000000004c <4>[ 90.034772] Call trace: <4>[ 90.035068] start_this_handle (fs/jbd2/transaction.c:334 (discriminator 1)) (P) <4>[ 90.035366] jbd2__journal_start (fs/jbd2/transaction.c:501) <4>[ 90.035586] __ext4_journal_start_sb (fs/ext4/ext4_jbd2.c:117) <4>[ 90.035807] ext4_do_writepages (fs/ext4/ext4_jbd2.h:242 fs/ext4/inode.c:2846) <4>[ 90.036004] ext4_writepages (fs/ext4/inode.c:2953) <4>[ 90.036233] do_writepages (mm/page-writeback.c:2636) <4>[ 90.036406] __writeback_single_inode (fs/fs-writeback.c:1680) <4>[ 90.036616] writeback_sb_inodes (fs/fs-writeback.c:1978) <4>[ 90.036891] wb_writeback (fs/fs-writeback.c:2156) <4>[ 90.037122] wb_workfn (fs/fs-writeback.c:2303 (discriminator 1) fs/fs-writeback.c:2343 (discriminator 1)) <4>[ 90.037318] process_one_work (kernel/workqueue.c:3244) <4>[ 90.037517] worker_thread (kernel/workqueue.c:3316 (discriminator 2) kernel/workqueue.c:3403 (discriminator 2)) <4>[ 90.037752] kthread (kernel/kthread.c:463) <4>[ 90.037903] ret_from_fork (arch/arm64/kernel/entry.S:863) <4>[ 90.038217] ---[ end trace 0000000000000000 ]--- <2>[ 90.039950] EXT4-fs (loop0): ext4_do_writepages: jbd2_start: 9223372036854775807 pages, ino 14; err -28 <3>[ 90.040291] JBD2: kworker/u8:2 wants too many credits credits:416 rsv_credits:21 max:334 <4>[ 90.040374] ------------[ cut here ]------------ <4>[ 90.040386] WARNING: fs/jbd2/transaction.c:334 at start_this_handle+0x4c0/0x4e0, CPU#1: 2/42
## Source
- Kernel version: 6.16.0-rc3-next-20250626
- Git tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/next/linux-next.git
- Git sha: ecb259c4f70dd5c83907809f45bf4dc6869961d7
- Git describe: 6.16.0-rc3-next-20250626
- Project details:
https://qa-reports.linaro.org/lkft/linux-next-master/build/next-20250626/
- Architectures: arm64
- Toolchains: gcc-13
- Kconfigs: gcc-13-lkftconfig-64k_page_size
## Build arm64
- Test log: https://qa-reports.linaro.org/api/testruns/28894530/log_file/
- Test LAVA log 1:
https://lkft.validation.linaro.org/scheduler/job/8331353#L6841
- Test LAVA log 2:
https://lkft.validation.linaro.org/scheduler/job/8331352#L8854
- Test details:
https://regressions.linaro.org/lkft/linux-next-master/next-20250626/log-pars...
- Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObV...
- Kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObV...
-- Linaro LKFT https://lkft.linaro.org
-
Jan Kara -
Joseph Qi -
Naresh Kamboju -
Zhang Yi