summaryrefslogtreecommitdiffstats
path: root/fs/ecryptfs
diff options
context:
space:
mode:
authorFilipe Manana <fdmanana@suse.com>2015-01-16 13:24:40 +0000
committerChris Mason <clm@fb.com>2015-01-19 13:05:45 -0800
commit75c68e9fbbdfc04467c9edcac76be998beaa630b (patch)
tree90744350470ba845aa065952de640cbaf52bddd3 /fs/ecryptfs
parent379d6854a2092e38b6e56a8067d922e31461b7e2 (diff)
downloadlinux-75c68e9fbbdfc04467c9edcac76be998beaa630b.tar.bz2
Btrfs: fix race deleting block group from space_info->ro_bgs list
When removing a block group we were deleting it from its space_info's ro_bgs list without the correct protection - the space info's spinlock. Fix this by doing the list delete while holding the spinlock of the corresponding space info, which is the correct lock for any operation on that list. This issue was introduced in the 3.19 kernel by the following change: Btrfs: move read only block groups onto their own list V2 commit 633c0aad4c0243a506a3e8590551085ad78af82d I ran into a kernel crash while a task was running statfs, which iterates the space_info->ro_bgs list while holding the space info's spinlock, and another task was deleting it from the same list, without holding that spinlock, as part of the block group remove operation (while running the function btrfs_remove_block_group). This happened often when running the stress test xfstests/generic/038 I recently made. Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: Chris Mason <clm@fb.com>
Diffstat (limited to 'fs/ecryptfs')
0 files changed, 0 insertions, 0 deletions