kernel/linux.git/include/linux/fscrypt.h, branch v7.3-rc1

fscrypt: Remove unused function fscrypt_finalize_bounce_page()

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

fscrypt_finalize_bounce_page() is no longer called, so remove it. Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260718214655.63186-4-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: Merge bio.c and inline_crypt.c into block.c

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

Now that fscrypt always uses blk-crypto on block-based filesystems, there's no meaningful difference between bio.c and inline_crypt.c. Therefore merge the two files into one named block.c. Note: I didn't carry over bio.c's "Copyright (C) 2015, Motorola Mobility", as none of the code that applied to remained. Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260713023708.9245-17-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: Remove unused functions and workqueue

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

Remove functions that are no longer used: - fscrypt_decrypt_bio() - fscrypt_decrypt_pagecache_blocks() - fscrypt_inode_uses_fs_layer_crypto() - fscrypt_inode_uses_inline_crypto() - fscrypt_enqueue_decrypt_work() This makes the decryption workqueue unused, so remove it too. Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260713023708.9245-16-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: Remove fscrypt_dio_supported()

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

On block-based filesystems, fscrypt file contents encryption is now always implemented using blk-crypto. This implementation supports direct I/O. Therefore, fscrypt_dio_supported() now always returns true, except in the edge case where statx(STATX_DIOALIGN) is called on an encrypted regular file that hasn't had its key set up. But that was really a workaround rather than the desired behavior, so we can disregard it. Thus, fscrypt_dio_supported() is no longer needed. Remove it. Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260713023708.9245-14-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

fscrypt: Avoid dynamic allocation in fscrypt_get_devices()

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

When a blk_crypto_key starts being used or is evicted, fs/crypto/ calls fscrypt_get_devices() to get the filesystem's list of block devices, then iterates over them and calls blk_crypto_config_supported(), blk_crypto_start_using_key(), or blk_crypto_evict_key() on each one. Currently, the block device pointers are placed in a dynamically allocated array. This dynamic allocation is problematic because: - It can fail, especially at the fscrypt_destroy_inline_crypt_key() call site when it's invoked for inode eviction under direct reclaim. - fscrypt_destroy_inline_crypt_key() doesn't handle the failure. It just zeroizes and frees the blk_crypto_key without calling blk_crypto_evict_key(). That causes a use-after-free. For now, let's fix this in the straightforward and easily-backportable way by switching to an on-stack array. Currently the fscrypt multi-device functionality is used only by f2fs, which has a hardcoded limit of 8 block devices. An on-stack array works fine for that. (Of course, this solution won't scale up to large number of block devices. For that we'd need a different solution, like moving the block device iteration into the filesystem. Or in the case of btrfs, which will only support blk-crypto-fallback, we should make it just call blk-crypto-fallback directly, so the block devices won't be needed.) Fixes: 22e9947a4b2b ("fscrypt: stop holding extra request_queue references") Cc: stable@vger.kernel.org Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/20260713023708.9245-1-ebiggers%40kernel.org Reviewed-by: Christoph Hellwig Link: https://patch.msgid.link/20260719055602.78828-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: pass a real sector_t to fscrypt_zeroout_range

2026-03-09T20:34:21+00:00

While the pblk argument to fscrypt_zeroout_range is declared as a sector_t, it actually is interpreted as a logical block size unit, which is highly unusual. Switch to passing the 512 byte units that sector_t is defined for. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20260302141922.370070-14-hch@lst.de Signed-off-by: Eric Biggers

fscrypt: pass a byte length to fscrypt_zeroout_range

2026-03-09T20:34:18+00:00

Range lengths are usually expressed as bytes in the VFS, switch fscrypt_zeroout_range to this convention. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20260302141922.370070-13-hch@lst.de Signed-off-by: Eric Biggers

fscrypt: pass a byte offset to fscrypt_zeroout_range

2026-03-09T20:31:51+00:00

Logical offsets into an inode are usually expressed as bytes in the VFS. Switch fscrypt_zeroout_range to that convention. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20260302141922.370070-12-hch@lst.de Signed-off-by: Eric Biggers

fscrypt: pass a byte offset to fscrypt_set_bio_crypt_ctx

2026-03-09T20:31:50+00:00

Logical offsets into an inode are usually expressed as bytes in the VFS. Switch fscrypt_set_bio_crypt_ctx to that convention. Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20260302141922.370070-9-hch@lst.de Signed-off-by: Eric Biggers