This project is mirrored from https://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-rt-devel.git. Pull mirroring updated .
  1. 17 Dec, 2020 4 commits
  2. 03 Dec, 2020 4 commits
  3. 19 Nov, 2020 1 commit
    • Theodore Ts'o's avatar
      ext4: drop fast_commit from /proc/mounts · 704c2317
      Theodore Ts'o authored
      The options in /proc/mounts must be valid mount options --- and
      fast_commit is not a mount option.  Otherwise, command sequences like
      this will fail:
      
          # mount /dev/vdc /vdc
          # mkdir -p /vdc/phoronix_test_suite /pts
          # mount --bind /vdc/phoronix_test_suite /pts
          # mount -o remount,nodioread_nolock /pts
          mount: /pts: mount point not mounted or bad option.
      
      And in the system logs, you'll find:
      
          EXT4-fs (vdc): Unrecognized mount option "fast_commit" or missing value
      
      Fixes: 995a3ed6
      
       ("ext4: add fast_commit feature and handling for extended mount options")
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      704c2317
  4. 11 Nov, 2020 1 commit
  5. 07 Nov, 2020 7 commits
  6. 28 Oct, 2020 2 commits
  7. 22 Oct, 2020 5 commits
  8. 18 Oct, 2020 13 commits
  9. 22 Sep, 2020 2 commits
    • Eric Biggers's avatar
      fscrypt: make fscrypt_set_test_dummy_encryption() take a 'const char *' · c8c868ab
      Eric Biggers authored
      
      
      fscrypt_set_test_dummy_encryption() requires that the optional argument
      to the test_dummy_encryption mount option be specified as a substring_t.
      That doesn't work well with filesystems that use the new mount API,
      since the new way of parsing mount options doesn't use substring_t.
      
      Make it take the argument as a 'const char *' instead.
      
      Instead of moving the match_strdup() into the callers in ext4 and f2fs,
      make them just use arg->from directly.  Since the pattern is
      "test_dummy_encryption=%s", the argument will be null-terminated.
      Acked-by: default avatarJeff Layton <jlayton@kernel.org>
      Link: https://lore.kernel.org/r/20200917041136.178600-14-ebiggers@kernel.org
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      c8c868ab
    • Eric Biggers's avatar
      fscrypt: handle test_dummy_encryption in more logical way · ac4acb1f
      Eric Biggers authored
      The behavior of the test_dummy_encryption mount option is that when a
      new file (or directory or symlink) is created in an unencrypted
      directory, it's automatically encrypted using a dummy encryption policy.
      That's it; in particular, the encryption (or lack thereof) of existing
      files (or directories or symlinks) doesn't change.
      
      Unfortunately the implementation of test_dummy_encryption is a bit weird
      and confusing.  When test_dummy_encryption is enabled and a file is
      being created in an unencrypted directory, we set up an encryption key
      (->i_crypt_info) for the directory.  This isn't actually used to do any
      encryption, however, since the directory is still unencrypted!  Instead,
      ->i_crypt_info is only used for inheriting the encryption policy.
      
      One consequence of this is that the filesystem ends up providing a
      "dummy context" (policy + nonce) instead of a "dummy policy".  In
      commit ed318a6c
      
       ("fscrypt: support test_dummy_encryption=v2"), I
      mistakenly thought this was required.  However, actually the nonce only
      ends up being used to derive a key that is never used.
      
      Another consequence of this implementation is that it allows for
      'inode->i_crypt_info != NULL && !IS_ENCRYPTED(inode)', which is an edge
      case that can be forgotten about.  For example, currently
      FS_IOC_GET_ENCRYPTION_POLICY on an unencrypted directory may return the
      dummy encryption policy when the filesystem is mounted with
      test_dummy_encryption.  That seems like the wrong thing to do, since
      again, the directory itself is not actually encrypted.
      
      Therefore, switch to a more logical and maintainable implementation
      where the dummy encryption policy inheritance is done without setting up
      keys for unencrypted directories.  This involves:
      
      - Adding a function fscrypt_policy_to_inherit() which returns the
        encryption policy to inherit from a directory.  This can be a real
        policy, a dummy policy, or no policy.
      
      - Replacing struct fscrypt_dummy_context, ->get_dummy_context(), etc.
        with struct fscrypt_dummy_policy, ->get_dummy_policy(), etc.
      
      - Making fscrypt_fname_encrypted_size() take an fscrypt_policy instead
        of an inode.
      Acked-by: default avatarJaegeuk Kim <jaegeuk@kernel.org>
      Acked-by: default avatarJeff Layton <jlayton@kernel.org>
      Link: https://lore.kernel.org/r/20200917041136.178600-13-ebiggers@kernel.org
      
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      ac4acb1f
  10. 18 Sep, 2020 1 commit