ext4: limit block allocations for indirect-block files to < 2^32
authorEric Sandeen <sandeen@redhat.com>
Wed, 16 Sep 2009 18:45:10 +0000 (14:45 -0400)
committerTheodore Ts'o <tytso@mit.edu>
Wed, 16 Sep 2009 18:45:10 +0000 (14:45 -0400)
commitfb0a387dcdcd21aab1b09ee7fd80b7c979bdbbfd
treedcb12c5fce8f7ccb8b183936ea71a29aba3f3846
parentc40ce3c9ea97425a12d7e44031a98fe50add6fc1
ext4: limit block allocations for indirect-block files to < 2^32

Today, the ext4 allocator will happily allocate blocks past
2^32 for indirect-block files, which results in the block
numbers getting truncated, and corruption ensues.

This patch limits such allocations to < 2^32, and adds
BUG_ONs if we do get blocks larger than that.

This should address RH Bug 519471, ext4 bitmap allocator
must limit blocks to < 2^32

* ext4_find_goal() is modified to choose a goal < UINT_MAX,
  so that our starting point is in an acceptable range.

* ext4_xattr_block_set() is modified such that the goal block
  is < UINT_MAX, as above.

* ext4_mb_regular_allocator() is modified so that the group
  search does not continue into groups which are too high

* ext4_mb_use_preallocated() has a check that we don't use
  preallocated space which is too far out

* ext4_alloc_blocks() and ext4_xattr_block_set() add some BUG_ONs

No attempt has been made to limit inode locations to < 2^32,
so we may wind up with blocks far from their inodes.  Doing
this much already will lead to some odd ENOSPC issues when the
"lower 32" gets full, and further restricting inodes could
make that even weirder.

For high inodes, choosing a goal of the original, % UINT_MAX,
may be a bit odd, but then we're in an odd situation anyway,
and I don't know of a better heuristic.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
fs/ext4/ext4.h
fs/ext4/inode.c
fs/ext4/mballoc.c
fs/ext4/super.c
fs/ext4/xattr.c