1. 05 Feb, 2013 6 commits
    • Josef Bacik's avatar
      Btrfs: fix possible stale data exposure · 59fe4f41
      Josef Bacik authored
      We specifically do not update the disk i_size if there are ordered extents
      outstanding for any area between the current disk_i_size and our ordered
      extent so that we do not expose stale data.  The problem is the check we
      have only checks if the ordered extent starts at or after the current
      disk_i_size, which doesn't take into account an ordered extent that starts
      before the current disk_i_size and ends past the disk_i_size.  Fix this by
      checking if the extent ends past the disk_i_size.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      59fe4f41
    • Josef Bacik's avatar
      Btrfs: fix missing i_size update · 5d1f4020
      Josef Bacik authored
      If we have an ordered extent before the ordered extent we are currently
      completing that is after the current disk_i_size we will put our i_size
      update into that ordered extent so that we do not expose stale data.  The
      problem is that if our disk i_size is updated past the previous ordered
      extent we won't update the i_size with the pending i_size update.  So check
      the pending i_size update and if its above the current disk i_size we need
      to go ahead and try to update.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      5d1f4020
    • Liu Bo's avatar
      Btrfs: fix race between snapshot deletion and getting inode · 6f1c3605
      Liu Bo authored
      While running snapshot testscript created by Mitch and David,
      the race between autodefrag and snapshot deletion can lead to
      corruption of dead_root list so that we can get crash on
      btrfs_clean_old_snapshots().
      
      And besides autodefrag, scrub also does the same thing, ie. read
      root first and get inode.
      
      Here is the story(take autodefrag as an example):
      (1) when we delete a snapshot or subvolume, it will set its root's
      refs to zero and do a iput() on its own inode, and if this inode happens
      to be the only active in-meory one in root's inode rbtree, it will add
      itself to the global dead_roots list for later cleanup.
      
      (2) after (1), the autodefrag thread may read another inode for defrag
      and the inode is just in the deleted snapshot/subvolume, but all of these
      are without checking if the root is still valid(refs > 0).  So the end up
      result is adding the deleted snapshot/subvolume's root to the global
      dead_roots list AGAIN.
      
      Fortunately, we already have a srcu lock to avoid the race, ie. subvol_srcu.
      
      So all we need to do is to take the lock to protect 'read root and get inode',
      since we synchronize to wait for the rcu grace period before adding something
      to the global dead_roots list.
      Reported-by: default avatarMitch Harder <mitch.harder@sabayonlinux.org>
      Signed-off-by: default avatarLiu Bo <bo.li.liu@oracle.com>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      6f1c3605
    • Miao Xie's avatar
      Btrfs: fix missing release of the space/qgroup reservation in start_transaction() · 843fcf35
      Miao Xie authored
      When we fail to start a transaction, we need to release the reserved free space
      and qgroup space, fix it.
      Signed-off-by: default avatarMiao Xie <miaox@cn.fujitsu.com>
      Reviewed-by: default avatarJan Schmidt <list.btrfs@jan-o-sch.net>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      843fcf35
    • Miao Xie's avatar
      Btrfs: fix wrong sync_writers decrement in btrfs_file_aio_write() · 0a3404dc
      Miao Xie authored
      If the checks at the beginning of btrfs_file_aio_write() fail, we needn't
      decrease ->sync_writers, because we have not increased it. Fix it.
      Signed-off-by: default avatarMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      0a3404dc
    • Josef Bacik's avatar
      Btrfs: do not merge logged extents if we've removed them from the tree · 222c81dc
      Josef Bacik authored
      You can run into this problem where if somebody is fsyncing and writing out
      the existing extents you will have removed the extent map from the em tree,
      but it's still valid for the current fsync so we go ahead and write it.  The
      problem is we unconditionally try to merge it back into the em tree, but if
      we've removed it from the em tree that will cause use after free problems.
      Fix this to only merge if we are still a part of the tree.  Thanks,
      Signed-off-by: default avatarJosef Bacik <jbacik@fusionio.com>
      222c81dc
  2. 24 Jan, 2013 8 commits
  3. 22 Jan, 2013 5 commits
  4. 20 Jan, 2013 5 commits
  5. 14 Jan, 2013 14 commits
  6. 19 Dec, 2012 1 commit
  7. 18 Dec, 2012 1 commit