summaryrefslogtreecommitdiff
path: root/fs/proc
diff options
context:
space:
mode:
authorIlya Dryomov <idryomov@gmail.com>2013-10-02 20:39:50 +0400
committerJosef Bacik <jbacik@fusionio.com>2013-10-05 00:02:13 +0400
commit964fb15acfcd672ac691f04879b71f07ccc21e0c (patch)
tree1d8df39327cbfcf2c6543b47b4b66e48a27f4946 /fs/proc
parent385fe0bede52a45cd960f30c7eb8d20ad8e1e05b (diff)
downloadlinux-964fb15acfcd672ac691f04879b71f07ccc21e0c.tar.xz
Btrfs: eliminate races in worker stopping code
The current implementation of worker threads in Btrfs has races in worker stopping code, which cause all kinds of panics and lockups when running btrfs/011 xfstest in a loop. The problem is that btrfs_stop_workers is unsynchronized with respect to check_idle_worker, check_busy_worker and __btrfs_start_workers. E.g., check_idle_worker race flow: btrfs_stop_workers(): check_idle_worker(aworker): - grabs the lock - splices the idle list into the working list - removes the first worker from the working list - releases the lock to wait for its kthread's completion - grabs the lock - if aworker is on the working list, moves aworker from the working list to the idle list - releases the lock - grabs the lock - puts the worker - removes the second worker from the working list ...... btrfs_stop_workers returns, aworker is on the idle list FS is umounted, memory is freed ...... aworker is waken up, fireworks ensue With this applied, I wasn't able to trigger the problem in 48 hours, whereas previously I could reliably reproduce at least one of these races within an hour. Reported-by: David Sterba <dsterba@suse.cz> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Diffstat (limited to 'fs/proc')
0 files changed, 0 insertions, 0 deletions