ext4: correctly migrate a file with a hole at the beginning
authorEryu Guan <guaneryu@gmail.com>
Sat, 4 Jul 2015 04:03:44 +0000 (00:03 -0400)
committerDanny Wood <danwood76@gmail.com>
Tue, 29 Jan 2019 13:09:13 +0000 (13:09 +0000)
commit69daebdc119b4ccfa2b22ec560f86e04f4e86ff9
treedfc5ba0821c348053f52f1341e6f0fe6af824483
parente2a1b5155da59e30567b78ea716a7db26ca8b095
ext4: correctly migrate a file with a hole at the beginning

commit 8974fec7d72e3e02752fe0f27b4c3719c78d9a15 upstream.

Currently ext4_ind_migrate() doesn't correctly handle a file which
contains a hole at the beginning of the file.  This caused the migration
to be done incorrectly, and then if there is a subsequent following
delayed allocation write to the "hole", this would reclaim the same data
blocks again and results in fs corruption.

  # assmuing 4k block size ext4, with delalloc enabled
  # skip the first block and write to the second block
  xfs_io -fc "pwrite 4k 4k" -c "fsync" /mnt/ext4/testfile

  # converting to indirect-mapped file, which would move the data blocks
  # to the beginning of the file, but extent status cache still marks
  # that region as a hole
  chattr -e /mnt/ext4/testfile

  # delayed allocation writes to the "hole", reclaim the same data block
  # again, results in i_blocks corruption
  xfs_io -c "pwrite 0 4k" /mnt/ext4/testfile
  umount /mnt/ext4
  e2fsck -nf /dev/sda6
  ...
  Inode 53, i_blocks is 16, should be 8.  Fix? no
  ...

Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/ext4/migrate.c