Commit d77fe802ae851a65356b1691ff97cd568b9e7d5c

Authored by Josef Bacik
Committed by Greg Kroah-Hartman
1 parent d7fad547c3

Btrfs: make sure we wait on logged extents when fsycning two subvols

commit 9dba8cf128ef98257ca719722280c9634e7e9dc7 upstream.

If we have two fsync()'s race on different subvols one will do all of its work
to get into the log_tree, wait on it's outstanding IO, and then allow the
log_tree to finish it's commit.  The problem is we were just free'ing that
subvols logged extents instead of waiting on them, so whoever lost the race
wouldn't really have their data on disk.  Fix this by waiting properly instead
of freeing the logged extents.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: Chris Mason <clm@fb.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Showing 1 changed file with 1 additions and 1 deletions Side-by-side Diff

... ... @@ -2600,9 +2600,9 @@
2600 2600 if (atomic_read(&log_root_tree->log_commit[index2])) {
2601 2601 blk_finish_plug(&plug);
2602 2602 btrfs_wait_marked_extents(log, &log->dirty_log_pages, mark);
  2603 + btrfs_wait_logged_extents(log, log_transid);
2603 2604 wait_log_commit(trans, log_root_tree,
2604 2605 root_log_ctx.log_transid);
2605   - btrfs_free_logged_extents(log, log_transid);
2606 2606 mutex_unlock(&log_root_tree->log_mutex);
2607 2607 ret = root_log_ctx.log_ret;
2608 2608 goto out;