lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <c2dvcablaximwjnwg67spegwkntxjgezu6prvyyto4vjnx6rvh@w3xgx4jjq4bb> Date: Fri, 4 Jul 2025 13:17:02 +0200 From: Jan Kara <jack@...e.cz> To: Zhang Yi <yi.zhang@...weicloud.com> Cc: Naresh Kamboju <naresh.kamboju@...aro.org>, Theodore Ts'o <tytso@....edu>, Jan Kara <jack@...e.cz>, 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 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@...weicloud.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@...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. 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@...e.com> SUSE Labs, CR
Powered by blists - more mailing lists