Re: [PATCH v2 2/2] blk-crypto: fix missing smp_load_acquire() for tfms_inited[]

[Eric Biggers <ebiggers@kernel.org>]

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