diff options
| author | Eric Biggers <ebiggers@kernel.org> | 2026-07-18 14:46:55 -0700 |
|---|---|---|
| committer | Eric Biggers <ebiggers@kernel.org> | 2026-07-20 10:39:26 -0700 |
| commit | 7dd38d9dd7a05329825fe2324d4d8e27ad4b3cec (patch) | |
| tree | feca85812cb6106171d92c920158a579675e44a9 | |
| parent | fae2c34252cf4aea40d0d74fb41261bdcc581dbb (diff) | |
blk-crypto: Update docs for blk-crypto-fallback motivation
The "Objective" section of inline-encryption.rst suggests that
blk-crypto-fallback is just for testing. That's no longer accurate, so
update it accordingly. Also fix a typo later in the document.
Reviewed-by: Christoph Hellwig <hch@lst.de>
Link: https://patch.msgid.link/20260718214655.63186-7-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
| -rw-r--r-- | Documentation/block/inline-encryption.rst | 14 |
1 files changed, 7 insertions, 7 deletions
diff --git a/Documentation/block/inline-encryption.rst b/Documentation/block/inline-encryption.rst index 0052c7011b48..0df964507f76 100644 --- a/Documentation/block/inline-encryption.rst +++ b/Documentation/block/inline-encryption.rst @@ -37,12 +37,12 @@ initialization vector for each sector, and can be tested for correctness. Objective ========= -We want to support inline encryption in the kernel. To make testing easier, we -also want support for falling back to the kernel crypto API when actual inline -encryption hardware is absent. We also want inline encryption to work with -layered devices like device-mapper and loopback (i.e. we want to be able to use -the inline encryption hardware of the underlying devices if present, or else -fall back to crypto API en/decryption). +We want to support inline encryption hardware in the kernel. The API for using +such hardware should also support a fallback to the CPU, so that users only need +to use a single API and more of the code can be tested without actual hardware. +We also want inline encryption to work with layered devices like device-mapper +and loopback (i.e. we want to be able to use the inline encryption hardware of +the underlying devices if present, or else fall back to the CPU). Constraints and notes ===================== @@ -295,7 +295,7 @@ hardware implementations might not implement both features together correctly, and disallow the combination for now. Whenever a device supports integrity, the kernel will pretend that the device does not support hardware inline encryption (by setting the blk_crypto_profile in the request_queue of the device to NULL). -When the crypto API fallback is enabled, this means that all bios with and +When the crypto API fallback is enabled, this means that all bios with an encryption context will use the fallback, and IO will complete as usual. When the fallback is disabled, a bio with an encryption context will be failed. |