kernel/git/stable/linux.git/fs/ext4/crypto.c, branch master

Merge tag 'ext4_for_linus-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4

2026-08-20T20:17:11+00:00

Pull ext4 updates from Ted Ts'o: - Improve performance by allowing parallel DIO writes when we were previously being overly conservative when checking whether it was safe to avoid requiring an exclusive lock - Improve the performance of ext4_mb_prefetch() used by fallocate() by avoiding work when it is not needed - Remove the unnecessary custom end_io function ext4_end_buffer_io_sync() - Improve performance when performing an overwrite to an already uptodate folio - Clean up how we handle deallocating EA inodes to avoid a potential lock ordering issue when there is a failed mount while an EA inode is still being evicted - Use str_plural() instead of a custom macro - Avoid soft lockups or RCU stalls if there are many busy buffers (caused by heavy I/O) while checkpointing - Use scoped NOFS when starting a handle in nojournal mode - Align fields in handle structure to optimize setting and getting the h_type and h_line_no fields - Fix documentation of the meta_bg block group layout - Bug fixes: - Fix a potential out-of-bounds read in ext4_read_inline_dir() - Fix a potential deadlock when concurrent xattr operations are racing with each other when some of the xattrs are using the ea_inode feature - Fix a spurious warning with data=journal that can be triggered when writeback races with remounting the file system read-only - Fix a potential deadlock when EXT4_IOC_MIGRATE races with a file system freeze operation - Make sure all in-flight direct I/O operations are complete before falling back to buffered I/O - Handle IOCB_NOWAIT properly when performing a extending DAX write - Prevent potentially sleeping on a block allocation when IOCB_NOWAIT is set - Fix potential races when racing an inline data write with a page fault - Propagate errors when adding or removing extent ranges during a fast commit replay - Avoid trying to expand an inode's extra size when it is being evicted to avoid a number of corner case or deadlocks - Avoid spurious error when retrying inode extra size expansion - Fix corner cases where we underestimate the number of journal credits needed - Avoid hangs/crashes/WARNINGS caused by maliciously corrupted file systems - Don't issue spurious orphan clean message on RO file systems - Avoid leaving the file system in an inconsistent state after a crash when a WRITE_ZEROS in progress converting an unwritten extent to a written extent - Handle WRITE_ZEROS correctly when there are some partially dirtied regions in the page cache - Pass errors during zero-rage, truncate, or punch hole to the caller if ext4_get_block() fails - Wait for writeback to finish when triggered by zero-range or zero-range for those devices that require stable writes - If the reserved gid superblock field is set, set the reserved gid instead of the reserved uid * tag 'ext4_for_linus-7.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4: (56 commits) ext4: fix estimate extent index blocks in ext4_ext_index_trans_blocks() ext4: fix transaction overflow during writeback ext4: teach ext4_meta_trans_blocks() about number of allocated extents ext4: guard against NULL s_group_info in ext4_get_group_info ext4: fix spurious message about orphan cleanup on RO fs ext4: stop retrying saturated xattr cache entries ext4: don't enable DAX on new encrypted files ext4: protect WRITE_ZEROES written extents with orphan list ext4: export converted block count from ext4_convert_unwritten_extents() ext4: fix incorrect function call when initializing s_resgid ext4: validate EA inode i_nlink in ext4_xattr_inode_iget jbd2: align h_type and h_line_no in the handle structure on byte boundaries ext4: enable scoped NOFS when starting a handle in nojournal mode ext4: write back partial-zeroed edges in WRITE_ZEROES ext4: zero out whole block for clean edges in WRITE_ZEROES ext4: track partial-zero outcome per edge in ext4_zero_partial_blocks() ext4: clarify return semantics of ext4_load_tail_bh() ext4: move partial block zeroing earlier in ext4_zero_range() ext4: check return value of ext4_get_block() in ext4_load_tail_bh() ext4: skip tail block zeroing for inline data files ...

ext4: don't enable DAX on new encrypted files

2026-08-06T14:21:52+00:00

Currently, when a new encrypted regular file is created, the call to ext4_set_inode_flags(inode, init=true) in __ext4_new_inode() is made before EXT4_INODE_ENCRYPT is set. As a result, it can set S_DAX if the filesystem is mounted with "-o dax=always". EXT4_INODE_ENCRYPT then actually gets set a bit later in __ext4_new_inode(), when it calls fscrypt_set_context() which calls ext4_set_context(). ext4_set_context() sets EXT4_INODE_ENCRYPT and calls ext4_set_inode_flags(inode, init=false) to set S_ENCRYPTED too. This was intended to clear S_DAX as well. However, this was broken by commit 043546e46dc7 ("fs/ext4: Only change S_DAX on inode load"). This causes data written to the file to bypass encryption, also causing xfstests failures such as generic/548 (when "-o dax=always" is used). Fix this by simplifying the flow by making __ext4_new_inode() set EXT4_INODE_ENCRYPT earlier. This makes it take effect in ext4_set_inode_flags(inode, init=true), making S_DAX never be set. Similarly, make EXT4_STATE_MAY_INLINE_DATA never be set in the first place on new encrypted inodes. Then it doesn't need to be cleared. As a result of these simplifications, ext4_set_context() no longer needs to change inode flags or state when 'handle != NULL'. Remove that too. Reported-by: Disha Goel Reported-by: Ojaswin Mujoo Closes: https://lore.kernel.org/r/20260723085648.1500357-1-ojaswin@linux.ibm.com Fixes: 043546e46dc7 ("fs/ext4: Only change S_DAX on inode load") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers Tested-by: Disha Goel Reviewed-by: Ojaswin Mujoo Reviewed-by: Jan Kara Link: https://patch.msgid.link/20260730175212.36923-1-ebiggers@kernel.org Signed-off-by: Theodore Ts'o

ext4: Remove fs-layer file contents en/decryption code

2026-07-20T17:39:25+00:00

Now that fscrypt's file contents en/decryption is always implemented using blk-crypto when the filesystem is block-based, the fs-layer en/decryption code in ext4 is unused code. Remove it. Note that this makes possible some additional cleanups, but they're left to later commits: - Making ext4_bio_write_folio() return void - Renaming bio_post_read_ctx to fsverity_ctx or similar, and allocating the pool only when fsverity support is needed Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260713023708.9245-8-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: Always use blk-crypto for contents on block-based filesystems

2026-07-20T17:39:25+00:00

For encrypting and decrypting file contents on block-based filesystems (i.e., ext4 and f2fs, but not ceph and ubifs), always use blk-crypto instead of fs-layer crypto (direct use of crypto_skcipher). Since the blk-crypto API provides a fallback to CPU-based encryption, it's all that's needed on block-based filesystems. The support for two alternative block-based file contents encryption implementations, fs-layer and blk-crypto, existed mainly for historical reasons, as the fs-layer path came first. Some of it is also still needed for the non-block-based filesystems, but a lot of it isn't. Removing the duplicate fs-layer code paths greatly simplifies the code, most of which is done in later commits. Specific implementation details: - SB_INLINECRYPT now controls whether blk_crypto_config::allow_hw is set to true, instead of whether blk-crypto is used at all. The effect is that the semantics are preserved: the inlinecrypt mount option selects the use of inline encryption hardware instead of the CPU. - Set up a blk_crypto_key iff the file is a regular file on a block-based filesystem. To determine whether the filesystem is block-based, add a bit fscrypt_operations::is_block_based. - Remove fscrypt_select_encryption_impl(). Move the logging logic that was previously there into fscrypt_prepare_inline_crypt_key(). Note that blk_crypto_config_supported() is no longer needed. Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260713023708.9245-6-ebiggers@kernel.org Signed-off-by: Eric Biggers

ext4: fix journal credit check when setting fscrypt context

2026-03-28T03:30:25+00:00

Fix an issue arising when ext4 features has_journal, ea_inode, and encrypt are activated simultaneously, leading to ENOSPC when creating an encrypted file. Fix by passing XATTR_CREATE flag to xattr_set_handle function if a handle is specified, i.e., when the function is called in the control flow of creating a new inode. This aligns the number of jbd2 credits set_handle checks for with the number allocated for creating a new inode. ext4_set_context must not be called with a non-null handle (fs_data) if fscrypt context xattr is not guaranteed to not exist yet. The only other usage of this function currently is when handling the ioctl FS_IOC_SET_ENCRYPTION_POLICY, which calls it with fs_data=NULL. Fixes: c1a5d5f6ab21eb7e ("ext4: improve journal credit handling in set xattr paths") Co-developed-by: Anthony Durrer Signed-off-by: Anthony Durrer Signed-off-by: Simon Weber Reviewed-by: Eric Biggers Link: https://patch.msgid.link/20260207100148.724275-4-simon.weber.39@gmail.com Signed-off-by: Theodore Ts'o Cc: stable@kernel.org

ext4: move crypt info pointer to fs-specific part of inode

2025-08-21T11:58:07+00:00

Move the fscrypt_inode_info pointer into the filesystem-specific part of the inode by adding the field ext4_inode_info::i_crypt_info and configuring fscrypt_operations::inode_info_offs accordingly. This is a prerequisite for a later commit that removes inode::i_crypt_info, saving memory and improving cache efficiency with filesystems that don't support fscrypt. Co-developed-by: Christian Brauner Signed-off-by: Eric Biggers Link: https://lore.kernel.org/20250810075706.172910-4-ebiggers@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Christian Brauner

ext4: Move CONFIG_UNICODE defguards into the code flow

2024-06-07T15:00:45+00:00

Instead of a bunch of ifdefs, make the unicode built checks part of the code flow where possible, as requested by Torvalds. Signed-off-by: Gabriel Krisman Bertazi [eugen.hristev@collabora.com: port to 6.10-rc1] Signed-off-by: Eugen Hristev Link: https://lore.kernel.org/r/20240606073353.47130-7-eugen.hristev@collabora.com Reviewed-by: Eric Biggers Reviewed-by: Gabriel Krisman Bertazi Signed-off-by: Christian Brauner

fscrypt: support crypto data unit size less than filesystem block size

2023-09-26T05:34:33+00:00

Until now, fscrypt has always used the filesystem block size as the granularity of file contents encryption. Two scenarios have come up where a sub-block granularity of contents encryption would be useful: 1. Inline crypto hardware that only supports a crypto data unit size that is less than the filesystem block size. 2. Support for direct I/O at a granularity less than the filesystem block size, for example at the block device's logical block size in order to match the traditional direct I/O alignment requirement. (1) first came up with older eMMC inline crypto hardware that only supports a crypto data unit size of 512 bytes. That specific case ultimately went away because all systems with that hardware continued using out of tree code and never actually upgraded to the upstream inline crypto framework. But, now it's coming back in a new way: some current UFS controllers only support a data unit size of 4096 bytes, and there is a proposal to increase the filesystem block size to 16K. (2) was discussed as a "nice to have" feature, though not essential, when support for direct I/O on encrypted files was being upstreamed. Still, the fact that this feature has come up several times does suggest it would be wise to have available. Therefore, this patch implements it by using one of the reserved bytes in fscrypt_policy_v2 to allow users to select a sub-block data unit size. Supported data unit sizes are powers of 2 between 512 and the filesystem block size, inclusively. Support is implemented for both the FS-layer and inline crypto cases. This patch focuses on the basic support for sub-block data units. Some things are out of scope for this patch but may be addressed later: - Supporting sub-block data units in combination with FSCRYPT_POLICY_FLAG_IV_INO_LBLK_64, in most cases. Unfortunately this combination usually causes data unit indices to exceed 32 bits, and thus fscrypt_supported_policy() correctly disallows it. The users who potentially need this combination are using f2fs. To support it, f2fs would need to provide an option to slightly reduce its max file size. - Supporting sub-block data units in combination with FSCRYPT_POLICY_FLAG_IV_INO_LBLK_32. This has the same problem described above, but also it will need special code to make DUN wraparound still happen on a FS block boundary. - Supporting use case (2) mentioned above. The encrypted direct I/O code will need to stop requiring and assuming FS block alignment. This won't be hard, but it belongs in a separate patch. - Supporting this feature on filesystems other than ext4 and f2fs. (Filesystems declare support for it via their fscrypt_operations.) On UBIFS, sub-block data units don't make sense because UBIFS encrypts variable-length blocks as a result of compression. CephFS could support it, but a bit more work would be needed to make the fscrypt_*_block_inplace functions play nicely with sub-block data units. I don't think there's a use case for this on CephFS anyway. Link: https://lore.kernel.org/r/20230925055451.59499-6-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: replace get_ino_and_lblk_bits with just has_32bit_inodes

2023-09-26T05:34:33+00:00

Now that fs/crypto/ computes the filesystem's lblk_bits from its maximum file size, it is no longer necessary for filesystems to provide lblk_bits via fscrypt_operations::get_ino_and_lblk_bits. It is still necessary for fs/crypto/ to retrieve ino_bits from the filesystem. However, this is used only to decide whether inode numbers fit in 32 bits. Also, ino_bits is static for all relevant filesystems, i.e. it doesn't depend on the filesystem instance. Therefore, in the interest of keeping things as simple as possible, replace 'get_ino_and_lblk_bits' with a flag 'has_32bit_inodes'. This can always be changed back to a function if a filesystem needs it to be dynamic, but for now a static flag is all that's needed. Link: https://lore.kernel.org/r/20230925055451.59499-5-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: make the bounce page pool opt-in instead of opt-out

2023-09-25T06:03:09+00:00

Replace FS_CFLG_OWN_PAGES with a bit flag 'needs_bounce_pages' which has the opposite meaning. I.e., filesystems now opt into the bounce page pool instead of opt out. Make fscrypt_alloc_bounce_page() check that the bounce page pool has been initialized. I believe the opt-in makes more sense, since nothing else in fscrypt_operations is opt-out, and these days filesystems can choose to use blk-crypto which doesn't need the fscrypt bounce page pool. Also, I happen to be planning to add two more flags, and I wanted to fix the "FS_CFLG_" name anyway as it wasn't prefixed with "FSCRYPT_". Link: https://lore.kernel.org/r/20230925055451.59499-3-ebiggers@kernel.org Signed-off-by: Eric Biggers