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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <mxmnbr6gni2lupljf7pzkhs6f3hynr2lq2nshbgcmzg77jduwk@wn76alaoxjts>
Date: Tue, 15 Apr 2025 18:28:55 +0200
From: Jan Kara <jack@...e.cz>
To: Luis Chamberlain <mcgrof@...nel.org>
Cc: Jan Kara <jack@...e.cz>, brauner@...nel.org, tytso@....edu, 
	adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org, riel@...riel.com, dave@...olabs.net, 
	willy@...radead.org, hannes@...xchg.org, oliver.sang@...el.com, david@...hat.com, 
	axboe@...nel.dk, hare@...e.de, david@...morbit.com, djwong@...nel.org, 
	ritesh.list@...il.com, linux-fsdevel@...r.kernel.org, linux-block@...r.kernel.org, 
	linux-mm@...ck.org, gost.dev@...sung.com, p.raghav@...sung.com, da.gomez@...sung.com, 
	syzbot+f3c6fda1297c748a7076@...kaller.appspotmail.com
Subject: Re: [PATCH v2 1/8] migrate: fix skipping metadata buffer heads on
 migration

On Tue 15-04-25 09:18:10, Luis Chamberlain wrote:
> On Thu, Apr 10, 2025 at 02:05:38PM +0200, Jan Kara wrote:
> > On Wed 09-04-25 18:49:38, Luis Chamberlain wrote:
> > > ** Reproduced on vanilla Linux with udelay(2000) **
> > > 
> > > Call trace (ENOSPC journal failure):
> > >   do_writepages()
> > >     → ext4_do_writepages()
> > >       → ext4_map_blocks()
> > >         → ext4_ext_map_blocks()
> > >           → ext4_ext_insert_extent()
> > >             → __ext4_handle_dirty_metadata()
> > >               → jbd2_journal_dirty_metadata() → ERROR -28 (ENOSPC)
> > 
> > Curious. Did you try running e2fsck after the filesystem complained like
> > this? This complains about journal handle not having enough credits for
> > needed metadata update. Either we've lost some update to the journal_head
> > structure (b_modified got accidentally cleared) or some update to extent
> > tree.
> 
> Just tried it after pkill fsstress and stopping the test:
> 
> root@...ext4-2k /var/lib/xfstests # umount /dev/loop5
> root@...ext4-2k /var/lib/xfstests # fsck /dev/loop5
> fsck from util-linux 2.41
> e2fsck 1.47.2 (1-Jan-2025)
> /dev/loop5 contains a file system with errors, check forced.
> Pass 1: Checking inodes, blocks, and sizes
> Inode 26 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 129 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 592 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 1095 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 1416 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 1653 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 1929 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 1965 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 2538 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 2765 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 2831 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 2838 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 3595 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 4659 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 5268 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 6400 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 6830 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 8490 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 8555 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 8658 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 8754 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 8996 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 9168 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 9430 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 9468 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 9543 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 9632 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 9746 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 10043 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 10280 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 10623 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 10651 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 10691 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 10708 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 11389 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 11564 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 11578 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 11842 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 11900 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> yInode 12721 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 12831 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> yInode 13531 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> yyyyInode 16580 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 16740 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> yInode 17123 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> yInode 17192 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 17412 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 17519 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> yyInode 18730 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 18974 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 19118 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> yyInode 19806 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 19942 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 20303 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 20323 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 21047 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 21919 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 22180 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 22856 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 23462 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 23587 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 23775 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 23916 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 24046 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 24161 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> yInode 25576 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 25666 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 25992 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 26404 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 26795 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 26862 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 26868 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> yInode 27627 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 27959 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 28014 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> yInode 29120 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 29308 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> yyyyInode 30673 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> yInode 31127 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 31332 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 31547 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> yyInode 32727 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 32888 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 33062 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> yyyInode 34421 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 34508 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> yyyyInode 35996 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 36258 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> yyInode 36867 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 37166 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 37171 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 37548 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 37732 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> yInode 38028 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> Inode 38099 extent tree (at level 1) could be shorter.  Optimize<y>? yes
> ....

These are harmless. They are not errors, just opportunities for
optimization of the extent tree e2fsck can make.

> So I tried:
> 
> root@...ext4-2k /var/lib/xfstests # fsck /dev/loop5 -y 2>&1 > log
> e2fsck 1.47.2 (1-Jan-2025)
> root@...ext4-2k /var/lib/xfstests # wc -l log
> 16411 log

Can you share the log please?

> root@...ext4-2k /var/lib/xfstests # tail log
> 
> Free blocks count wrong for group #609 (62, counted=63).
> Fix? yes
> 
> Free blocks count wrong (12289, counted=12293).
> Fix? yes

These could potentially indicate some interesting issues but it depends on
what the above e2fsck messages are...

								Honza
-- 
Jan Kara <jack@...e.com>
SUSE Labs, CR

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ