diff options
author | Chris Mason <chris.mason@oracle.com> | 2009-06-04 15:34:51 -0400 |
---|---|---|
committer | Chris Mason <chris.mason@oracle.com> | 2009-06-04 15:41:27 -0400 |
commit | 44fb5511638938a2c37c895abc14df648ffc07e9 (patch) | |
tree | 0554a8a71403958b279ddcb601a3d0bb85943a59 /fs/bfs/file.c | |
parent | 2cc3c559fb2fe8cecca82a517bc56e88b0c1effd (diff) | |
download | op-kernel-dev-44fb5511638938a2c37c895abc14df648ffc07e9.zip op-kernel-dev-44fb5511638938a2c37c895abc14df648ffc07e9.tar.gz |
Btrfs: Fix oops and use after free during space balancing
The btrfs allocator uses list_for_each to walk the available block
groups when searching for free blocks. It starts off with a hint
to help find the best block group for a given allocation.
The hint is resolved into a block group, but we don't properly check
to make sure the block group we find isn't in the middle of being
freed due to filesystem shrinking or balancing. If it is being
freed, the list pointers in it are bogus and can't be trusted. But,
the code happily goes along and uses them in the list_for_each loop,
leading to all kinds of fun.
The fix used here is to check to make sure the block group we find really
is on the list before we use it. list_del_init is used when removing
it from the list, so we can do a proper check.
The allocation clustering code has a similar bug where it will trust
the block group in the current free space cluster. If our allocation
flags have changed (going from single spindle dup to raid1 for example)
because the drives in the FS have changed, we're not allowed to use
the old block group any more.
The fix used here is to check the current cluster against the
current allocation flags.
Signed-off-by: Chris Mason <chris.mason@oracle.com>
Diffstat (limited to 'fs/bfs/file.c')
0 files changed, 0 insertions, 0 deletions