Received-SPF: pass (google.com: best guess record for domain of linux-ext4-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <1562021070.2762.36.camel@HansenPartnership.com>
Subject: [BUG] mke2fs produces corrupt filesystem if badblock list contains
 a block under 251
From:   James Bottomley <James.Bottomley@HansenPartnership.com>
To:     linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org
Cc:     Parisc List <linux-parisc@vger.kernel.org>
Date:   Mon, 01 Jul 2019 15:44:30 -0700
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-ext4-owner@vger.kernel.org
Precedence: bulk

Background: we actually use the badblocks feature of the ext filesystem
group to do a poorman's boot filesystem for parisc: Our system chunks
up the disk searching for an Initial Program Loader (IPL) signature and
then executes it, so we poke a hole in an ext3 filesystem at creation
time and place the IPL into it.  Our IP can read ext3 files and
directories, so it allows us to load the kernel directly from the file.

The problem is that our IPL needs to be aligned at 256k in absolute
terms on the disk, so, in the usual situation of having a 64k partition
label and the boot partition being the first one we usually end up
poking the badblock hole beginning at block 224 (using a 1k block
size).

The problem is that this used to work long ago (where the value of long
seems to be some time before 2011) but no longer does.  The problem can
be illustrated simply by doing

---
# dd if=/dev/zero of=bbtest.img bs=1M count=100
# losetup /dev/loop0 bbtest.img
# a=237; while [ $a -le 450 ]; do echo $a >> bblist.txt; a=$[$a+1]; done
# mke2fs -b 1024 -l /home/jejb/bblist.txt  /dev/loop0
---

Now if you try to do an e2fsck on the partition you'll get this

---
# e2fsck  -f /dev/loop0
e2fsck 1.45.2 (27-May-2019)
Pass 1: Checking inodes, blocks, and sizes
Programming error?  block #237 claimed for no reason in process_bad_block.
Programming error?  block #238 claimed for no reason in process_bad_block.
Programming error?  block #239 claimed for no reason in process_bad_block.
Programming error?  block #240 claimed for no reason in process_bad_block.
Programming error?  block #241 claimed for no reason in process_bad_block.
Programming error?  block #242 claimed for no reason in process_bad_block.
Programming error?  block #243 claimed for no reason in process_bad_block.
Programming error?  block #244 claimed for no reason in process_bad_block.
Programming error?  block #245 claimed for no reason in process_bad_block.
Programming error?  block #246 claimed for no reason in process_bad_block.
Programming error?  block #247 claimed for no reason in process_bad_block.
Programming error?  block #248 claimed for no reason in process_bad_block.
Programming error?  block #249 claimed for no reason in process_bad_block.
Programming error?  block #250 claimed for no reason in process_bad_block.
Programming error?  block #251 claimed for no reason in process_bad_block.
Programming error?  block #252 claimed for no reason in process_bad_block.
Programming error?  block #253 claimed for no reason in process_bad_block.
Programming error?  block #254 claimed for no reason in process_bad_block.
Programming error?  block #255 claimed for no reason in process_bad_block.
Programming error?  block #256 claimed for no reason in process_bad_block.
Programming error?  block #257 claimed for no reason in process_bad_block.
Programming error?  block #258 claimed for no reason in process_bad_block.
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 for group #0 (7556, counted=7578).
Fix<y>? 
---

So mke2fs has created an ab-inito corrupt filesystem.  Empirically,
this only seems to happen if there is a block in the bad block list
under 251, but I haven't verified this extensively.

James