Pull fsverity fixes from Eric Biggers:
 "Fixes for several bugs found by LLMs:

   - Fix bypass of IPE's fsverity support, and a use-after-free in
     certain cases, when FS_IOC_ENABLE_VERITY fails when almost done

   - Fix FS_IOC_MEASURE_VERITY and FS_IOC_READ_VERITY_METADATA to no
     longer bypass Landlock and AppArmor's read permission checks

   - Be robust against the filesystem returning different values for a
     file's verity descriptor length in two successive queries"

* tag 'fsverity-for-linus' of git://git.kernel.org/pub/scm/fs/fsverity/linux:
  fsverity: Set S_VERITY only after rollback is no longer possible
  fsverity: Tell LSMs about signature only after verity is enabled
  fsverity: Be more careful with return value of ->get_verity_descriptor()
  fsverity: Explicitly require FMODE_READ to retrieve hashes

Pull fscrypt fixes from Eric Biggers:

 - Add more checks to prevent encryption on "large block size" ext4
   filesystems (s_blocksize > PAGE_SIZE), which isn't supported yet.
   There was already a mount-time check, but it wasn't enough.

 - Add missing memory barrier to fscrypt_find_mode_key()

 - Add missing zeroization in an error path

* tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/linux:
  ext4: reject encrypted inodes when block size > page size
  ext4: refuse encryption when block size > page size
  fscrypt: Fix missing barrier in fscrypt_find_mode_key()
  fscrypt: Explicitly zeroize sw_secret in error path

Commit f77f281b6118 ("fsverity: use a hashtable to find the
fsverity_info") changed the implementation of FS_IOC_ENABLE_VERITY to
make concurrent reads start going through fsverity verification slightly
earlier than they did before.

Instead of it happening when enable_verity() calls fsverity_set_info(),
it now happens when ->end_enable_verity() sets S_VERITY.

However, ext4 and btrfs can roll back verity after they set S_VERITY,
causing a use-after-free.

Fix that by making ext4 and btrfs set S_VERITY only after rollback is no
longer possible.  On failure, don't roll back S_VERITY, but do roll back
the filesystem-specific verity flag.

Also update enable_verity() to handle any future instances of this bug
more safely by warning and *not* freeing the fsverity_info.

Finally, tweak some comments.  Clarify one, and move information from
another to its proper place in the comment for ->end_enable_verity().

Fixes: f77f281b6118 ("fsverity: use a hashtable to find the fsverity_info")
Cc: stable@vger.kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20261025204807.122875-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

Pull ext4 updates from Ted Ts'o:
 "Add support for buffered iomap support in ext4. This is not enabled by
  default, but requires the buffered_iomap mount option, as this mode
  does not support online defragmentation, inline data, fsverify,
  fscrypt, non-extent inodes, and data=journal mode. If buffered_iomap
  is enabled, ext4 will fall back to the original I/O code path
  automatically if necessary. Large writes show significant performance
  improvements when buffered iomap is enabled.

  There are also miscellaneous bug fixes and improvements, including for
  fast commit and avoiding deadlocks and out-of-bound reads when
  handling corner cases involving corrupted file systems"

* tag 'ext4_for_linus-7.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: (41 commits)
  ext4: introduce a mount option for iomap buffered I/O path
  ext4: partially enable iomap for the buffered I/O path of regular files
  ext4: add tracepoints for EOF block zeroing and disksize-grow I/O
  ext4: add tracepoints for DISKSIZE_GROW_PENDING set, clear, and wait
  ext4: set DISKSIZE_GROW_PENDING after zeroing unaligned EOF block
  ext4: clear DISKSIZE_GROW_PENDING on truncate or error
  ext4: submit and wait for disksize-grow I/O in fallocate paths
  ext4: defer i_disksize update while DISKSIZE_GROW_PENDING is set
  ext4: advance i_disksize to i_size upon disksize-grow I/O completion
  ext4: submit and wait for pending disksize-grow I/O on writeback
  ext4: add EXT4_STATE_DISKSIZE_GROW_PENDING state bit and helpers
  ext4: disable online defrag when inode using iomap buffered I/O path
  ext4: add block mapping tracepoints for iomap buffered I/O path
  ext4: drain writeback before removing extents on the iomap path
  ext4: implement partial block zero range path using iomap
  ext4: implement mmap path using iomap
  ext4: implement writeback path using iomap
  ext4: rework handle credit accounting for unwritten extent conversion
  ext4: implement buffered write path using iomap
  ext4: do not use data=ordered mode for inodes using buffered iomap path
  ...

Encryption is not supported when a filesystem's block size is larger
than the page size. ext4_check_large_folio() refuses to mount a
filesystem like that if the "encrypt" feature is already enabled, and
ext4_set_context() refuses to create encrypted inodes if the feature
is enabled after mounting.

However, a corrupted or hand-crafted filesystem can still have
encrypted inodes even if the "encrypt" feature is not set, and those
inodes can be unlocked if they're using v1 policies.

Check this in __ext4_iget() and reject them as corrupted.

Fixes: 709f0f1f1bf5 ("ext4: add checks for large folio incompatibilities when BS > PS")
Suggested-by: Eric Biggers <ebiggers@kernel.org>
Cc: stable@vger.kernel.org # v6.19+
Signed-off-by: Alberto Garcia <berto@igalia.com>
Reviewed-by: Baokun Li <libaokun@linux.alibaba.com>
Reviewed-by: Eric Biggers <ebiggers@kernel.org>
Link: https://patch.msgid.link/aeb8efa8beb72721fb4b13cffe6eb22c795ec33f.1790343958.git.berto@igalia.com
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

Encryption is not supported when a filesystem's block size is larger
than the page size, and commit 709f0f1f1bf5 ("ext4: add checks for
large folio incompatibilities when BS > PS") added a check to refuse
mounting such a filesystem.

However, it is also possible to enable the "encrypt" feature on a
filesystem that is already mounted (with tune2fs -O encrypt). Once
that happens it won't be possible to mount the filesystem again in
the future, but there is nothing preventing the user from setting an
encryption policy while the filesystem is still mounted.

Fix this by refusing to set an fscrypt context in ext4_set_context()
when the block size is larger than the page size.

Fixes: 709f0f1f1bf5 ("ext4: add checks for large folio incompatibilities when BS > PS")
Cc: stable@vger.kernel.org # v6.19+
Signed-off-by: Alberto Garcia <berto@igalia.com>
Reviewed-by: Baokun Li <libaokun@linux.alibaba.com>
Reviewed-by: Eric Biggers <ebiggers@kernel.org>
Link: https://patch.msgid.link/093b40e9df29fc102907092f4ff73461f4cfcbfd.1790343958.git.berto@igalia.com
Signed-off-by: Eric Biggers <ebiggers@kernel.org>

Pull fsverity updates from Eric Biggers:
 "Patches from Andrey Albershteyn to prepare for XFS fsverity support:

   - Report verification errors through fserror, instead of only through
     an unstructured log message and generic I/O error return

   - Move the reporting of STATX_ATTR_VERITY into the VFS, so that each
     fsverity-capable filesystem doesn't need to do it. This also fixes
     a bug where btrfs didn't return STATX_ATTR_VERITY in
     attributes_mask

   - Make the VFS prevent enabling DAX on fsverity files, so that it
     will be handled in a single place for ext4 and XFS

   - Move ext4 and f2fs's code to read verity metadata from the
     pagecache into shared code, so that XFS will be able to use it too

   - Export fsverity_ensure_verity_info() for XFS scrub to use

   - Pass all-zeroes hash to ->write_merkle_tree_block() so that XFS
     will be able to implement an optimization for sparse files"

* tag 'fsverity-for-linus' of git://git.kernel.org/pub/scm/fs/fsverity/linux:
  fsverity: hoist statx reporting of fs-verity flag
  fsverity: don't allow setting DAX file attribute on fsverity files
  fsverity: hoist pagecache_read from f2fs/ext4 to fsverity
  fsverity: pass digest size and hash of the all-zeroes block to ->write
  fsverity: expose ensure_fsverity_info()
  fsverity: report validation errors through fserror to fsnotify
  MAINTAINERS: List the fsverity branches

Pull vfs idmap constification from Christian Brauner:
 "This makes struct mnt_idmap const throughout the tree.

  A mount's idmapping is immutable. The only thing modified after
  alloc_mnt_idmap() is the reference count and that is hidden behind
  mnt_idmap_get() and mnt_idmap_put(). Everything else only reads from
  it. That is the same model struct cred uses and the idmapping is
  sensitive enough to deserve it.

  The conversion goes bottom up through the vfs{g,u}id and fs{g,u}id
  helpers, the privilege checks, acl, xattr and quota and then every
  inode operation that takes an idmap, so ->permission(), ->getattr(),
  ->setattr(), ->create(), ->mkdir(), ->mknod(), ->symlink(),
  ->rename(), ->tmpfile(), ->get_acl(), ->set_acl() and ->fileattr_set()
  with their implementations in every filesystem, plus the LSM hooks.

  struct vfsmount, struct mount_kattr and struct kstatmount store a
  const pointer and nop_mnt_idmap and invalid_mnt_idmap live in rodata,
  so anything that tries to modify them faults instead of silently
  corrupting the initial idmapping"

* tag 'vfs-7.4-rc1.idmap' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (27 commits)
  fs: make nop_mnt_idmap and invalid_mnt_idmap const
  fs: port mnt_idmap() and file_mnt_idmap() to const mnt_idmap
  fs: port vfs_*() helpers to const mnt_idmap
  fs: port ->setattr() to pass const mnt_idmap
  fs: port ->getattr() to pass const mnt_idmap
  fs: port ->create() to pass const mnt_idmap
  fs: port ->symlink() to pass const mnt_idmap
  fs: port ->mkdir() to pass const mnt_idmap
  fs: port ->rename() to pass const mnt_idmap
  fs: port ->mknod() to pass const mnt_idmap
  fs: port ->tmpfile() to pass const mnt_idmap
  fs: port ->get_acl() to pass const mnt_idmap
  fs: port ->set_acl() to pass const mnt_idmap
  fs: port ->fileattr_set() to pass const mnt_idmap
  fs: port xattr to const mnt_idmap
  fs: port ->permission() to pass const mnt_idmap
  fs: port acl to const mnt_idmap
  fs: port inode_init_owner() to const mnt_idmap
  fs: port inode_owner_or_capable() to const mnt_idmap
  fs: port privilege checking helpers to const mnt_idmap
  ...

Pull buffer_head updates from Christian Brauner:
 "This stops the buffer_head write completion handlers from clearing
  BH_Uptodate when a write fails.

  A buffer whose write failed still holds exactly the data the
  filesystem asked to be written. It's the disk that is stale, not the
  buffer. Claiming otherwise has consequences. mark_buffer_dirty() warns
  when a filesystem redirties the buffer to retry the write, a buffer
  that isn't up to date gets re-read from disk which silently replaces
  the data with the stale on-disk copy, and the window between the write
  completing and BH_Uptodate being cleared is visible to anyone holding
  the folio lock.

  BH_Write_EIO already records that the last write failed. Every
  consumer is moved over to buffer_write_io_error(): the two core
  helpers in fs/buffer.c, adfs, ext2, omfs, exfat, fat, ext4, ocfs2,
  gfs2 and jbd2. Then write completion stops touching BH_Uptodate in
  both directions and BH_Write_EIO is cleared on successful completion
  instead of at submission, so a resubmission no longer hides an error
  that hasn't been fixed yet. bforget() and invalidation drop the flag
  so a reused block doesn't inherit someone else's write error.

  The groundwork for this removes b_page from struct buffer_head and
  lets a buffer_head point at memory outside the page cache. jbd2's
  shadow buffers sit on a slab folio today. A slab folio overloads
  ->mapping so mark_buffer_write_io_error() couldn't be called on them
  at all. They now point at the frozen data directly with b_folio NULL.

  Also included are documentation updates from Matthew for sb_bread(),
  sb_breadahead() and mmb_mark_buffer_dirty() and the removal of stale
  references to unmap_buffer() and mark_buffer_dirty_inode()"

* tag 'vfs-7.4-rc1.bh' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (27 commits)
  buffer: Rename label
  buffer: Refer to folios in comments
  buffer: Document mmb_mark_buffer_dirty()
  buffer: Document sb_bread(), sb_bread_unmovable() and sb_breadahead()
  fs: Remove references to mark_buffer_dirty_inode()
  buffer: clear BH_Write_EIO when a write succeeds, not when one starts
  buffer: Remove reference to unmap_buffer()
  buffer: stop touching BH_Uptodate on write completion
  jbd2: check for a fast commit write error with buffer_write_io_error()
  jbd2: say what jbd2_freeze_jh_data()'s assertion is actually checking
  jbd2: report journal write errors with BH_Write_EIO
  gfs2: check for a metadata write error with buffer_write_io_error()
  ocfs2: check for a stale write error before reusing a metadata buffer
  ocfs2: check for a metadata write error with buffer_write_io_error()
  ext4: check for a metadata write error with buffer_write_io_error()
  fat: check for a metadata write error with buffer_write_io_error()
  exfat: check for a directory write error with buffer_write_io_error()
  omfs: check for an inode write error with buffer_write_io_error()
  ext2: check for an xattr block write error with buffer_write_io_error()
  adfs: check for a directory write error with buffer_write_io_error()
  ...

Since the iomap buffered I/O path does not yet support all existing ext4
features, it cannot be enabled by default. Introduce the
'buffered_iomap' and 'nobuffered_iomap' mount options to explicitly
enable or disable the iomap buffered I/O path for regular files.

Toggling this option via remount is allowed. The change of I/O path will
not take effect immediately. It will be deferred. The new setting will
only take effect after the inode is re-initialized (i.e., after the last
reference is dropped and the inode is re-read from disk).

Signed-off-by: Zhang Yi <yi.zhang@huawei.com>
Tested-by: syzbot@syzkaller.appspotmail.com
Link: https://patch.msgid.link/20261009103831.2978767-3-yi.zhang@huaweicloud.com
Signed-off-by: Theodore Ts'o <tytso@mit.edu>