When we define an error in lib/ext2fs/ext2_err.et.in, we will always use
EXT2_ET_* prefix for a new error. But EXT2_NO_MTAB_FILE doesn't obey
this rule. So fix it.
Signed-off-by: Zheng Liu <wenqing.lz@taobao.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If we have an extent tree like this (from debuge2fs's "ex" command):
Level Entries Logical Physical Length Flags
...
2/ 2 60/ 63 13096 - 13117 650024 - 650045 22
2/ 2 61/ 63 13134 - 13142 650062 - 650070 9
2/ 2 62/ 63 13193 - 13194 650121 - 650122 2
2/ 2 63/ 63 13227 - 13227 650155 - 650155 1 A)
1/ 2 4/ 14 13228 - 17108 655367 3881 B)
2/ 2 1/117 13228 - 13251 650156 - 650179 24 C)
2/ 2 2/117 13275 - 13287 650203 - 650215 13
2/ 2 3/117 13348 - 13353 650276 - 650281 6
...
and we resize the fs in such a way that all of those blocks must
be moved down, we do them one at a time. Eventually we move 1-block
extent A) to a lower block, and then follow it with the other
blocks in the next logical offsets from extent C) in the next
interior node B).
The userspace extent code tries to merge, so when it finds that
logical 13228 can be merged with logical 13227 into a single extent,
it does. And so on, all through extent C), up to block 13250 (why
not 13251? [1]), and eventually move the node block as well.
So we end up with this when all the blocks are moved post-resize:
Level Entries Logical Physical Length Flags
...
2/ 2 120/122 13193 - 13193 33220 - 33220 1
2/ 2 121/122 13194 - 13194 33221 - 33221 1
2/ 2 122/122 13227 - 13250 33222 - 33245 24 D)
1/ 2 5/ 19 13228 - 17108 34676 3881 E) ***
2/ 2 1/222 13251 - 13251 33246 - 33246 1 F)
2/ 2 2/222 13275 - 13286 33247 - 33258 12
...
All those adjacent blocks got moved into extent D), which is nice -
but the next interior node E) was never updated to reflect its new
starting point - it says the leaf extents beneath it start at 13228,
when in fact they start at 13251.
So as we move blocks one by one out of original extent C) above, we
need to keep updating C)'s parent node B) for a proper starting point.
fix_parents() does this.
Once the tree is corrupted like this, more corruption can
ensue post-resize, because we traverse the tree by interior nodes,
relying on their start block to know where we are in the tree.
If it gets off, we'll end up inserting blocks into the wrong part
of the tree, etc.
I have a testcase using fsx to create a complex extent tree which
is then moved during resize; it hit this corruption quite easily,
and with this fix, it succeeds.
Note the first hunk in the commit is for going the other way,
moving the last block of an extent to the extent after it; this
needs the same sort of fix-up, although I haven't seen it in
practice.
[1] We leave the last block because a single-block extent is its
own case, and there is no merging code in that case. \o/
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
free_gdp_blocks needs to be taught to use 64-bit fields and the appropriate
getters, otherwise it'll truncate high block numbers (when, say, resizing a
>16T fs) and mark the low numbered group descriptor blocks as free. Yikes.
Reported-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
It turns out that resize2fs uses ext2fs_dup_handle to duplicate fs handles. If
MMP is enabled, this causes both handles to share MMP buffers, which is bad
news when it comes time to free both handles. Change the code to (we hope) fix
this. This prevents resize2fs from failing with a double-free error when
handed a MMP filesystem.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Under some failure cases, we can get to fatal_error()
without even having a superblock set up. In that case,
ext2fs_mmp_stop() will segfault when it tries to dereference
fs->super.
Check for the existence of a superblock before we go
down the ext2fs_mmp_stop() path to avoid this problem.
Reported-by: Hubert Kario <hkario@redhat.com>
Addresses-Red-Hat-Bugzilla: #997972
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
do_write doesn't fully set up the first extent header on a new
inode, so if we write a 0-length file, and don't write any data
to the new file, we end up creating something that looks corrupt
to kernelspace:
EXT4-fs error (device loop0): ext4_ext_check_inode:464: inode #12: comm ls: bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Do something similar to ext4_ext_tree_init() here, and
fill out the first extent header upon creation to avoid this.
Reported-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Tested-by: Robert Yang <liezhi.yang@windriver.com>
The function deallocate_inode() in e2fsck/pass2.c was buggy in that it
would clear out the inode's mode and flags fields before trying to
deallocate any blocks which might belong to the inode.
The good news is that deallocate_inode() is mostly used to free inodes
which do not have blocks: device inodes, FIFO's, Unix-domain sockets.
The bad news is that if deallocate_inode() tried to free an invalid
extent-mapped inode, it would try to interpret the root of the extent
node as block numbers, and would therefore mark various file system
metadata blocks (the superblock, block group descriptors, the root
directory, etc.) as free and available for allocation. This was
unfortunate.
(Try running an older e2fsck against the test file system image in the
new test f_invalid_extent_symlink, and then run e2fsck a second time
on the fs image, and weep.)
Fortunately, this kind of file system image corruption appears to be
fairly rare in actual practice, since it would require a very unlucky
set of bits to be flipped, or a buggy file system implementation.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
E2fsck was missing a check for directories with logical blocks so
large that i_size > 2GB. Without this check the test image found in
the new test f_toobig_extent_dir will cause e2fsck to die with a
memory allocation failure:
Error storing directory block information (inode=12, block=0, num=475218819): Memory allocation failed
e2fsck: aborted
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reported-by: Andrey Melnikov <temnota.am@gmail.com>
The environment variable EXT2FS_NO_MTAB_OK will suppress the error
code EXT2_NO_MTAB_FILE when the /etc/mtab file can not be found. This
allows the e2fsprogs regression test suite to be run in chroots which
might not have an /etc/mtab file.
By default will still want to complain if the /etc/mtab file is
missing, since we really don't want to discourage distributions and
purveyors of embedded systems from running without an /etc/mtab file.
But if it's missing it only results in a missing sanity check that
might cause file system corruption if the file system is mounted when
programs such as e2fsck, tune2fs, or resize2fs is running, so there is
no potential security problems that might result if this environment
variable is set inappropriately.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
We can calculate journal blocks as soon as blocksize is set.
It will help to figure out wrong journal blocks count earlier.
This will save some un-necessary initialization.
Without patch output =>
mke2fs /dev/sdc1 -J size=1048576
mke2fs 1.42.7 (21-Jan-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
61312 inodes, 244936 blocks
12246 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=251658240
8 block groups
32768 blocks per group, 32768 fragments per group
7664 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376
Allocating group tables: done
Writing inode tables: done
The requested journal size is 268435456 blocks; it must be
between 1024 and 10240000 blocks. Aborting.
With patch output =>
mke2fs /dev/sdc1 -J size=1048576
mke2fs 1.42.7 (21-Jan-2013)
The requested journal size is 268435456 blocks; it must be
between 1024 and 10240000 blocks. Aborting.
Signed-off-by: Ashish Sangwan <a.sangwan@samsung.com>
Signed-off-by: Namjae Jeon <namjae.jeon@samsung.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
It is possible to have a flex_bg filesystem with block groups
which have inode & block bitmaps at some point well past the
start of the group.
If an offline shrink puts the new size somewhere between
the start of the block group and the (old) location of
the bitmaps, they can be left beyond the end of the filesystem,
i.e. result in fs corruption.
Check each remaining block group for whether its bitmaps
are beyond the end of the new filesystem, and reallocate
them in a new location if needed.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Avoid compatibility problems by using the byte swapping functions
defined by e2fsprogs, instead of the ones defined in the system header
files. We use them everywhere else, so we should use them in
kernel-jbd.h too.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Add a test to see if the backtrace() function requires linking in a
library in /usr/lib.
Addresses-Debian-Bug: #708307
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If secure_getenv() use it in preference to __secure_getenv().
Starting with (e)glibc version 2.17, secure_getenv() exists, while
__secure_getenv() only works with shared library links (where it is a
weak symbol), but not for static links with /lib/libc.a
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Don't change the root directory's UID/GID automatically just because
mke2fs was run as a non-root user. This can be confusing for users,
and is not flexible for non-root installation tools that need to
create a filesystem with different ownership from the current user.
Add the "-E root_owner[=uid:gid]" option to mke2fs so that the user
and group can be explicitly specified for the root directory. If
the "=uid:gid" argument is not specified, the current UID and GID
are extracted from the running process, as was done in the past.
Signed-off-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
A minor cleanup to order the command-line option parsing in
alphabetical order, except for "-E" and "-R", which need to
be co-located.
Print a message that the "-R" option is deprecated. It has
been deprecated since 2005 (commit c6a44136b9).
Signed-off-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The sed filters for test outputs that are used to remove build and
test specific information (such as version strings, dates, times,
UUIDs) were unconditionally deleting the first line of output. This
would normally contain the tool version string, but in some cases
contained other information that was being lost. This can lead to
difficulty debugging test failures.
The sed filtering has been changed to only remove the actual version
strings. As well, similar filter strings were duplicated throughout
many scripts, and "sed" and "tr" were often called multiple times in
a pipeline. These have been consolidated into a single filter.sed
file to avoid having to maintain these filters in multiple places.
In a few cases, accidentally deleted messages have been restored to
the expect output for the tests. In other cases, trivial whitespace
has been changed in the expect files.
Signed-off-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This file was never getting compiled, and there is no user of
ext2fs_list_backups() in the e2fsprogs sources. So remove it as a
clean up.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This tests creates a file system where the last entry in one leaf
block overlaps with logical block range in the first entry of the next
leaf block.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
e2fsck does not detect extents which are outside their location in the
extent tree. This can result in a bad extent at the end of an extent-block
not being detected.
From a part of a dump_extents output:
1/ 2 37/ 68 143960 - 146679 123826181 2720
2/ 2 1/ 2 143960 - 146679 123785816 - 123788535 2720
2/ 2 2/ 2 146680 - 147583 123788536 - 123789439 904 Uninit <-bad extent
1/ 2 38/ 68 146680 - 149391 123826182 2712
2/ 2 1/ 2 146680 - 147583 18486 - 19389 904
2/ 2 2/ 2 147584 - 149391 123789440 - 123791247 1808
e2fsck does not detect this bad extent which both overlaps another, valid
extent, and is invalid by being beyond the end of the extent above it in
the tree.
This patch modifies e2fsck to detect this invalid extent and remove it.
Signed-off-by: David Jeffery <djeffery@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Perhaps the most serious fix up is a type-punning warning which could
result in miscompilation with overly enthusiastic compilers.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
... or indeed by any mainline kernel, since the compression patches
were never stablized.
Addresses-Debian-Bug: #707609
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reported-by: "Creidieki M. Crouch" <creidieki@gmail.com>
When opening the external journal, use the same logic to decide
whether or not to open the file system with EXT2_FLAG_EXCLUSIVE found
in main().
Otherwise, it's not posible to use e2fsck when the root file system is
using an external journal.
Reported-by: Calvin Owens <jcalvinowens@gmail.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
E2fsck previously was complaining with zero-length extended attributes
if they appeared in the in-inode xattr space. Test to make sure
e2fsck is now happy with such xattrs.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
e2fsck thinks that this:
# touch mnt/testfile1
# setfattr -n "user.test" mnt/testfile1
results in a filesystem with corruption:
Pass 1: Checking inodes, blocks, and sizes
Extended attribute in inode 12 has a value size (0) which is invalid
Clear? yes
but as far as I can tell, there is absolutely nothing wrong with
a 0-length value on an extended attribute. Just remove the check.
Reported-by: David Shaw <dshaw@jabberwocky.com>
Reported-by: Harald Reindl <h.reindl@thelounge.net>
Addresses-Red-Hat-Bugzilla: #557959
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
The ext2fs_read_inode_full() function should not use fs->read_inode()
if the caller has requested more than the base 128 byte inode
structure and the inode size is greater than 128 bytes. Otherwise the
caller won't get all of the bytes that they were asking for, since
there's no way for the fs->read_inode override function can know what
the size of the buffer passed to ext2fs_read_inode_full().
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
This prevents from SIGSEGV when -s options is used.
Signed-off-by: Tomas Racek <tracek@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Lukas Czerner <lczerner@redhat.com>
All data cannot be included in normal image file so e2image should exit
in this case.
Signed-off-by: Tomas Racek <tracek@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Exit is called right after the install_image anyway so this one can
be removed.
Signed-off-by: Tomas Racek <tracek@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Disallow tune2fs command to set the inode size to be larger than the
block size. Without this patch, tune2fs makes the file system to be
unmountable.
Steps to reproduce:
1.Create ext4 without flex_bg (or just create ext3)
# mke2fs -t ext4 -O ^flex_bg DEV
2.Set inode size larger than block size
# tune2fs -I 8192 DEV
3. We failed to mount FS
# mount DEV MP
mount: wrong fs type, bad option, bad superblock on /dev/sda7,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
Signed-off-by: Akira Fujita <a-fujita@rs.jp.nec.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
The only checksum program which we can reliably count upon being
installed on all systems is "sum", which is not a particular robust
checksum. The problem with using md5sum or sha1sum is it hat it may
not be installed on all systems. So create a crcsum program which is
used so we can validate that a data file on a resized file system has
not been corrupted.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
When doing an off-line resize2fs of an initially very small file
system, it's possible to run out of reserved gdt blocks (which are
reserved via the resize inode). Once we run out, we need to move the
allocation bitmaps and inode table out of the way to grow the gdt
blocks. Unfortunately, when moving these metadata blocks, it was
possible that a block that had been just been newly allocated for a
new block group could also get allocated for a metadata block for an
existing block group that was being moved.
To prevent this, after we grow the gdt blocks and allocate the
metadata blocks for the new block groups, make sure all of these
blocks are marked as reserved.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reported-by: John Jolly <john.jolly@gmail.com>
The extent_inode commands split_node, replace_node, and insert_node
take arguments which resulted in confusing error messages after
succeeding. Fix this.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Commit e3507739e4 introduced a build failure if e2fsprogs is
configured with --enable-jbd-debug. Fix this.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
New function ext2fs_symlink() doesn't have a prototype in ext2fs.h and
thus debugfs compilation gives warning:
debugfs.c:2219:2: warning: implicit declaration of function 'ext2fs_symlink'
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Zheng Liu