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-next>] [day] [month] [year] [list]
Message-ID: <CAFLxGvwnKKHOnM2w8i9hn7LTVYKh5PQP2zYMBmma2k9z7HBpzw@mail.gmail.com>
Date:   Sat, 11 May 2019 14:43:16 +0200
From:   Richard Weinberger <richard.weinberger@...il.com>
To:     Arthur Marsh <arthur.marsh@...ernode.on.net>
Cc:     LKML <linux-kernel@...r.kernel.org>, linux-ext4@...r.kernel.org
Subject: Re: ext3/ext4 filesystem corruption under post 5.1.0 kernels

[CC'in linux-ext4]

On Sat, May 11, 2019 at 1:47 PM Arthur Marsh
<arthur.marsh@...ernode.on.net> wrote:
>
> I have yet to bisect, but have had trouble with recent, post 5.1.0 kernels built from Linus' git head on both i386 (Pentium 4 pc) and amd64 (Athlon II X4 640).
>
> The easiest way to trigger the problem is:
>
> git gc
>
> on the kernel source tree, although the problem can occur without doing a git gc.
>
> The filesystem with the kernel source tree is the root file system, ext3, mounted as:
>
> /dev/sdb7 on / type ext3 (rw,relatime,errors=remount-ro)
>
> After the "Compressing objects" stage, the following appears in dmesg:
>
> [  848.968550] EXT4-fs error (device sdb7): ext4_get_branch:171: inode #8: block 30343695: comm jbd2/sdb7-8: invalid block
> [  849.077426] Aborting journal on device sdb7-8.
> [  849.100963] EXT4-fs (sdb7): Remounting filesystem read-only
> [  849.100976] jbd2_journal_bmap: journal block not found at offset 989 on sdb7-8
>
> fsck -yv
>
> then reports:
>
> # fsck -yv
> fsck from util-linux 2.33.1
> e2fsck 1.45.0 (6-Mar-2019)
> /dev/sdb7: recovering journal
> /dev/sdb7 contains a file system with errors, check forced.
> Pass 1: Checking inodes, blocks, and sizes
> Pass 2: Checking directory structure
> Pass 3: Checking directory connectivity
> Pass 4: Checking reference counts
> Pass 5: Checking group summary information
> Free blocks count wrong (4619656, counted=4619444).
> Fix? yes
>
> Free inodes count wrong (15884075, counted=15884058).
> Fix? yes
>
>
> /dev/sdb7: ***** FILE SYSTEM WAS MODIFIED *****
>
> Other times, I have gotten:
>
> "Inodes that were part of a corrupted orphan linked list found."
> "Block bitmap differences:"
> "Free blocks sound wrong for group"
>
> No problems have been observed with the 5.1.0 release kernel.
>
> Any suggestions for narrowing down the issue welcome.

Can you git-bisect it?

-- 
Thanks,
//richard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ