1. 20 Feb, 2013 33 commits
  2. 15 Feb, 2013 2 commits
    • David Sterba's avatar
      btrfs: access superblock via pagecache in scan_one_device · 6f60cbd3
      David Sterba authored
      btrfs_scan_one_device is calling set_blocksize() which can race
      with a concurrent process making dirty page cache pages.  It can end up
      dropping dirty page cache pages on the floor, which isn't very nice when
      someone is just running btrfs dev scan to find filesystems on the
      box.
      
      Now that udev is registering btrfs devices as it discovers them, we can
      actually end up racing with our own mkfs program too.  When this
      happens, we drop some of the important blocks written by mkfs.
      
      This commit changes scan_one_device to read the super out of the page
      cache instead of trying to use bread.  This way we don't have to care
      about the blocksize of the device.
      
      This also drops the invalidate_bdev() call.  It wasn't very polite to
      invalidate during the scan either.  mkfs is putting the super into the
      page cache, there's no reason to invalidate at this point.
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.cz>
      Signed-off-by: default avatarChris Mason <chris.mason@fusionio.com>
      6f60cbd3
    • Arne Jansen's avatar
      Btrfs: fix crash in log replay with qgroups enabled · 2a745b14
      Arne Jansen authored
      When replaying a log tree with qgroups enabled, tree_mod_log_rewind does a
      sanity-check of the number of items against the maximum possible number.
      It calculates that number with the nodesize of fs_root. Unfortunately
      fs_root is not yet set at this stage. So instead use the nodesize from
      tree_root, which is already initialized.
      Signed-off-by: default avatarArne Jansen <sensille@gmx.net>
      Signed-off-by: default avatarChris Mason <chris.mason@fusionio.com>
      2a745b14
  3. 06 Feb, 2013 3 commits
  4. 05 Feb, 2013 2 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