linux-ext4 - Re: kernel BUG at fs/ext4/inode.c:1721!

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: <YWXWdlut+IW9eh8B@zn.tnic>
Date:   Tue, 12 Oct 2021 20:39:50 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Eric Whitney <enwlinux@...il.com>
Cc:     linux-ext4@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>,
        Theodore Ts'o <tytso@....edu>,
        Andreas Dilger <adilger.kernel@...ger.ca>
Subject: Re: kernel BUG at fs/ext4/inode.c:1721!

On Mon, Oct 11, 2021 at 07:11:24PM -0400, Eric Whitney wrote:
> I've tried numerous kernel builds with -rc4 and rerun the full set of xfstests
> we use when regressing ext4 each rc using a kernel that doesn't enable
> FS_ENCRYPTION (I normally run with that) without luck.  The code that caused
> the splat you saw is new and would run when an assertion is violated,
> suggesting that there may be an unsuspected bug elsewhere in ext4.

Hmm.

> Do you recall having seen any evidence of ENOMEM or ENOSPC conditions prior
> to the failure?

I don't see anything of the sorts in the dmesg I've saved.

> If you're willing to share, please send along your kernel config file and I'll
> try working with that as well.

Sure, I'll send you the config I used and the dmesg I caught privately -
you might see something I've missed. Stuff like this, for example:

[   10.254952] Adding 15721468k swap on /dev/nvme0n1p1.  Priority:-2 extents:1 across:15721468k SS
[   10.275365] EXT4-fs (nvme0n1p2): re-mounted. Opts: errors=remount-ro. Quota mode: disabled.
[   10.417820] device-mapper: ioctl: 4.45.0-ioctl (2021-03-22) initialised: dm-devel@...hat.com
[   10.595392] loop: module loaded
[   10.661742] EXT4-fs (sdc1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
[   10.758774] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
[   10.930331] r8169 0000:18:00.0 eth0: Link is Up - 100Mbps/Full - flow control rx/tx
[   10.939298] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   13.306747] EXT4-fs (sdb1): recovery complete
[   13.325960] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
[   13.353624] EXT4-fs (nvme1n1p1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.
[  191.896690] loop0: detected capacity change from 0 to 2048
[  191.941350] EXT4-fs (dm-0): mounting ext2 file system using the ext4 subsystem
[  191.948773] EXT4-fs (dm-0): mounted filesystem without journal. Opts: (null). Quota mode: disabled.
[  282.932355] fuse: init (API version 7.34)
[ 3159.620840] loop1: detected capacity change from 0 to 4194304
[ 3160.125963] EXT4-fs (dm-1): mounting ext3 file system using the ext4 subsystem
[ 3160.203143] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null). Quota mode: disabled.

Dunno if using ext4 to mount ext2 and ext3 filesystems would be
relevant.

> In the meantime, should this bug get in your way, just revert the following
> patch and you should be able to run without further trouble:
> 
> 948ca5f30e1d "ext4: enforce buffer head state assertion in ext4_da_map_blocks"
> 
> I'll likely be posting a patch to revert this shortly, since it's going to
> take some time to sort out what's going on without a reproducer.

Gotcha.

> Thanks again for your help,

Thanks too for taking a look.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette