1. 06 8月, 2020 1 次提交
  2. 04 6月, 2020 10 次提交
  3. 03 6月, 2020 2 次提交
  4. 29 5月, 2020 5 次提交
  5. 20 5月, 2020 1 次提交
  6. 19 5月, 2020 1 次提交
    • E
      fscrypt: support test_dummy_encryption=v2 · ed318a6c
      Eric Biggers 提交于
      v1 encryption policies are deprecated in favor of v2, and some new
      features (e.g. encryption+casefolding) are only being added for v2.
      
      Therefore, the "test_dummy_encryption" mount option (which is used for
      encryption I/O testing with xfstests) needs to support v2 policies.
      
      To do this, extend its syntax to be "test_dummy_encryption=v1" or
      "test_dummy_encryption=v2".  The existing "test_dummy_encryption" (no
      argument) also continues to be accepted, to specify the default setting
      -- currently v1, but the next patch changes it to v2.
      
      To cleanly support both v1 and v2 while also making it easy to support
      specifying other encryption settings in the future (say, accepting
      "$contents_mode:$filenames_mode:v2"), make ext4 and f2fs maintain a
      pointer to the dummy fscrypt_context rather than using mount flags.
      
      To avoid concurrency issues, don't allow test_dummy_encryption to be set
      or changed during a remount.  (The former restriction is new, but
      xfstests doesn't run into it, so no one should notice.)
      
      Tested with 'gce-xfstests -c {ext4,f2fs}/encrypt -g auto'.  On ext4,
      there are two regressions, both of which are test bugs: ext4/023 and
      ext4/028 fail because they set an xattr and expect it to be stored
      inline, but the increase in size of the fscrypt_context from
      24 to 40 bytes causes this xattr to be spilled into an external block.
      
      Link: https://lore.kernel.org/r/20200512233251.118314-4-ebiggers@kernel.orgAcked-by: NJaegeuk Kim <jaegeuk@kernel.org>
      Reviewed-by: NTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      ed318a6c
  7. 02 4月, 2020 1 次提交
  8. 06 3月, 2020 1 次提交
    • E
      ext4: remove EXT4_EOFBLOCKS_FL and associated code · 4337ecd1
      Eric Whitney 提交于
      The EXT4_EOFBLOCKS_FL inode flag is used to indicate whether a file
      contains unwritten blocks past i_size.  It's set when ext4_fallocate
      is called with the KEEP_SIZE flag to extend a file with an unwritten
      extent.  However, this flag hasn't been useful functionally since
      March, 2012, when a decision was made to remove it from ext4.
      
      All traces of EXT4_EOFBLOCKS_FL were removed from e2fsprogs version
      1.42.2 by commit 010dc7b90d97 ("e2fsck: remove EXT4_EOFBLOCKS_FL flag
      handling") at that time.  Now that enough time has passed to make
      e2fsprogs versions containing this modification common, this patch now
      removes the code associated with EXT4_EOFBLOCKS_FL from the kernel as
      well.
      
      This change has two implications.  First, because pre-1.42.2 e2fsck
      versions only look for a problem if EXT4_EOFBLOCKS_FL is set, and
      because that bit will never be set by newer kernels containing this
      patch, old versions of e2fsck won't have a compatibility problem with
      files created by newer kernels.
      
      Second, newer kernels will not clear EXT4_EOFBLOCKS_FL inode flag bits
      belonging to a file written by an older kernel.  If set, it will remain
      in that state until the file is deleted.  Because e2fsck versions since
      1.42.2 don't check the flag at all, no adverse effect is expected.
      However, pre-1.42.2 e2fsck versions that do check the flag may report
      that it is set when it ought not to be after a file has been truncated
      or had its unwritten blocks written.  In this case, the old version of
      e2fsck will offer to clear the flag.  No adverse effect would then
      occur whether the user chooses to clear the flag or not.
      Signed-off-by: NEric Whitney <enwlinux@gmail.com>
      Link: https://lore.kernel.org/r/20200211210216.24960-1-enwlinux@gmail.comSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
      4337ecd1
  9. 22 2月, 2020 3 次提交
  10. 21 2月, 2020 2 次提交
  11. 20 2月, 2020 1 次提交
    • Q
      ext4: fix a data race in EXT4_I(inode)->i_disksize · 35df4299
      Qian Cai 提交于
      EXT4_I(inode)->i_disksize could be accessed concurrently as noticed by
      KCSAN,
      
       BUG: KCSAN: data-race in ext4_write_end [ext4] / ext4_writepages [ext4]
      
       write to 0xffff91c6713b00f8 of 8 bytes by task 49268 on cpu 127:
        ext4_write_end+0x4e3/0x750 [ext4]
        ext4_update_i_disksize at fs/ext4/ext4.h:3032
        (inlined by) ext4_update_inode_size at fs/ext4/ext4.h:3046
        (inlined by) ext4_write_end at fs/ext4/inode.c:1287
        generic_perform_write+0x208/0x2a0
        ext4_buffered_write_iter+0x11f/0x210 [ext4]
        ext4_file_write_iter+0xce/0x9e0 [ext4]
        new_sync_write+0x29c/0x3b0
        __vfs_write+0x92/0xa0
        vfs_write+0x103/0x260
        ksys_write+0x9d/0x130
        __x64_sys_write+0x4c/0x60
        do_syscall_64+0x91/0xb47
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
      
       read to 0xffff91c6713b00f8 of 8 bytes by task 24872 on cpu 37:
        ext4_writepages+0x10ac/0x1d00 [ext4]
        mpage_map_and_submit_extent at fs/ext4/inode.c:2468
        (inlined by) ext4_writepages at fs/ext4/inode.c:2772
        do_writepages+0x5e/0x130
        __writeback_single_inode+0xeb/0xb20
        writeback_sb_inodes+0x429/0x900
        __writeback_inodes_wb+0xc4/0x150
        wb_writeback+0x4bd/0x870
        wb_workfn+0x6b4/0x960
        process_one_work+0x54c/0xbe0
        worker_thread+0x80/0x650
        kthread+0x1e0/0x200
        ret_from_fork+0x27/0x50
      
       Reported by Kernel Concurrency Sanitizer on:
       CPU: 37 PID: 24872 Comm: kworker/u261:2 Tainted: G        W  O L 5.5.0-next-20200204+ #5
       Hardware name: HPE ProLiant DL385 Gen10/ProLiant DL385 Gen10, BIOS A40 07/10/2019
       Workqueue: writeback wb_workfn (flush-7:0)
      
      Since only the read is operating as lockless (outside of the
      "i_data_sem"), load tearing could introduce a logic bug. Fix it by
      adding READ_ONCE() for the read and WRITE_ONCE() for the write.
      Signed-off-by: NQian Cai <cai@lca.pw>
      Link: https://lore.kernel.org/r/1581085751-31793-1-git-send-email-cai@lca.pwSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org
      35df4299
  12. 14 2月, 2020 1 次提交
    • J
      ext4: fix checksum errors with indexed dirs · 48a34311
      Jan Kara 提交于
      DIR_INDEX has been introduced as a compat ext4 feature. That means that
      even kernels / tools that don't understand the feature may modify the
      filesystem. This works because for kernels not understanding indexed dir
      format, internal htree nodes appear just as empty directory entries.
      Index dir aware kernels then check the htree structure is still
      consistent before using the data. This all worked reasonably well until
      metadata checksums were introduced. The problem is that these
      effectively made DIR_INDEX only ro-compatible because internal htree
      nodes store checksums in a different place than normal directory blocks.
      Thus any modification ignorant to DIR_INDEX (or just clearing
      EXT4_INDEX_FL from the inode) will effectively cause checksum mismatch
      and trigger kernel errors. So we have to be more careful when dealing
      with indexed directories on filesystems with checksumming enabled.
      
      1) We just disallow loading any directory inodes with EXT4_INDEX_FL when
      DIR_INDEX is not enabled. This is harsh but it should be very rare (it
      means someone disabled DIR_INDEX on existing filesystem and didn't run
      e2fsck), e2fsck can fix the problem, and we don't want to answer the
      difficult question: "Should we rather corrupt the directory more or
      should we ignore that DIR_INDEX feature is not set?"
      
      2) When we find out htree structure is corrupted (but the filesystem and
      the directory should in support htrees), we continue just ignoring htree
      information for reading but we refuse to add new entries to the
      directory to avoid corrupting it more.
      
      Link: https://lore.kernel.org/r/20200210144316.22081-1-jack@suse.cz
      Fixes: dbe89444 ("ext4: Calculate and verify checksums for htree nodes")
      Reviewed-by: NAndreas Dilger <adilger@dilger.ca>
      Signed-off-by: NJan Kara <jack@suse.cz>
      Signed-off-by: NTheodore Ts'o <tytso@mit.edu>
      Cc: stable@kernel.org
      48a34311
  13. 18 1月, 2020 4 次提交
  14. 27 12月, 2019 3 次提交
  15. 07 11月, 2019 1 次提交
    • E
      ext4: add support for IV_INO_LBLK_64 encryption policies · b925acb8
      Eric Biggers 提交于
      IV_INO_LBLK_64 encryption policies have special requirements from the
      filesystem beyond those of the existing encryption policies:
      
      - Inode numbers must never change, even if the filesystem is resized.
      - Inode numbers must be <= 32 bits.
      - File logical block numbers must be <= 32 bits.
      
      ext4 has 32-bit inode and file logical block numbers.  However,
      resize2fs can re-number inodes when shrinking an ext4 filesystem.
      
      However, typically the people who would want to use this format don't
      care about filesystem shrinking.  They'd be fine with a solution that
      just prevents the filesystem from being shrunk.
      
      Therefore, add a new feature flag EXT4_FEATURE_COMPAT_STABLE_INODES that
      will do exactly that.  Then wire up the fscrypt_operations to expose
      this flag to fs/crypto/, so that it allows IV_INO_LBLK_64 policies when
      this flag is set.
      Acked-by: NTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: NEric Biggers <ebiggers@google.com>
      b925acb8
  16. 06 11月, 2019 3 次提交
    • J
      ext4: Reserve revoke credits for freed blocks · 83448bdf
      Jan Kara 提交于
      So far we have reserved only relatively high fixed amount of revoke
      credits for each transaction. We over-reserved by large amount for most
      cases but when freeing large directories or files with data journalling,
      the fixed amount is not enough. In fact the worst case estimate is
      inconveniently large (maximum extent size) for freeing of one extent.
      
      We fix this by doing proper estimate of the amount of blocks that need
      to be revoked when removing blocks from the inode due to truncate or
      hole punching and otherwise reserve just a small amount of revoke
      credits for each transaction to accommodate freeing of xattrs block or
      so.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20191105164437.32602-23-jack@suse.czSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
      83448bdf
    • J
      ext4: Provide function to handle transaction restarts · a4130367
      Jan Kara 提交于
      Provide ext4_journal_ensure_credits_fn() function to ensure transaction
      has given amount of credits and call helper function to prepare for
      restarting a transaction. This allows to remove some boilerplate code
      from various places, add proper error handling for the case where
      transaction extension or restart fails, and reduces following changes
      needed for proper revoke record reservation tracking.
      Signed-off-by: NJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20191105164437.32602-10-jack@suse.czSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
      a4130367
    • M
      ext4: introduce direct I/O write using iomap infrastructure · 378f32ba
      Matthew Bobrowski 提交于
      This patch introduces a new direct I/O write path which makes use of
      the iomap infrastructure.
      
      All direct I/O writes are now passed from the ->write_iter() callback
      through to the new direct I/O handler ext4_dio_write_iter(). This
      function is responsible for calling into the iomap infrastructure via
      iomap_dio_rw().
      
      Code snippets from the existing direct I/O write code within
      ext4_file_write_iter() such as, checking whether the I/O request is
      unaligned asynchronous I/O, or whether the write will result in an
      overwrite have effectively been moved out and into the new direct I/O
      ->write_iter() handler.
      The block mapping flags that are eventually passed down to
      ext4_map_blocks() from the *_get_block_*() suite of routines have been
      taken out and introduced within ext4_iomap_alloc().
      
      For inode extension cases, ext4_handle_inode_extension() is
      effectively the function responsible for performing such metadata
      updates. This is called after iomap_dio_rw() has returned so that we
      can safely determine whether we need to potentially truncate any
      allocated blocks that may have been prepared for this direct I/O
      write. We don't perform the inode extension, or truncate operations
      from the ->end_io() handler as we don't have the original I/O 'length'
      available there. The ->end_io() however is responsible fo converting
      allocated unwritten extents to written extents.
      
      In the instance of a short write, we fallback and complete the
      remainder of the I/O using buffered I/O via
      ext4_buffered_write_iter().
      
      The existing buffer_head direct I/O implementation has been removed as
      it's now redundant.
      
      [ Fix up ext4_dio_write_iter() per Jan's comments at
        https://lore.kernel.org/r/20191105135932.GN22379@quack2.suse.cz -- TYT ]
      Signed-off-by: NMatthew Bobrowski <mbobrowski@mbobrowski.org>
      Reviewed-by: NJan Kara <jack@suse.cz>
      Reviewed-by: NRitesh Harjani <riteshh@linux.ibm.com>
      Link: https://lore.kernel.org/r/e55db6f12ae6ff017f36774135e79f3e7b0333da.1572949325.git.mbobrowski@mbobrowski.orgSigned-off-by: NTheodore Ts'o <tytso@mit.edu>
      378f32ba