[LTP] 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.