kernel/linux.git/fs/crypto/fname.c, branch v6.18.22

Merge tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/linux

2025-09-29T22:33:50+00:00

Pull fscrypt updates from Eric Biggers: "Make fs/crypto/ use the HMAC-SHA512 library functions instead of crypto_shash. This is simpler, faster, and more reliable" * tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/fs/fscrypt/linux: fscrypt: use HMAC-SHA512 library for HKDF fscrypt: Remove redundant __GFP_NOWARN

fscrypt: use HMAC-SHA512 library for HKDF

2025-09-06T04:01:51+00:00

For the HKDF-SHA512 key derivation needed by fscrypt, just use the HMAC-SHA512 library functions directly. These functions were introduced in v6.17, and they provide simple and efficient direct support for HMAC-SHA512. This ends up being quite a bit simpler and more efficient than using crypto/hkdf.c, as it avoids the generic crypto layer: - The HMAC library can't fail, so callers don't need to handle errors - No inefficient indirect calls - No inefficient and error-prone dynamic allocations - No inefficient and error-prone loading of algorithm by name - Less stack usage Benchmarks on x86_64 show that deriving a per-file key gets about 30% faster, and FS_IOC_ADD_ENCRYPTION_KEY gets nearly twice as fast. The only small downside is the HKDF-Expand logic gets duplicated again. Then again, even considering that, the new fscrypt_hkdf_expand() is only 7 lines longer than the version that called hkdf_expand(). Later we could add HKDF support to lib/crypto/, but for now let's just do this. Link: https://lore.kernel.org/r/20250906035913.1141532-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: replace raw loads of info pointer with helper function

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

Add and use a helper function fscrypt_get_inode_info_raw(). It loads an inode's fscrypt info pointer using a raw dereference, which is appropriate when the caller knows the key setup already happened. This eliminates most occurrences of inode::i_crypt_info in the source, in preparation for replacing that with a filesystem-specific field. Co-developed-by: Christian Brauner Signed-off-by: Eric Biggers Link: https://lore.kernel.org/20250810075706.172910-2-ebiggers@kernel.org Signed-off-by: Christian Brauner

fscrypt: Switch to sync_skcipher and on-stack requests

2025-07-10T19:33:08+00:00

Now that fscrypt uses only synchronous skciphers, switch to the actual sync_skcipher API and the corresponding on-stack requests. This eliminates a heap allocation per en/decryption operation. Link: https://lore.kernel.org/r/20250710060754.637098-4-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: Don't use asynchronous CryptoAPI algorithms

2025-07-10T19:33:08+00:00

Now that fscrypt's incomplete support for non-inline crypto engines has been removed, and none of the CPU-based algorithms have the CRYPTO_ALG_ASYNC flag set anymore, there is no need to accommodate asynchronous algorithms. Therefore, explicitly allocate only synchronous algorithms. Then, remove the code that handled waiting for asynchronous en/decryption operations to complete. This commit should *not* be backported to kernels that lack commit 0ba6ec5b2972 ("crypto: x86/aes - stop using the SIMD helper"), as then it would disable the use of the optimized AES code on x86. Link: https://lore.kernel.org/r/20250710060754.637098-2-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt: Explicitly include

2025-06-20T21:30:23+00:00

Fix build warnings with W=1 that started appearing after commit a934a57a42f6 ("scripts/misc-check: check missing #include when W=1"). While at it, also sort the include lists alphabetically. Link: https://lore.kernel.org/r/20250614221301.100803-1-ebiggers@kernel.org Signed-off-by: Eric Biggers

fscrypt_d_revalidate(): use stable parent inode passed by caller

2025-01-28T00:25:23+00:00

The only thing it's using is parent directory inode and we are already given a stable reference to that - no need to bother with boilerplate. Reviewed-by: Jeff Layton Signed-off-by: Al Viro

Pass parent directory inode and expected name to ->d_revalidate()

2025-01-28T00:25:23+00:00

->d_revalidate() often needs to access dentry parent and name; that has to be done carefully, since the locking environment varies from caller to caller. We are not guaranteed that dentry in question will not be moved right under us - not unless the filesystem is such that nothing on it ever gets renamed. It can be dealt with, but that results in boilerplate code that isn't even needed - the callers normally have just found the dentry via dcache lookup and want to verify that it's in the right place; they already have the values of ->d_parent and ->d_name stable. There is a couple of exceptions (overlayfs and, to less extent, ecryptfs), but for the majority of calls that song and dance is not needed at all. It's easier to make ecryptfs and overlayfs find and pass those values if there's a ->d_revalidate() instance to be called, rather than doing that in the instances. This commit only changes the calling conventions; making use of supplied values is left to followups. NOTE: some instances need more than just the parent - things like CIFS may need to build an entire path from filesystem root, so they need more precautions than the usual boilerplate. This series doesn't do anything to that need - these filesystems have to keep their locking mechanisms (rename_lock loops, use of dentry_path_raw(), private rwsem a-la v9fs). One thing to keep in mind when using name is that name->name will normally point into the pathname being resolved; the filename in question occupies name->len bytes starting at name->name, and there is NUL somewhere after it, but it the next byte might very well be '/' rather than '\0'. Do not ignore name->len. Reviewed-by: Jeff Layton Reviewed-by: Gabriel Krisman Bertazi Signed-off-by: Al Viro

fs: Create a generic is_dot_dotdot() utility

2024-01-23T15:58:56+00:00

De-duplicate the same functionality in several places by hoisting the is_dot_dotdot() utility function into linux/fs.h. Suggested-by: Amir Goldstein Reviewed-by: Jeff Layton Reviewed-by: Amir Goldstein Acked-by: Christian Brauner Signed-off-by: Chuck Lever

fscrypt: rename fscrypt_info => fscrypt_inode_info

2023-10-09T03:44:26+00:00

We are going to track per-extent information, so it'll be necessary to distinguish between inode infos and extent infos. Rename fscrypt_info to fscrypt_inode_info, adjusting any lines that now exceed 80 characters. Signed-off-by: Josef Bacik [ebiggers: rebased onto fscrypt tree, renamed fscrypt_get_info(), adjusted two comments, and fixed some lines over 80 characters] Link: https://lore.kernel.org/r/20231005025757.33521-1-ebiggers@kernel.org Reviewed-by: Neal Gompa Signed-off-by: Eric Biggers