1. 02 Mar, 2017 1 commit
  2. 05 Feb, 2017 1 commit
  3. 31 Dec, 2016 1 commit
    • Eric Biggers's avatar
      fscrypt: use ENOKEY when file cannot be created w/o key · 54475f53
      Eric Biggers authored
      As part of an effort to clean up fscrypt-related error codes, make
      attempting to create a file in an encrypted directory that hasn't been
      "unlocked" fail with ENOKEY.  Previously, several error codes were used
      for this case, including ENOENT, EACCES, and EPERM, and they were not
      consistent between and within filesystems.  ENOKEY is a better choice
      because it expresses that the failure is due to lacking the encryption
      key.  It also matches the error code returned when trying to open an
      encrypted regular file without the key.
      I am not aware of any users who might be relying on the previous
      inconsistent error codes, which were never documented anywhere.
      This failure case will be exercised by an xfstest.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
  4. 21 Nov, 2016 1 commit
    • Eric Biggers's avatar
      ext4: avoid lockdep warning when inheriting encryption context · 2f8f5e76
      Eric Biggers authored
      On a lockdep-enabled kernel, xfstests generic/027 fails due to a lockdep
      warning when run on ext4 mounted with -o test_dummy_encryption:
          xfs_io/4594 is trying to acquire lock:
          ){++++.+}, at:
          [<ffffffff813096ef>] jbd2_log_wait_commit+0x5/0x11b
          but task is already holding lock:
          ){++++.+}, at:
          [<ffffffff813000de>] start_this_handle+0x354/0x3d8
      The abbreviated call stack is:
       [<ffffffff813096ef>] ? jbd2_log_wait_commit+0x5/0x11b
       [<ffffffff8130972a>] jbd2_log_wait_commit+0x40/0x11b
       [<ffffffff813096ef>] ? jbd2_log_wait_commit+0x5/0x11b
       [<ffffffff8130987b>] ? __jbd2_journal_force_commit+0x76/0xa6
       [<ffffffff81309896>] __jbd2_journal_force_commit+0x91/0xa6
       [<ffffffff813098b9>] jbd2_journal_force_commit_nested+0xe/0x18
       [<ffffffff812a6049>] ext4_should_retry_alloc+0x72/0x79
       [<ffffffff812f0c1f>] ext4_xattr_set+0xef/0x11f
       [<ffffffff812cc35b>] ext4_set_context+0x3a/0x16b
       [<ffffffff81258123>] fscrypt_inherit_context+0xe3/0x103
       [<ffffffff812ab611>] __ext4_new_inode+0x12dc/0x153a
       [<ffffffff812bd371>] ext4_create+0xb7/0x161
      When a file is created in an encrypted directory, ext4_set_context() is
      called to set an encryption context on the new file.  This calls
      ext4_xattr_set(), which contains a retry loop where the journal is
      forced to commit if an ENOSPC error is encountered.
      If the task actually were to wait for the journal to commit in this
      case, then it would deadlock because a handle remains open from
      __ext4_new_inode(), so the running transaction can't be committed yet.
      Fortunately, __jbd2_journal_force_commit() avoids the deadlock by not
      allowing the running transaction to be committed while the current task
      has it open.  However, the above lockdep warning is still triggered.
      This was a false positive which was introduced by: 1eaa566d: jbd2:
      track more dependencies on transaction commit
      Fix the problem by passing the handle through the 'fs_data' argument to
      ext4_set_context(), then using ext4_xattr_set_handle() instead of
      ext4_xattr_set().  And in the case where no journal handle is specified
      and ext4_set_context() has to open one, add an ENOSPC retry loop since
      in that case it is the outermost transaction.
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
  5. 15 Nov, 2016 1 commit
    • Deepa Dinamani's avatar
      ext4: use current_time() for inode timestamps · eeca7ea1
      Deepa Dinamani authored
      CURRENT_TIME_SEC and CURRENT_TIME are not y2038 safe.
      current_time() will be transitioned to be y2038 safe
      along with vfs.
      current_time() returns timestamps according to the
      granularities set in the super_block.
      The granularity check in ext4_current_time() to call
      current_time() or CURRENT_TIME_SEC is not required.
      Use current_time() directly to obtain timestamps
      unconditionally, and remove ext4_current_time().
      Quota files are assumed to be on the same filesystem.
      Hence, use current_time() for these files as well.
      Signed-off-by: default avatarDeepa Dinamani <deepa.kernel@gmail.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
  6. 06 Sep, 2016 1 commit
  7. 10 Jul, 2016 1 commit
  8. 07 Jun, 2016 1 commit
  9. 30 Apr, 2016 2 commits
    • Theodore Ts'o's avatar
      ext4: clean up error handling when orphan list is corrupted · 7827a7f6
      Theodore Ts'o authored
      Instead of just printing warning messages, if the orphan list is
      corrupted, declare the file system is corrupted.  If there are any
      reserved inodes in the orphaned inode list, declare the file system
      corrupted and stop right away to avoid doing more potential damage to
      the file system.
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
    • Theodore Ts'o's avatar
      ext4: fix hang when processing corrupted orphaned inode list · c9eb13a9
      Theodore Ts'o authored
      If the orphaned inode list contains inode #5, ext4_iget() returns a
      bad inode (since the bootloader inode should never be referenced
      directly).  Because of the bad inode, we end up processing the inode
      repeatedly and this hangs the machine.
      This can be reproduced via:
         mke2fs -t ext4 /tmp/foo.img 100
         debugfs -w -R "ssv last_orphan 5" /tmp/foo.img
         mount -o loop /tmp/foo.img /mnt
      (But don't do this if you are using an unpatched kernel if you care
      about the system staying functional.  :-)
      This bug was found by the port of American Fuzzy Lop into the kernel
      to find file system problems[1].  (Since it *only* happens if inode #5
      shows up on the orphan list --- 3, 7, 8, etc. won't do it, it's not
      surprising that AFL needed two hours before it found it.)
      [1] http://events.linuxfoundation.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf
      Cc: stable@vger.kernel.org
      Reported by: Vegard Nossum <vegard.nossum@oracle.com>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
  10. 10 Mar, 2016 1 commit
  11. 12 Feb, 2016 1 commit
  12. 08 Jan, 2016 1 commit
  13. 18 Oct, 2015 1 commit
  14. 17 Oct, 2015 2 commits
  15. 23 Jul, 2015 1 commit
  16. 31 May, 2015 1 commit
    • Theodore Ts'o's avatar
      ext4 crypto: encrypt tmpfile located in encryption protected directory · e709e9df
      Theodore Ts'o authored
      Factor out calls to ext4_inherit_context() and move them to
      __ext4_new_inode(); this fixes a problem where ext4_tmpfile() wasn't
      calling calling ext4_inherit_context(), so the temporary file wasn't
      getting protected.  Since the blocks for the tmpfile could end up on
      disk, they really should be protected if the tmpfile is created within
      the context of an encrypted directory.
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
  17. 18 May, 2015 1 commit
    • Theodore Ts'o's avatar
      ext4: clean up superblock encryption mode fields · f5aed2c2
      Theodore Ts'o authored
      The superblock fields s_file_encryption_mode and s_dir_encryption_mode
      are vestigal, so remove them as a cleanup.  While we're at it, allow
      file systems with both encryption and inline_data enabled at the same
      time to work correctly.  We can't have encrypted inodes with inline
      data, but there's no reason to prohibit unencrypted inodes from using
      the inline data feature.
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
  18. 16 Apr, 2015 1 commit
  19. 15 Apr, 2015 1 commit
  20. 12 Apr, 2015 2 commits
  21. 03 Apr, 2015 1 commit
  22. 30 Oct, 2014 1 commit
  23. 13 Oct, 2014 1 commit
  24. 12 Jul, 2014 1 commit
  25. 05 Jul, 2014 1 commit
    • Theodore Ts'o's avatar
      ext4: fix unjournalled bg descriptor while initializing inode bitmap · 61c219f5
      Theodore Ts'o authored
      The first time that we allocate from an uninitialized inode allocation
      bitmap, if the block allocation bitmap is also uninitalized, we need
      to get write access to the block group descriptor before we start
      modifying the block group descriptor flags and updating the free block
      count, etc.  Otherwise, there is the potential of a bad journal
      checksum (if journal checksums are enabled), and of the file system
      becoming inconsistent if we crash at exactly the wrong time.
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Cc: stable@vger.kernel.org
  26. 26 Jun, 2014 1 commit
  27. 08 Nov, 2013 1 commit
  28. 28 Aug, 2013 2 commits
  29. 17 Aug, 2013 1 commit
    • Theodore Ts'o's avatar
      ext4: avoid reusing recently deleted inodes in no journal mode · 19883bd9
      Theodore Ts'o authored
      In no journal mode, if an inode has recently been deleted, we
      shouldn't reuse it right away.  Otherwise it's possible, after an
      unclean shutdown, to hit a situation where a recently deleted inode
      gets reused for some other purpose before the inode table block has
      been written to disk.  However, if the directory entry has been
      updated, then the directory entry will be pointing at the old inode
      E2fsck will make sure the file system is consistent after the
      unclean shutdown.  However, if the recently deleted inode is a
      character mode device, or an inode with the immutable bit set, even
      after the file system has been fixed up by e2fsck, it can be
      possible for a *.pyc file to be pointing at a character mode
      device, and when python tries to open the *.pyc file, Hilarity
      Ensues.  We could change all of userspace to be very suspicious
      about stat'ing files before opening them, and clearing the
      immutable flag if necessary --- or we can just avoid reusing an
      inode number if it has been recently deleted.
      Google-Bug-Id: 10017573
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
  30. 26 Jul, 2013 1 commit
    • Theodore Ts'o's avatar
      ext4: make sure group number is bumped after a inode allocation race · a34eb503
      Theodore Ts'o authored
      When we try to allocate an inode, and there is a race between two
      CPU's trying to grab the same inode, _and_ this inode is the last free
      inode in the block group, make sure the group number is bumped before
      we continue searching the rest of the block groups.  Otherwise, we end
      up searching the current block group twice, and we end up skipping
      searching the last block group.  So in the unlikely situation where
      almost all of the inodes are allocated, it's possible that we will
      return ENOSPC even though there might be free inodes in that last
      block group.
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
      Cc: stable@vger.kernel.org
  31. 04 Jun, 2013 1 commit
  32. 20 Apr, 2013 1 commit
  33. 19 Apr, 2013 1 commit
    • Jan Kara's avatar
      ext4: move quota initialization out of inode allocation transaction · eb9cc7e1
      Jan Kara authored
      Inode allocation transaction is pretty heavy (246 credits with quotas
      and extents before previous patch, still around 200 after it).  This is
      mostly due to credits required for allocation of quota structures
      (credits there are heavily overestimated but it's difficult to make
      better estimates if we don't want to wire non-trivial assumptions about
      quota format into filesystem).
      So move quota initialization out of allocation transaction. That way
      transaction for quota structure allocation will be started only if we
      need to look up quota structure on disk (rare) and furthermore it will
      be started for each quota type separately, not for all of them at once.
      This reduces maximum transaction size to 34 is most cases and to 73 in
      the worst case.
      [ Modified by tytso to clean up the cleanup paths for error handling.
        Also use a separate call to ext4_std_error() for each failure so it
        is easier for someone who is debugging a problem in this function to
        determine which function call failed. ]
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatar"Theodore Ts'o" <tytso@mit.edu>
  34. 10 Apr, 2013 1 commit
  35. 12 Mar, 2013 1 commit
  36. 14 Feb, 2013 1 commit