summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorJosef Bacik <jbacik@fb.com>2014-02-07 19:57:59 +0100
committerChris Mason <clm@fb.com>2014-02-09 02:57:15 +0100
commit27a377db745ed4d11b3b9b340756857cb8dde07f (patch)
tree9f2893a3f3751542daad4a70f37e6ea57ec61373
parentbtrfs: reserve no transaction units in btrfs_ioctl_set_features (diff)
downloadlinux-27a377db745ed4d11b3b9b340756857cb8dde07f.tar.xz
linux-27a377db745ed4d11b3b9b340756857cb8dde07f.zip
Btrfs: don't loop forever if we can't run because of the tree mod log
A user reported a 100% cpu hang with my new delayed ref code. Turns out I forgot to increase the count check when we can't run a delayed ref because of the tree mod log. If we can't run any delayed refs during this there is no point in continuing to look, and we need to break out. Thanks, Signed-off-by: Josef Bacik <jbacik@fb.com> Signed-off-by: Chris Mason <clm@fb.com>
-rw-r--r--fs/btrfs/extent-tree.c1
1 files changed, 1 insertions, 0 deletions
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 9c9ecc93ae2c..32312e09f0f5 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -2385,6 +2385,7 @@ static noinline int __btrfs_run_delayed_refs(struct btrfs_trans_handle *trans,
spin_unlock(&delayed_refs->lock);
locked_ref = NULL;
cond_resched();
+ count++;
continue;
}