Documentation/block/inline-encryption.rst

132 blk-crypto-fallback
141 Therefore, we also introduce *blk-crypto-fallback*, which is an implementation
142 of inline encryption using the kernel crypto API.  blk-crypto-fallback is built
146 handle en/decryption of the bio using blk-crypto-fallback.
149 on it being unmodified.  Instead, blk-crypto-fallback allocates bounce pages,
152 blk-crypto-fallback completes the original bio.  If the original bio is too
155 For decryption, blk-crypto-fallback "wraps" the bio's completion callback
158 successfully, blk-crypto-fallback restores the bio's original completion
161 Afterwards, blk-crypto-fallback completes the bio.
163 In both cases, the bios that blk-crypto-fallback submits no longer have an
166 blk-crypto-fallback also defines its own blk_crypto_profile and has its own
174 makes sense for blk-crypto-fallback.
177 blk-crypto-fallback is used, the ciphertext written to disk (and hence the
182 blk-crypto-fallback is optional and is controlled by the
190 block_device -- either via hardware or via blk-crypto-fallback.  This function
193 size, etc.  This function can be useful if blk-crypto-fallback is disabled.
199 was called earlier).  This is needed to initialize blk-crypto-fallback if it
292 encryption support is present or the kernel crypto API fallback is used (since
293 if the fallback is used, the device will receive the integrity info of the
301 When the crypto API fallback is enabled, this means that all bios with and
302 encryption context will use the fallback, and IO will complete as usual.  When
303 the fallback is disabled, a bio with an encryption context will be failed.