An error occurred fetching the project authors.
  1. 26 Mar, 2020 3 commits
    • Eric Sandeen's avatar
      ext4: do not commit super on read-only bdev · c96e2b85
      Eric Sandeen authored
      Under some circumstances we may encounter a filesystem error on a
      read-only block device, and if we try to save the error info to the
      superblock and commit it, we'll wind up with a noisy error and
      backtrace, i.e.:
      
      [ 3337.146838] EXT4-fs error (device pmem1p2): ext4_get_journal_inode:4634: comm mount: inode #0: comm mount: iget: illegal inode #
      ------------[ cut here ]------------
      generic_make_request: Trying to write to read-only block-device pmem1p2 (partno 2)
      WARNING: CPU: 107 PID: 115347 at block/blk-core.c:788 generic_make_request_checks+0x6b4/0x7d0
      ...
      
      To avoid this, commit the error info in the superblock only if the
      block device is writable.
      Reported-by: default avatarRitesh Harjani <riteshh@linux.ibm.com>
      Signed-off-by: default avatarEric Sandeen <sandeen@redhat.com>
      Reviewed-by: default avatarAndreas Dilger <adilger@dilger.ca>
      Link: https://lore.kernel.org/r/4b6e774d-cc00-3469-7abb-108eb151071a@sandeen.netSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      c96e2b85
    • Ritesh Harjani's avatar
      ext4: unregister sysfs path before destroying jbd2 journal · 5e47868f
      Ritesh Harjani authored
      Call ext4_unregister_sysfs(), before destroying jbd2 journal,
      since below might cause, NULL pointer dereference issue.
      This got reported with LTP tests.
      
      ext4_put_super() 		cat /sys/fs/ext4/loop2/journal_task
      	| 				ext4_attr_show();
      ext4_jbd2_journal_destroy();  			|
          	|				 journal_task_show()
      	| 					|
      	| 				task_pid_vnr(NULL);
      sbi->s_journal = NULL;
      Signed-off-by: default avatarRitesh Harjani <riteshh@linux.ibm.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20200318061301.4320-1-riteshh@linux.ibm.comSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      5e47868f
    • Ritesh Harjani's avatar
      ext4: check for non-zero journal inum in ext4_calculate_overhead · f1eec3b0
      Ritesh Harjani authored
      While calculating overhead for internal journal, also check
      that j_inum shouldn't be 0. Otherwise we get below error with
      xfstests generic/050 with external journal (XXX_LOGDEV config) enabled.
      
      It could be simply reproduced with loop device with an external journal
      and marking blockdev as RO before mounting.
      
      [ 3337.146838] EXT4-fs error (device pmem1p2): ext4_get_journal_inode:4634: comm mount: inode #0: comm mount: iget: illegal inode #
      ------------[ cut here ]------------
      generic_make_request: Trying to write to read-only block-device pmem1p2 (partno 2)
      WARNING: CPU: 107 PID: 115347 at block/blk-core.c:788 generic_make_request_checks+0x6b4/0x7d0
      CPU: 107 PID: 115347 Comm: mount Tainted: G             L   --------- -t - 4.18.0-167.el8.ppc64le #1
      NIP:  c0000000006f6d44 LR: c0000000006f6d40 CTR: 0000000030041dd4
      <...>
      NIP [c0000000006f6d44] generic_make_request_checks+0x6b4/0x7d0
      LR [c0000000006f6d40] generic_make_request_checks+0x6b0/0x7d0
      <...>
      Call Trace:
      generic_make_request_checks+0x6b0/0x7d0 (unreliable)
      generic_make_request+0x3c/0x420
      submit_bio+0xd8/0x200
      submit_bh_wbc+0x1e8/0x250
      __sync_dirty_buffer+0xd0/0x210
      ext4_commit_super+0x310/0x420 [ext4]
      __ext4_error+0xa4/0x1e0 [ext4]
      __ext4_iget+0x388/0xe10 [ext4]
      ext4_get_journal_inode+0x40/0x150 [ext4]
      ext4_calculate_overhead+0x5a8/0x610 [ext4]
      ext4_fill_super+0x3188/0x3260 [ext4]
      mount_bdev+0x778/0x8f0
      ext4_mount+0x28/0x50 [ext4]
      mount_fs+0x74/0x230
      vfs_kern_mount.part.6+0x6c/0x250
      do_mount+0x2fc/0x1280
      sys_mount+0x158/0x180
      system_call+0x5c/0x70
      EXT4-fs (pmem1p2): no journal found
      EXT4-fs (pmem1p2): can't get journal size
      EXT4-fs (pmem1p2): mounted filesystem without journal. Opts: dax,norecovery
      
      Fixes: 3c816ded ("ext4: use journal inode to determine journal overhead")
      Reported-by: default avatarHarish Sriram <harish@linux.ibm.com>
      Signed-off-by: default avatarRitesh Harjani <riteshh@linux.ibm.com>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      Link: https://lore.kernel.org/r/20200316093038.25485-1-riteshh@linux.ibm.comSigned-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      f1eec3b0
  2. 05 Mar, 2020 1 commit
  3. 29 Feb, 2020 1 commit
  4. 22 Feb, 2020 3 commits
  5. 21 Feb, 2020 1 commit
  6. 15 Feb, 2020 1 commit
  7. 13 Feb, 2020 2 commits
  8. 04 Feb, 2020 1 commit
  9. 25 Jan, 2020 2 commits
  10. 17 Jan, 2020 3 commits
  11. 26 Dec, 2019 1 commit
  12. 23 Dec, 2019 1 commit
  13. 15 Dec, 2019 1 commit
  14. 19 Nov, 2019 1 commit
  15. 15 Nov, 2019 2 commits
  16. 14 Nov, 2019 2 commits
  17. 06 Nov, 2019 1 commit
    • Eric Biggers's avatar
      ext4: add support for IV_INO_LBLK_64 encryption policies · b925acb8
      Eric Biggers authored
      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: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      b925acb8
  18. 04 Nov, 2019 1 commit
  19. 22 Oct, 2019 1 commit
  20. 30 Aug, 2019 1 commit
    • Deepa Dinamani's avatar
      ext4: Initialize timestamps limits · 4881c497
      Deepa Dinamani authored
      ext4 has different overflow limits for max filesystem
      timestamps based on the extra bytes available.
      
      The timestamp limits are calculated according to the
      encoding table in
      a4dad1aei(ext4: Fix handling of extended tv_sec):
      
      * extra  msb of                         adjust for signed
      * epoch  32-bit                         32-bit tv_sec to
      * bits   time    decoded 64-bit tv_sec  64-bit tv_sec      valid time range
      * 0 0    1    -0x80000000..-0x00000001  0x000000000   1901-12-13..1969-12-31
      * 0 0    0    0x000000000..0x07fffffff  0x000000000   1970-01-01..2038-01-19
      * 0 1    1    0x080000000..0x0ffffffff  0x100000000   2038-01-19..2106-02-07
      * 0 1    0    0x100000000..0x17fffffff  0x100000000   2106-02-07..2174-02-25
      * 1 0    1    0x180000000..0x1ffffffff  0x200000000   2174-02-25..2242-03-16
      * 1 0    0    0x200000000..0x27fffffff  0x200000000   2242-03-16..2310-04-04
      * 1 1    1    0x280000000..0x2ffffffff  0x300000000   2310-04-04..2378-04-22
      * 1 1    0    0x300000000..0x37fffffff  0x300000000   2378-04-22..2446-05-10
      
      Note that the time limits are not correct for deletion times.
      
      Added a warn when an inode cannot be extended to incorporate an
      extended timestamp.
      Signed-off-by: default avatarDeepa Dinamani <deepa.kernel@gmail.com>
      Reviewed-by: default avatarAndreas Dilger <adilger@dilger.ca>
      Acked-by: default avatarJeff Layton <jlayton@kernel.org>
      Cc: tytso@mit.edu
      Cc: adilger.kernel@dilger.ca
      Cc: linux-ext4@vger.kernel.org
      4881c497
  21. 28 Aug, 2019 1 commit
    • zhangyi (F)'s avatar
      ext4: fix integer overflow when calculating commit interval · 9ba55543
      zhangyi (F) authored
      If user specify a large enough value of "commit=" option, it may trigger
      signed integer overflow which may lead to sbi->s_commit_interval becomes
      a large or small value, zero in particular.
      
      UBSAN: Undefined behaviour in ../fs/ext4/super.c:1592:31
      signed integer overflow:
      536870912 * 1000 cannot be represented in type 'int'
      [...]
      Call trace:
      [...]
      [<ffffff9008a2d120>] ubsan_epilogue+0x34/0x9c lib/ubsan.c:166
      [<ffffff9008a2d8b8>] handle_overflow+0x228/0x280 lib/ubsan.c:197
      [<ffffff9008a2d95c>] __ubsan_handle_mul_overflow+0x4c/0x68 lib/ubsan.c:218
      [<ffffff90086d070c>] handle_mount_opt fs/ext4/super.c:1592 [inline]
      [<ffffff90086d070c>] parse_options+0x1724/0x1a40 fs/ext4/super.c:1773
      [<ffffff90086d51c4>] ext4_remount+0x2ec/0x14a0 fs/ext4/super.c:4834
      [...]
      
      Although it is not a big deal, still silence the UBSAN by limit the
      input value.
      Signed-off-by: default avatarzhangyi (F) <yi.zhang@huawei.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarJan Kara <jack@suse.cz>
      9ba55543
  22. 13 Aug, 2019 3 commits
    • Eric Biggers's avatar
      ext4: add fs-verity read support · 22cfe4b4
      Eric Biggers authored
      Make ext4_mpage_readpages() verify data as it is read from fs-verity
      files, using the helper functions from fs/verity/.
      
      To support both encryption and verity simultaneously, this required
      refactoring the decryption workflow into a generic "post-read
      processing" workflow which can do decryption, verification, or both.
      
      The case where the ext4 block size is not equal to the PAGE_SIZE is not
      supported yet, since in that case ext4_mpage_readpages() sometimes falls
      back to block_read_full_page(), which does not support fs-verity yet.
      Co-developed-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      22cfe4b4
    • Eric Biggers's avatar
      ext4: add basic fs-verity support · c93d8f88
      Eric Biggers authored
      Add most of fs-verity support to ext4.  fs-verity is a filesystem
      feature that enables transparent integrity protection and authentication
      of read-only files.  It uses a dm-verity like mechanism at the file
      level: a Merkle tree is used to verify any block in the file in
      log(filesize) time.  It is implemented mainly by helper functions in
      fs/verity/.  See Documentation/filesystems/fsverity.rst for the full
      documentation.
      
      This commit adds all of ext4 fs-verity support except for the actual
      data verification, including:
      
      - Adding a filesystem feature flag and an inode flag for fs-verity.
      
      - Implementing the fsverity_operations to support enabling verity on an
        inode and reading/writing the verity metadata.
      
      - Updating ->write_begin(), ->write_end(), and ->writepages() to support
        writing verity metadata pages.
      
      - Calling the fs-verity hooks for ->open(), ->setattr(), and ->ioctl().
      
      ext4 stores the verity metadata (Merkle tree and fsverity_descriptor)
      past the end of the file, starting at the first 64K boundary beyond
      i_size.  This approach works because (a) verity files are readonly, and
      (b) pages fully beyond i_size aren't visible to userspace but can be
      read/written internally by ext4 with only some relatively small changes
      to ext4.  This approach avoids having to depend on the EA_INODE feature
      and on rearchitecturing ext4's xattr support to support paging
      multi-gigabyte xattrs into memory, and to support encrypting xattrs.
      Note that the verity metadata *must* be encrypted when the file is,
      since it contains hashes of the plaintext data.
      
      This patch incorporates work by Theodore Ts'o and Chandan Rajendra.
      Reviewed-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      c93d8f88
    • Eric Biggers's avatar
      ext4: wire up new fscrypt ioctls · 29b3692e
      Eric Biggers authored
      Wire up the new ioctls for adding and removing fscrypt keys to/from the
      filesystem, and the new ioctl for retrieving v2 encryption policies.
      
      The key removal ioctls also required making ext4_drop_inode() call
      fscrypt_drop_inode().
      
      For more details see Documentation/filesystems/fscrypt.rst and the
      fscrypt patches that added the implementation of these ioctls.
      Reviewed-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      29b3692e
  23. 17 May, 2019 1 commit
  24. 12 May, 2019 1 commit
  25. 02 May, 2019 1 commit
  26. 01 May, 2019 1 commit
  27. 25 Apr, 2019 2 commits
    • Gabriel Krisman Bertazi's avatar
      ext4: Support case-insensitive file name lookups · b886ee3e
      Gabriel Krisman Bertazi authored
      This patch implements the actual support for case-insensitive file name
      lookups in ext4, based on the feature bit and the encoding stored in the
      superblock.
      
      A filesystem that has the casefold feature set is able to configure
      directories with the +F (EXT4_CASEFOLD_FL) attribute, enabling lookups
      to succeed in that directory in a case-insensitive fashion, i.e: match
      a directory entry even if the name used by userspace is not a byte per
      byte match with the disk name, but is an equivalent case-insensitive
      version of the Unicode string.  This operation is called a
      case-insensitive file name lookup.
      
      The feature is configured as an inode attribute applied to directories
      and inherited by its children.  This attribute can only be enabled on
      empty directories for filesystems that support the encoding feature,
      thus preventing collision of file names that only differ by case.
      
      * dcache handling:
      
      For a +F directory, Ext4 only stores the first equivalent name dentry
      used in the dcache. This is done to prevent unintentional duplication of
      dentries in the dcache, while also allowing the VFS code to quickly find
      the right entry in the cache despite which equivalent string was used in
      a previous lookup, without having to resort to ->lookup().
      
      d_hash() of casefolded directories is implemented as the hash of the
      casefolded string, such that we always have a well-known bucket for all
      the equivalencies of the same string. d_compare() uses the
      utf8_strncasecmp() infrastructure, which handles the comparison of
      equivalent, same case, names as well.
      
      For now, negative lookups are not inserted in the dcache, since they
      would need to be invalidated anyway, because we can't trust missing file
      dentries.  This is bad for performance but requires some leveraging of
      the vfs layer to fix.  We can live without that for now, and so does
      everyone else.
      
      * on-disk data:
      
      Despite using a specific version of the name as the internal
      representation within the dcache, the name stored and fetched from the
      disk is a byte-per-byte match with what the user requested, making this
      implementation 'name-preserving'. i.e. no actual information is lost
      when writing to storage.
      
      DX is supported by modifying the hashes used in +F directories to make
      them case/encoding-aware.  The new disk hashes are calculated as the
      hash of the full casefolded string, instead of the string directly.
      This allows us to efficiently search for file names in the htree without
      requiring the user to provide an exact name.
      
      * Dealing with invalid sequences:
      
      By default, when a invalid UTF-8 sequence is identified, ext4 will treat
      it as an opaque byte sequence, ignoring the encoding and reverting to
      the old behavior for that unique file.  This means that case-insensitive
      file name lookup will not work only for that file.  An optional bit can
      be set in the superblock telling the filesystem code and userspace tools
      to enforce the encoding.  When that optional bit is set, any attempt to
      create a file name using an invalid UTF-8 sequence will fail and return
      an error to userspace.
      
      * Normalization algorithm:
      
      The UTF-8 algorithms used to compare strings in ext4 is implemented
      lives in fs/unicode, and is based on a previous version developed by
      SGI.  It implements the Canonical decomposition (NFD) algorithm
      described by the Unicode specification 12.1, or higher, combined with
      the elimination of ignorable code points (NFDi) and full
      case-folding (CF) as documented in fs/unicode/utf8_norm.c.
      
      NFD seems to be the best normalization method for EXT4 because:
      
        - It has a lower cost than NFC/NFKC (which requires
          decomposing to NFD as an intermediary step)
        - It doesn't eliminate important semantic meaning like
          compatibility decompositions.
      
      Although:
      
        - This implementation is not completely linguistic accurate, because
        different languages have conflicting rules, which would require the
        specialization of the filesystem to a given locale, which brings all
        sorts of problems for removable media and for users who use more than
        one language.
      Signed-off-by: default avatarGabriel Krisman Bertazi <krisman@collabora.co.uk>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      b886ee3e
    • Gabriel Krisman Bertazi's avatar
      ext4: include charset encoding information in the superblock · c83ad55e
      Gabriel Krisman Bertazi authored
      Support for encoding is considered an incompatible feature, since it has
      potential to create collisions of file names in existing filesystems.
      If the feature flag is not enabled, the entire filesystem will operate
      on opaque byte sequences, respecting the original behavior.
      
      The s_encoding field stores a magic number indicating the encoding
      format and version used globally by file and directory names in the
      filesystem.  The s_encoding_flags defines policies for using the charset
      encoding, like how to handle invalid sequences.  The magic number is
      mapped to the exact charset table, but the mapping is specific to ext4.
      Since we don't have any commitment to support old encodings, the only
      encoding I am supporting right now is utf8-12.1.0.
      
      The current implementation prevents the user from enabling encoding and
      per-directory encryption on the same filesystem at the same time.  The
      incompatibility between these features lies in how we do efficient
      directory searches when we cannot be sure the encryption of the user
      provided fname will match the actual hash stored in the disk without
      decrypting every directory entry, because of normalization cases.  My
      quickest solution is to simply block the concurrent use of these
      features for now, and enable it later, once we have a better solution.
      Signed-off-by: default avatarGabriel Krisman Bertazi <krisman@collabora.co.uk>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      c83ad55e