On Wed, Oct 14, 2026 at 03:18:46PM +0800, Baokun Li wrote:
>
[trim LLM-generated text]
> diff --git a/block/blk-crypto-fallback.c b/block/blk-crypto-fallback.c
> index b5dbb092caea..31f76d117593 100644
> --- a/block/blk-crypto-fallback.c
> +++ b/block/blk-crypto-fallback.c
> @@ -488,15 +488,17 @@ static void blk_crypto_fallback_decrypt_endio(struct
> bio *bio)
> bool blk_crypto_fallback_bio_prep(struct bio *bio)
> {
> struct bio_crypt_ctx *bc = bio->bi_crypt_context;
> + const struct blk_crypto_config *cfg = &bc->bc_key->crypto_cfg;
> struct bio_fallback_crypt_ctx *f_ctx;
>
> - if (WARN_ON_ONCE(!tfms_inited[bc->bc_key->crypto_cfg.crypto_mode])) {
> + /* Pairs with the release in blk_crypto_fallback_start_using_mode(). */
> + if (WARN_ON_ONCE(!smp_load_acquire(&tfms_inited[cfg->crypto_mode]))) {
> /* User didn't call blk_crypto_start_using_key() first */
> bio_io_error(bio);
> return false;
> }
No, anyone submitting encrypted I/O is required to ensure that
blk_crypto_start_using_key() was called first, in which case the
additional barrier here during I/O submission isn't needed. If the
caller didn't ensure that, then it's a bug, and we WARN. This patch is
inconsistent with that.
I think this can be considered a bug report that the ordering of
fscrypt_find_mode_key() is too weak now, as it just uses
list_for_each_entry_rcu(). It looks like it should do
smp_acquire__after_ctrl_dep() after it finds the right entry in the
list.
- Eric
