[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1c7ae5cb-61ad-404c-950a-ba1b5895e6c3@huaweicloud.com>
Date: Thu, 3 Jul 2025 19:33:32 +0800
From: Zhang Yi <yi.zhang@...weicloud.com>
To: Naresh Kamboju <naresh.kamboju@...aro.org>, Theodore Ts'o
<tytso@....edu>, Jan Kara <jack@...e.cz>
Cc: linux-ext4 <linux-ext4@...r.kernel.org>, linux-fsdevel@...r.kernel.org,
open list <linux-kernel@...r.kernel.org>, lkft-triage@...ts.linaro.org,
Linux Regressions <regressions@...ts.linux.dev>,
LTP List <ltp@...ts.linux.it>, Anders Roxell <anders.roxell@...aro.org>,
Dan Carpenter <dan.carpenter@...aro.org>, Arnd Bergmann <arnd@...db.de>
Subject: Re: next-20250626: WARNING fs jbd2 transaction.c start_this_handle
with ARM64_64K_PAGES
On 2025/7/3 15:26, Naresh Kamboju wrote:
> On Thu, 26 Jun 2025 at 19:23, Zhang Yi <yi.zhang@...weicloud.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@...aro.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
>>>
>>
Powered by blists - more mailing lists