dumpe2fs: don't crash when the user provides no block device argument

If the user doesn't provide any arguments, the guard fails to run and
the whole thing segfaults on ext2fs_open2().  Don't do that.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
libext2fs: fix endian handling error; reduce fragmentation some

If we're going to read the "nr - 1" entry in an indirect block for use
as a "goal" input to the block allocator, we need to byteswap the
entry.  While we're at it, if we're allocating blocks for the zeroth
entry in the indirect block, we might as well use the indirect block
as the starting point to try to reduce fragmentation.

(d_fallocate_blkmap will test this...)

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
libext2fs: don't allow alloc_stats on bad inode/block numbers

Don't allow callers to feed bad block/inode numbers to
ext2fs_*_alloc_stats2, because evil callers (<cough>resize2fs<cough>)
can corrupt library state this way, leading to a crash.

(There will be a subsequent patch to resize2fs to fix its bad
behavior.)

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
debugfs: fix typo in message

Signed-off-by: Bernhard M. Wiedemann <bwiedemann@suse.de>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
tune2fs: fix memory leak in inode_scan_and_fix()

When we use ext2fs_open_inode_scan() to iterate inodes and finish
jobs, we also need a ext2fs_close_inode_scan(scan) operation, but in
inode_scan_and_fix(), we forgot to call it, fix this error.

Signed-off-by: Xiaoguang Wang <wangxg.fnst@cn.fujitsu.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
misc: fix infinite loop when finding the start of the hugefile start range

When looking for the start of the hugefile range, the 'next' variable
is incorrectly decremented.  If we happened to find a single free
block, the effect of this decrement is that blk == next, which means
that we never modify the loop control variable, so get_start_block
never returns.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>