diff options
author | Ilya Dryomov <idryomov@gmail.com> | 2013-10-02 20:39:50 +0400 |
---|---|---|
committer | Josef Bacik <jbacik@fusionio.com> | 2013-10-05 00:02:13 +0400 |
commit | 964fb15acfcd672ac691f04879b71f07ccc21e0c (patch) | |
tree | 1d8df39327cbfcf2c6543b47b4b66e48a27f4946 /fs/proc | |
parent | 385fe0bede52a45cd960f30c7eb8d20ad8e1e05b (diff) | |
download | linux-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