| Message ID | 4E42D6FD.2020904@redhat.com |
|---|---|
| State | Accepted, archived |
| Headers | show |
Oops, thanks for catching this! Applied to the e2fsprogs next branch.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/lib/ext2fs/gen_bitmap64.c b/lib/ext2fs/gen_bitmap64.c index f75876d..80c9f7a 100644 --- a/lib/ext2fs/gen_bitmap64.c +++ b/lib/ext2fs/gen_bitmap64.c @@ -193,6 +193,7 @@ errcode_t ext2fs_copy_generic_bmap(ext2fs_generic_bitmap src, new_bmap->real_end = src->real_end; new_bmap->bitmap_ops = src->bitmap_ops; new_bmap->base_error_code = src->base_error_code; + new_bmap->cluster_bits = src->cluster_bits; descr = src->description; if (descr) {
The f_lotsbad regression test was failing on some systems with: @@ -26,6 +61,7 @@ Restarting e2fsck from the beginning... Pass 1: Checking inodes, blocks, and sizes +Illegal block number passed to ext2fs_test_block_bitmap #0 for in-use block map Pass 2: Checking directory structure Entry 'termcap' in / (2) has deleted/unused inode 12. Clear? yes Running with valgrind (./test_script --valgrind f_lotsbad) we see: +==31409== Conditional jump or move depends on uninitialised value(s) +==31409== at 0x42927A: ext2fs_test_generic_bmap (gen_bitmap64.c:378) among others. Looking at gen_bitmap64.c: 376: arg >>= bitmap->cluster_bits; 377: 378: if ((arg < bitmap->start) || (arg > bitmap->end)) { A little more debugging showed that it was actually bitmap->cluster_bits which was uninitialized, because it never gets copied over in ext2fs_copy_generic_bmap() Patch below resolves the issue. Reported-by: Andreas Dilger <adilger@whamcloud.com> Signed-off-by: Eric Sandeen <sandeen@redhat.com> --- -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html