1. 20 Feb, 2013 34 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 1 commit
    • 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