1. 18 9月, 2014 5 次提交
  2. 29 6月, 2014 1 次提交
  3. 10 6月, 2014 1 次提交
  4. 11 3月, 2014 3 次提交
    • M
      Btrfs: don't flush all delalloc inodes when we doesn't get s_umount lock · 6c255e67
      Miao Xie 提交于
      We needn't flush all delalloc inodes when we doesn't get s_umount lock,
      or we would make the tasks wait for a long time.
      Signed-off-by: NMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: NJosef Bacik <jbacik@fb.com>
      6c255e67
    • M
      Btrfs: fix use-after-free in the finishing procedure of the device replace · c404e0dc
      Miao Xie 提交于
      During device replace test, we hit a null pointer deference (It was very easy
      to reproduce it by running xfstests' btrfs/011 on the devices with the virtio
      scsi driver). There were two bugs that caused this problem:
      - We might allocate new chunks on the replaced device after we updated
        the mapping tree. And we forgot to replace the source device in those
        mapping of the new chunks.
      - We might get the mapping information which including the source device
        before the mapping information update. And then submit the bio which was
        based on that mapping information after we freed the source device.
      
      For the first bug, we can fix it by doing mapping tree update and source
      device remove in the same context of the chunk mutex. The chunk mutex is
      used to protect the allocable device list, the above method can avoid
      the new chunk allocation, and after we remove the source device, all
      the new chunks will be allocated on the new device. So it can fix
      the first bug.
      
      For the second bug, we need make sure all flighting bios are finished and
      no new bios are produced during we are removing the source device. To fix
      this problem, we introduced a global @bio_counter, we not only inc/dec
      @bio_counter outsize of map_blocks, but also inc it before submitting bio
      and dec @bio_counter when ending bios.
      
      Since Raid56 is a little different and device replace dosen't support raid56
      yet, it is not addressed in the patch and I add comments to make sure we will
      fix it in the future.
      Reported-by: NQu Wenruo <quwenruo@cn.fujitsu.com>
      Signed-off-by: NWang Shilong <wangsl.fnst@cn.fujitsu.com>
      Signed-off-by: NMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: NJosef Bacik <jbacik@fb.com>
      c404e0dc
    • M
      Btrfs: fix unprotected alloc list insertion during the finishing procedure of replace · 391cd9df
      Miao Xie 提交于
      the alloc list of the filesystem is protected by ->chunk_mutex, we need
      get that mutex when we insert the new device into the list.
      Signed-off-by: NMiao Xie <miaox@cn.fujitsu.com>
      Signed-off-by: NJosef Bacik <jbacik@fb.com>
      391cd9df
  5. 29 1月, 2014 1 次提交
  6. 21 11月, 2013 1 次提交
  7. 12 11月, 2013 5 次提交
  8. 05 10月, 2013 1 次提交
  9. 21 9月, 2013 1 次提交
  10. 01 9月, 2013 2 次提交
  11. 15 7月, 2013 1 次提交
  12. 14 6月, 2013 2 次提交
  13. 18 5月, 2013 1 次提交
    • S
      Btrfs: don't allow device replace on RAID5/RAID6 · 49688107
      Stefan Behrens 提交于
      This is not yet supported and causes crashes. One sad user reported
      that it destroyed his filesystem.
      
      One failure is in __btrfs_map_block+0xc1f calling kmalloc(0).
      
      0x5f21f is in __btrfs_map_block (fs/btrfs/volumes.c:4923).
      4918                            num_stripes = map->num_stripes;
      4919                            max_errors = nr_parity_stripes(map);
      4920
      4921                            raid_map = kmalloc(sizeof(u64) * num_stripes,
      4922                                               GFP_NOFS);
      4923                            if (!raid_map) {
      4924                                    ret = -ENOMEM;
      4925                                    goto out;
      4926                            }
      4927
      
      There might be more issues. Until this is really tested, don't allow
      users to start the procedure on RAID5/RAID6 filesystems.
      Signed-off-by: NStefan Behrens <sbehrens@giantdisaster.de>
      Signed-off-by: NJosef Bacik <jbacik@fusionio.com>
      49688107
  14. 20 2月, 2013 1 次提交
  15. 13 12月, 2012 1 次提交