]> git.baikalelectronics.ru Git - kernel.git/commit
Btrfs: fix possible softlockup in the allocator
authorJosef Bacik <josef@redhat.com>
Tue, 6 Oct 2009 14:04:28 +0000 (10:04 -0400)
committerChris Mason <chris.mason@oracle.com>
Tue, 6 Oct 2009 14:04:28 +0000 (10:04 -0400)
commit09e9ec2caa4a1077ae96eee0c3c95da67a51c786
treeae9394e50bc2418e8c3054de12ed44962d6f261a
parentd0539cb97938ac6c5bbeaff1915559b79099a8d4
Btrfs: fix possible softlockup in the allocator

Like the cluster allocating stuff, we can lockup the box with the normal
allocation path.  This happens when we

1) Start to cache a block group that is severely fragmented, but has a decent
amount of free space.
2) Start to commit a transaction
3) Have the commit try and empty out some of the delalloc inodes with extents
that are relatively large.

The inodes will not be able to make the allocations because they will ask for
allocations larger than a contiguous area in the free space cache.  So we will
wait for more progress to be made on the block group, but since we're in a
commit the caching kthread won't make any more progress and it already has
enough free space that wait_block_group_cache_progress will just return.  So,
if we wait and fail to make the allocation the next time around, just loop and
go to the next block group.  This keeps us from getting stuck in a softlockup.
Thanks,

Signed-off-by: Josef Bacik <jbacik@redhat.com>
Signed-off-by: Chris Mason <chris.mason@oracle.com>
fs/btrfs/extent-tree.c