1. 12 Aug, 2023 5 commits
    • Amir Goldstein's avatar
      ovl: support encoding non-decodable file handles · 16aac5ad
      Amir Goldstein authored
      When all layers support file handles, we support encoding non-decodable
      file handles (a.k.a. fid) even with nfs_export=off.
      
      When file handles do not need to be decoded, we do not need to copy up
      redirected lower directories on encode, and we encode also non-indexed
      upper with lower file handle, so fid will not change on copy up.
      
      This enables reporting fanotify events with file handles on overlayfs
      with default config/mount options.
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      16aac5ad
    • Alexander Larsson's avatar
      ovl: Handle verity during copy-up · 0c71faf5
      Alexander Larsson authored
      During regular metacopy, if lowerdata file has fs-verity enabled, and
      the verity option is enabled, we add the digest to the metacopy xattr.
      
      If verity is required, and lowerdata does not have fs-verity enabled,
      fall back to full copy-up (or the generated metacopy would not
      validate).
      Signed-off-by: default avatarAlexander Larsson <alexl@redhat.com>
      Reviewed-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      0c71faf5
    • Alexander Larsson's avatar
      ovl: Validate verity xattr when resolving lowerdata · 184996e9
      Alexander Larsson authored
      The new digest field in the metacopy xattr is used during lookup to
      record whether the header contained a digest in the OVL_HAS_DIGEST
      flags.
      
      When accessing file data the first time, if OVL_HAS_DIGEST is set, we
      reload the metadata and check that the source lowerdata inode matches
      the specified digest in it (according to the enabled verity
      options). If the verity check passes we store this info in the inode
      flags as OVL_VERIFIED_DIGEST, so that we can avoid doing it again if
      the inode remains in memory.
      
      The verification is done in ovl_maybe_validate_verity() which needs to
      be called in the same places as ovl_maybe_lookup_lowerdata(), so there
      is a new ovl_verify_lowerdata() helper that calls these in the right
      order, and all current callers of ovl_maybe_lookup_lowerdata() are
      changed to call it instead.
      Signed-off-by: default avatarAlexander Larsson <alexl@redhat.com>
      Reviewed-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      184996e9
    • Alexander Larsson's avatar
      ovl: Add versioned header for overlay.metacopy xattr · bf070890
      Alexander Larsson authored
      Historically overlay.metacopy was a zero-size xattr, and it's
      existence marked a metacopy file. This change adds a versioned header
      with a flag field, a length and a digest. The initial use-case of this
      will be for validating a fs-verity digest, but the flags field could
      also be used later for other new features.
      
      ovl_check_metacopy_xattr() now returns the size of the xattr,
      emulating a size of OVL_METACOPY_MIN_SIZE for empty xattrs to
      distinguish it from the no-xattr case.
      Signed-off-by: default avatarAlexander Larsson <alexl@redhat.com>
      Reviewed-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      bf070890
    • Alexander Larsson's avatar
      ovl: Add framework for verity support · ae8cba40
      Alexander Larsson authored
      This adds the scaffolding (docs, config, mount options) for supporting
      the new digest field in the metacopy xattr. This contains a fs-verity
      digest that need to match the fs-verity digest of the lowerdata
      file. The mount option "verity" specifies how this xattr is handled.
      
      If you enable verity ("verity=on") all existing xattrs are validated
      before use, and during metacopy we generate verity xattr in the upper
      metacopy file (if the source file has verity enabled). This means
      later accesses can guarantee that the same data is used.
      
      Additionally you can use "verity=require". In this mode all metacopy
      files must have a valid verity xattr. For this to work metadata
      copy-up must be able to create a verity xattr (so that later accesses
      are validated). Therefore, in this mode, if the lower data file
      doesn't have fs-verity enabled we fall back to a full copy rather than
      a metacopy.
      
      Actual implementation follows in a separate commit.
      Signed-off-by: default avatarAlexander Larsson <alexl@redhat.com>
      Reviewed-by: default avatarAmir Goldstein <amir73il@gmail.com>
      Acked-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarAmir Goldstein <amir73il@gmail.com>
      ae8cba40
  2. 06 Aug, 2023 8 commits
    • Linus Torvalds's avatar
      Linux 6.5-rc5 · 52a93d39
      Linus Torvalds authored
      52a93d39
    • Linus Torvalds's avatar
      Merge tag 'v6.5-rc5.vfs.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs · 0108963f
      Linus Torvalds authored
      Pull vfs fixes from Christian Brauner:
      
       - Fix a wrong check for O_TMPFILE during RESOLVE_CACHED lookup
      
       - Clean up directory iterators and clarify file_needs_f_pos_lock()
      
      * tag 'v6.5-rc5.vfs.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
        fs: rely on ->iterate_shared to determine f_pos locking
        vfs: get rid of old '->iterate' directory operation
        proc: fix missing conversion to 'iterate_shared'
        open: make RESOLVE_CACHED correctly test for O_TMPFILE
      0108963f
    • Christian Brauner's avatar
      fs: rely on ->iterate_shared to determine f_pos locking · 7d84d1b9
      Christian Brauner authored
      Now that we removed ->iterate we don't need to check for either
      ->iterate or ->iterate_shared in file_needs_f_pos_lock(). Simply check
      for ->iterate_shared instead. This will tell us whether we need to
      unconditionally take the lock. Not just does it allow us to avoid
      checking f_inode's mode it also actually clearly shows that we're
      locking because of readdir.
      Signed-off-by: default avatarChristian Brauner <brauner@kernel.org>
      7d84d1b9
    • Linus Torvalds's avatar
      vfs: get rid of old '->iterate' directory operation · 3e327154
      Linus Torvalds authored
      All users now just use '->iterate_shared()', which only takes the
      directory inode lock for reading.
      
      Filesystems that never got convered to shared mode now instead use a
      wrapper that drops the lock, re-takes it in write mode, calls the old
      function, and then downgrades the lock back to read mode.
      
      This way the VFS layer and other callers no longer need to care about
      filesystems that never got converted to the modern era.
      
      The filesystems that use the new wrapper are ceph, coda, exfat, jfs,
      ntfs, ocfs2, overlayfs, and vboxsf.
      
      Honestly, several of them look like they really could just iterate their
      directories in shared mode and skip the wrapper entirely, but the point
      of this change is to not change semantics or fix filesystems that
      haven't been fixed in the last 7+ years, but to finally get rid of the
      dual iterators.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarChristian Brauner <brauner@kernel.org>
      3e327154
    • Linus Torvalds's avatar
      proc: fix missing conversion to 'iterate_shared' · 0a2c2baa
      Linus Torvalds authored
      I'm looking at the directory handling due to the discussion about f_pos
      locking (see commit 79796425: "file: reinstate f_pos locking
      optimization for regular files"), and wanting to clean that up.
      
      And one source of ugliness is how we were supposed to move filesystems
      over to the '->iterate_shared()' function that only takes the inode lock
      for reading many many years ago, but several filesystems still use the
      bad old '->iterate()' that takes the inode lock for exclusive access.
      
      See commit 61922694 ("introduce a parallel variant of ->iterate()")
      that also added some documentation stating
      
            Old method is only used if the new one is absent; eventually it will
            be removed.  Switch while you still can; the old one won't stay.
      
      and that was back in April 2016.  Here we are, many years later, and the
      old version is still clearly sadly alive and well.
      
      Now, some of those old style iterators are probably just because the
      filesystem may end up having per-inode mutable data that it uses for
      iterating a directory, but at least one case is just a mistake.
      
      Al switched over most filesystems to use '->iterate_shared()' back when
      it was introduced.  In particular, the /proc filesystem was converted as
      one of the first ones in commit f50752ea ("switch all procfs
      directories ->iterate_shared()").
      
      But then later one new user of '->iterate()' was then re-introduced by
      commit 6d9c939d ("procfs: add smack subdir to attrs").
      
      And that's clearly not what we wanted, since that new case just uses the
      same 'proc_pident_readdir()' and 'proc_pident_lookup()' helper functions
      that other /proc pident directories use, and they are most definitely
      safe to use with the inode lock held shared.
      
      So just fix it.
      
      This still leaves a fair number of oddball filesystems using the
      old-style directory iterator (ceph, coda, exfat, jfs, ntfs, ocfs2,
      overlayfs, and vboxsf), but at least we don't have any remaining in the
      core filesystems.
      
      I'm going to add a wrapper function that just drops the read-lock and
      takes it as a write lock, so that we can clean up the core vfs layer and
      make all the ugly 'this filesystem needs exclusive inode locking' be
      just filesystem-internal warts.
      
      I just didn't want to make that conversion when we still had a core user
      left.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarChristian Brauner <brauner@kernel.org>
      0a2c2baa
    • Aleksa Sarai's avatar
      open: make RESOLVE_CACHED correctly test for O_TMPFILE · a0fc452a
      Aleksa Sarai authored
      O_TMPFILE is actually __O_TMPFILE|O_DIRECTORY. This means that the old
      fast-path check for RESOLVE_CACHED would reject all users passing
      O_DIRECTORY with -EAGAIN, when in fact the intended test was to check
      for __O_TMPFILE.
      
      Cc: stable@vger.kernel.org # v5.12+
      Fixes: 99668f61 ("fs: expose LOOKUP_CACHED through openat2() RESOLVE_CACHED")
      Signed-off-by: default avatarAleksa Sarai <cyphar@cyphar.com>
      Message-Id: <20230806-resolve_cached-o_tmpfile-v1-1-7ba16308465e@cyphar.com>
      Signed-off-by: default avatarChristian Brauner <brauner@kernel.org>
      a0fc452a
    • Linus Torvalds's avatar
      Merge tag 'rust-fixes-6.5-rc5' of https://github.com/Rust-for-Linux/linux · f0ab9f34
      Linus Torvalds authored
      Pull rust fixes from Miguel Ojeda:
      
       - Allocator: prevent mis-aligned allocation
      
       - Types: delete 'ForeignOwnable::borrow_mut'. A sound replacement is
         planned for the merge window
      
       - Build: fix bindgen error with UBSAN_BOUNDS_STRICT
      
      * tag 'rust-fixes-6.5-rc5' of https://github.com/Rust-for-Linux/linux:
        rust: fix bindgen build error with UBSAN_BOUNDS_STRICT
        rust: delete `ForeignOwnable::borrow_mut`
        rust: allocator: Prevent mis-aligned allocation
      f0ab9f34
    • Linus Torvalds's avatar
      Merge tag 'ata-6.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata · fb0d9199
      Linus Torvalds authored
      Pull ata fix from Damien Le Moal:
      
       - Prevent the scsi disk driver from issuing a START STOP UNIT command
         for ATA devices during system resume as this causes various issues
         reported by multiple users.
      
      * tag 'ata-6.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/dlemoal/libata:
        ata,scsi: do not issue START STOP UNIT on resume
      fb0d9199
  3. 05 Aug, 2023 5 commits
  4. 04 Aug, 2023 13 commits
  5. 03 Aug, 2023 9 commits