1. 24 12月, 2021 2 次提交
  2. 04 11月, 2021 2 次提交
  3. 01 10月, 2021 1 次提交
    • H
      ext4: limit the number of blocks in one ADD_RANGE TLV · a2c2f082
      Hou Tao 提交于
      Now EXT4_FC_TAG_ADD_RANGE uses ext4_extent to track the
      newly-added blocks, but the limit on the max value of
      ee_len field is ignored, and it can lead to BUG_ON as
      shown below when running command "fallocate -l 128M file"
      on a fast_commit-enabled fs:
      
        kernel BUG at fs/ext4/ext4_extents.h:199!
        invalid opcode: 0000 [#1] SMP PTI
        CPU: 3 PID: 624 Comm: fallocate Not tainted 5.14.0-rc6+ #1
        Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
        RIP: 0010:ext4_fc_write_inode_data+0x1f3/0x200
        Call Trace:
         ? ext4_fc_write_inode+0xf2/0x150
         ext4_fc_commit+0x93b/0xa00
         ? ext4_fallocate+0x1ad/0x10d0
         ext4_sync_file+0x157/0x340
         ? ext4_sync_file+0x157/0x340
         vfs_fsync_range+0x49/0x80
         do_fsync+0x3d/0x70
         __x64_sys_fsync+0x14/0x20
         do_syscall_64+0x3b/0xc0
         entry_SYSCALL_64_after_hwframe+0x44/0xae
      
      Simply fixing it by limiting the number of blocks
      in one EXT4_FC_TAG_ADD_RANGE TLV.
      
      Fixes: aa75f4d3 ("ext4: main fast-commit commit path")
      Cc: stable@kernel.org
      Signed-off-by: NHou Tao <houtao1@huawei.com>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Link: https://lore.kernel.org/r/20210820044505.474318-1-houtao1@huawei.com
      a2c2f082
  4. 31 8月, 2021 1 次提交
  5. 06 6月, 2021 1 次提交
  6. 10 4月, 2021 3 次提交
  7. 21 3月, 2021 1 次提交
    • H
      ext4: fix rename whiteout with fast commit · 8210bb29
      Harshad Shirwadkar 提交于
      This patch adds rename whiteout support in fast commits. Note that the
      whiteout object that gets created is actually char device. Which
      imples, the function ext4_inode_journal_mode(struct inode *inode)
      would return "JOURNAL_DATA" for this inode. This has a consequence in
      fast commit code that it will make creation of the whiteout object a
      fast-commit ineligible behavior and thus will fall back to full
      commits. With this patch, this can be observed by running fast commits
      with rename whiteout and seeing the stats generated by ext4_fc_stats
      tracepoint as follows:
      
      ext4_fc_stats: dev 254:32 fc ineligible reasons:
      XATTR:0, CROSS_RENAME:0, JOURNAL_FLAG_CHANGE:0, NO_MEM:0, SWAP_BOOT:0,
      RESIZE:0, RENAME_DIR:0, FALLOC_RANGE:0, INODE_JOURNAL_DATA:16;
      num_commits:6, ineligible: 6, numblks: 3
      
      So in short, this patch guarantees that in case of rename whiteout, we
      fall back to full commits.
      
      Amir mentioned that instead of creating a new whiteout object for
      every rename, we can create a static whiteout object with irrelevant
      nlink. That will make fast commits to not fall back to full
      commit. But until this happens, this patch will ensure correctness by
      falling back to full commits.
      
      Fixes: 8016e29f ("ext4: fast commit recovery path")
      Cc: stable@kernel.org
      Signed-off-by: NHarshad Shirwadkar <harshadshirwadkar@gmail.com>
      Link: https://lore.kernel.org/r/20210316221921.1124955-1-harshadshirwadkar@gmail.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
      8210bb29
  8. 03 2月, 2021 1 次提交
  9. 28 1月, 2021 1 次提交
  10. 16 1月, 2021 3 次提交
  11. 18 12月, 2020 2 次提交
  12. 07 11月, 2020 12 次提交
  13. 29 10月, 2020 4 次提交
  14. 22 10月, 2020 6 次提交