next-20250626: WARNING fs jbd2 transaction.c start_this_handle with ARM64_64K_PAGES

next-20250626: WARNING fs jbd2 transaction.c start_this_handle with ARM64_64K_PAGES

[Naresh Kamboju]

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-parser-test/exception-warning-fsjbd2transaction-at-start_this_handle/
* Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObVQTwoR1/
* Kernel config:
https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObVQTwoR1/config

--
Linaro LKFT
https://lkft.linaro.org

Re: next-20250626: WARNING fs jbd2 transaction.c start_this_handle with ARM64_64K_PAGES

[Zhang Yi]

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@huaweicloud.com/

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-parser-test/exception-warning-fsjbd2transaction-at-start_this_handle/
> * Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObVQTwoR1/
> * Kernel config:
> https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObVQTwoR1/config
> 
> --
> Linaro LKFT
> https://lkft.linaro.org
> 

Re: next-20250626: WARNING fs jbd2 transaction.c start_this_handle with ARM64_64K_PAGES

[Naresh Kamboju]

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@huaweicloud.com/

>
> 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-parser-test/exception-warning-fsjbd2transaction-at-start_this_handle/
> > * Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObVQTwoR1/
> > * Kernel config:
> > https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObVQTwoR1/config
> >
> > --
> > Linaro LKFT
> > https://lkft.linaro.org
> >
>

Re: next-20250626: WARNING fs jbd2 transaction.c start_this_handle with ARM64_64K_PAGES

[Joseph Qi]

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@huaweicloud.com/
> 

I can also reproduce the similar warning with xfstests generic/730 under
64k page size + 4k block size.

Thanks,
Joseph

Re: next-20250626: WARNING fs jbd2 transaction.c start_this_handle with ARM64_64K_PAGES

[Zhang 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@huaweicloud.com/
> 

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-parser-test/exception-warning-fsjbd2transaction-at-start_this_handle/
>>> * Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObVQTwoR1/
>>> * Kernel config:
>>> https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObVQTwoR1/config
>>>
>>> --
>>> Linaro LKFT
>>> https://lkft.linaro.org
>>>
>>

Re: next-20250626: WARNING fs jbd2 transaction.c start_this_handle with ARM64_64K_PAGES

[Jan Kara]

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@huaweicloud.com/
> > 
> 
> 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
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: next-20250626: WARNING fs jbd2 transaction.c start_this_handle with ARM64_64K_PAGES

[Zhang Yi]

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@huaweicloud.com/
>>
> 
> 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.

Re: next-20250626: WARNING fs jbd2 transaction.c start_this_handle with ARM64_64K_PAGES

[Joseph Qi]

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@huaweicloud.com/
>>>
>>
>> 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
...

Re: next-20250626: WARNING fs jbd2 transaction.c start_this_handle with ARM64_64K_PAGES

[Zhang Yi]

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@huaweicloud.com/
>>>
>>
>> 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.

Re: next-20250626: WARNING fs jbd2 transaction.c start_this_handle with ARM64_64K_PAGES

[Zhang Yi]

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@huaweicloud.com/
>>>>
>>>
>>> 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.

Re: next-20250626: WARNING fs jbd2 transaction.c start_this_handle with ARM64_64K_PAGES

[Jan Kara]

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
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: next-20250626: WARNING fs jbd2 transaction.c start_this_handle with ARM64_64K_PAGES

[Zhang 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@huaweicloud.com/
> 

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@huaweicloud.com/

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-parser-test/exception-warning-fsjbd2transaction-at-start_this_handle/
>>> * Build link: https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObVQTwoR1/
>>> * Kernel config:
>>> https://storage.tuxsuite.com/public/linaro/lkft/builds/2z2V7LhiJecGzINkU7ObVQTwoR1/config
>>>
>>> --
>>> Linaro LKFT
>>> https://lkft.linaro.org
>>>
>>
> 
>