linux-ext4 - [Bug 195561] Suspicious persistent EXT4-fs error: ext4_validate_block_bitmap:395: [Proc] bg 17: block 557056: invalid block bitmap

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: <bug-195561-13602-m7zdzpoHtf@https.bugzilla.kernel.org/>
Date:   Sun, 30 Apr 2017 03:20:42 +0000
From:   bugzilla-daemon@...zilla.kernel.org
To:     linux-ext4@...nel.org
Subject: [Bug 195561] Suspicious persistent EXT4-fs error:
 ext4_validate_block_bitmap:395: [Proc] bg 17: block 557056: invalid block
 bitmap

https://bugzilla.kernel.org/show_bug.cgi?id=195561

--- Comment #24 from Theodore Tso (tytso@....edu) ---
Hmm, the original bug report said you are using Android 7.1.  Which I think was
still using make_ext4fs.   I really don't trust make_ext4fs farther than I can
throw it.   Something else to try --- use "dd if=/dev/zero of=/dev/sdXX" before
doing whatever you do to install the file system.   There are multiple ways of
calling into the  make_ext4fs codepaths (from fastboot, from the recovery
partition, as part of the build process), and some of them didn't work
correctly if the underlying storage device wasn't zero'ed out (as would be the
case if you were using flash and the DISCARD command, or the eMMC equivalent). 
 I wonder if the issue has to do with a slightly different way the file system
is getting set up on android-x86, and if you are using magnetic HDD's that
doesn't have discard, that might be way you're seeing it and other Android
developers aren't.

I got tired of getting pulled in to debug weird problems that were traced down
to make_ext4fs being fragile (it works fine writing to sparse files, since
uninitialized blocks in a sparse file are all zeroes), which is why I was very
happy to see Android switching over to use mke2fs, instead of make_ext4fs,
which was a clean-room implementation back in the day when some Android
management was overly paranoid about GPLv2 in userspace.  There were some rough
spots since mke2fs -d doesn't deal with SELinux and other Android specific
issues, which is why e2fsprogs/contrib/android exists in the AOSP version of
e2fsprogs.   (It's there in the upstream version of e2fsprogs, but there a
bunch of bug fixes in the AOSP version that haven't propagated back to the
upstream e2fsprogs repo yet.)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.